[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GNU Crypto] towards a (new) high-level symmetric block cipher API (
From: |
Casey Marshall |
Subject: |
Re: [GNU Crypto] towards a (new) high-level symmetric block cipher API (long) |
Date: |
Sat, 15 Mar 2003 17:33:58 -0800 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030228 |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Raif S. Naffah wrote:
| hello there,
|
| here are some thoughts about a proposal for a new high-level API to
| include in GNU Crypto.
|
| [...]
I think this could be a somewhat redundant construction, and has a few
problems. What I was thinking is a single master interface that works
both as a collection of crypto primitives and as a node in a list.
Something akin to:
public interface IAssembly {
~ void init(Map[] attrib) throws ...;
~ int update(byte[] in, int inOffset, byte[] out, int outOffset)
~ throws ...;
~ int lastUpdate(byte[] in, int inOffset, byte[] out, int outOffset)
~ throws ...;
~ Iterator iterator();
~ void setNext(IAssembly ass);
~ IAssembly next();
~ ...
}
Where a concrete Assembly can contain a Mode+Cipher+Padding, another
Assembly, a list of Assemblies, etc. Calling update or lastUpdate on a
"root" Assembly will start a chain of calls to *[uU]pdate, each one
filtering its input before sending the data to its child.
I also think it would be desirable to have the Assembly be block-size
ignorant; i.e. the input can be of any length and each Assembly will
buffer its input until enough data is ready for the underlying
primitive. Such a construction would even allow non-cryptographic
filters (such as a compression algorithm) to be placed into the chain.
This is, I suppose, similar to an OutputStream in Java, except:
~ 1. The filtered data does not "come out" the end of the chain, but is
rather passed back to the caller in the output array.
~ 2. The chain is iteratable.
~ 3. The chain is mutable (nodes can be moved, inserted, or removed).
Additionally, an Assembly should perhaps have one additional component:
a key derivation function. This could be simply a pointer that says
"look for raw bytes in the attributes", a PBE KDF, a public key exchange
method (DH), or something else.
- --
Casey Marshall || address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE+c9SFgAuWMgRGsWsRAqSbAJ9/WuTTMtq4UrzN+R0rfKbZTWNt/QCgg1+5
aHVC5dx/DX3DrpazScAM6cY=
=tzbF
-----END PGP SIGNATURE-----