[GNU Crypto] towards a (new) high-level symmetric block cipher API (long)

[Raif S. Naffah]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

hello there,

here are some thoughts about a proposal for a new high-level API to 
include in GNU Crypto.  the only ciphers covered here are symmetric 
block-ciphers.  comments are welcome:

* block ciphers, transform (Encryption) plaintext (p) into ciphertext 
(c), and v/v (Decryption) in fixed-size blocks, n-bit long.  the 
transformation is a function of a session key (Ke for encryption, and 
Kd for decryption); generated from user-supplied key(ing) material. 
i.e.:

   p ---> E(Ke) ---> c
   c ---> D(Kd) ---> p

where:

   p       the plaintext, as a multiple of n-bit blocks,
   c       the ciphertext, as a multiple of n-bit blocks,
   E       the encryption function,
   D       its inverse function, and
   Ke, Kd  the session encryption and decryption keys.


* modes of operations, wrap block ciphers, that transforms the input 
stream into r-bit blocks.  r-bit being the block-size of the Mode, 
which is different, and usually less, than n-bit: the block-size of the 
underlying symmetric block cipher. i.e.:

   in ---> M(C, K, ...) ---> out

where:

   in    the input text as a multiple of n-bit blocks,
   out   the output text as a multiple of r-bit blocks,
   C     the underlying symmetric key block cipher, with E and D
         encryption and decryption functions respectively, and
   K     the encryption and decryption session keys.
   ...   other parameters, notably the IV (initialisation Vector)
         required for some modes of operations.

worth noting at this stage, that an 8-bit mode, over a 128-bit block 
cipher for example, allows operating the latter as a 1-byte stream 
cipher.


* as long as the input is processed in blocks, there is no need to 
distinguish between first, subsequent or final invocation of the 
transforms.  this leaves the onus on the caller to segment correctly 
the raw input into appropriate length blocks and collect and assemble 
the output.


* in practice, data is rarely a multiple of the block-size (of either 
the block cipher or the mode of operation).  the last remaining bits 
must be padded to finalise, and force processing of (flush), any 
intermediate bytes in the mode of operation --a block cipher does not 
hold any intermediate data.  thus, leaving aside for the moment 
security considerations, the following combinations should be enough to 
completely transform any length input:

   + Cipher + Padding, or
   + Mode + Cipher + Padding.

furthermore, because of the fact that the last block of real input data 
may not be of the required block-size, an explicit signal must be sent 
to indicate that padding (and conversely unpadding) should take place.


* in practice also, techniques for cascaded transformation, use more 
than one cipher, with same or different keys to process the input in 
stages.  a good example of this is DES-EDE.  generically this can be 
represented as:

   p ---> E1(Ke1) ---> D2(Kd2) ---> E3(Ke3) ---> c
   c ---> D1(Kd1) ---> E2(Ke2) ---> D3(Kd3) ---> p

in case of DES-EDE, all E/D pairs are the same DES algorithm, but all 
keys (K1, K2 and K3) are different.

the literature[1], defines a Cascade Cipher as being the concatenation 
of L >= 2 block ciphers, and Multiple Encryption, as a Cascade of 
identical ciphers.

the above definition holds true even when applied to modes of 
operations.


* from the above, it's evident that: block ciphers, modes of operation, 
and cascade ciphers are all block-ciphers; i.e. they process their 
input in blocks.  combined with a padding, such constructions are 
capable of fully transforming raw data of any length.

the following types are an attempt to formalise the above --using EBNF 
meta characters:

Cipher ::=   IBlockCipher | IMode
Cascade ::=  (Cipher | Cascade)+
Assembly ::= Cascade Padding


* the simplest form (implementation-wise) of constructing cascaded 
ciphers, is to impose the same block size on all participating 
elements.  this is because, otherwise, padding may be required between 
each pair of cascading elements with different block sizes when 
executing the last transformation.


* the following (partial at this stage) API is proposed:

public interface ICascade extends IMode {
   ...
   void append(ICascade c) throws IllegalArgumentException;
   void prepend(ICascade c) throws IllegalArgumentException;
   void clear();
   Iterator iterator();
   ...
}

public class Cascade implements ICascade {
   ...
   public static ICascade getInstance(IBlockCipher e1, IBlockCipher e2)
   throws IllegalArgumentException {...}
   ...
}

public interface IAssembly {
   ...
   ICascade getCascade();
   IPad getPadding();
   void init(Map[] m) throws...;
   int update(byte[] in, int inOffset, byte[] out, int outOffset)
      throws ...;
   int lastUpdate(byte[] in, int inOffset, byte[] out, int outOffset)
      throws ...;
   ...
}

public class Assembly {
   ...
   public static IAssembly getInstance(ICascade c, IPad p) {...}
   ...
}


cheers;
rsn
- -----
[1] The Handbook of Applied Cryptography, Menezes & al.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Que du magnifique

iD8DBQE+co6a+e1AKnsTRiERA69oAKDkwbRIkgZ+qXz2UQSSlt6hurCPmwCeLF4K
1MSXkN4CnMnjc5fLH1JSuj0=
=XklR
-----END PGP SIGNATURE-----