[GNU Crypto] Assembly (long)

[Raif S. Naffah]

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

hello Casey,

On Friday 21 March 2003 20:13, Casey Marshall wrote:
> ...
> The very first sketch is attached ... I
> think for this it may be necessary to add a keySize method to Stage...

i believe this is mandatory to implement the TODO in the Cascade's 
insert() method --which i hopefully will do ;-) today.


> (maybe also methods that say if a Stage needs an IV), so Assembly
> knows how many random bytes are needed.

may be --see my comments at the end.


as it is the Assmebly will do the basic job of allowing us to have (even 
now, a better) JCE Cipher-compatible construction.  but it's not 
enough; i want more :-)

if we want to implement things as you suggested earlier like 
compression, etc. this Assembly is not enough.

at the heart of an Assembly there is a Cascade.  this takes care of 
'chain'ing ciphers.  if, for the sake of example, we look at having a 
construction that would allow both: padding and compression, we need to 
have the following:

for padding:

* when encrypting, we need to distinguish between a casual and last push 
(update) operation.  this is because this padding stage, when operated 
in this direction, only outputs data in blocks with a block-size that 
'fits' the entry point of the cascade.  in other words, if we feed the 
update() method 1 block, it results in 1 block --no buffering needed.  
the lastUpdate() method must also generate:

   1 block for any number of bytes < cascade's block-size, or
   2 blocks for a number of bytes == cascade's block-size.

* when decrypting, the same distinction between casual and last push 
(update) operation, must still be maintained.  yet, buffering is 
needed.


for compression:

* similar to padding, the distinction between casual and last operation 
must be made.

* buffering, at least for the common compression algorithms, is needed 
when doing either compression or decompression.


from the above, we can abstract both padding and compression, as 
Transformers, with a Transformer being characterised by the followings:

* Transformers can be chained together.
* when wired in an Assembly, the operational direction is irrelevant, 
since for both FORWARD and BACKWARD modes, the data has to travel in 
always the same order of configured Transformers in a chain.  i.e.

                                      +-----+
                                      |    in
FORWARD:  ---> T1 ---> T2 ---> ... ---+  Cascade  +--->
                                           out    |
                                            +-----+

                                            +-----+
                                           in     |
BACKWARD: ---> T1 ---> T2 ---> ... ---+  Cascade  +--->
                                      |    out
                                      +-----+

* useful Transformers --the ones we're interested in-- have internal 
buffers. the distinction between a casual push (update) operation and 
the last one would allow to correctly flush any intermediate bytes that 
may exist.
* to allow for hooking Transformers together and to a Cascade, a 
'minimal-output-size' in bytes is necessary.  the trivial case of a 
value of 1 for such attribute practically means that no output 
buffering is needed --which is independant of buffering the input if 
the Transformer implementation itself is block-based.


Finally Transformers may be wired to pre-process or post-process data 
fed into an Assembly, hence the following general diagram:

I -> preT1 -> preT2 -> ... -> Cascade -> postT1 -> postT2 -> ... -> O

nothing that i can see, would prevent the same type Transformer from 
being used for either pre-processing or post-processing purposes.


examples of Transformers that may be of practical use are: 
PaddingTransformer, CompressionTransformer, HashTransformer.


> ... what I would like is to have an
> Assembly also have a way to generate keys for the Stages it contains,
> either by chopping up a very long key passed in the attributes map,
> or generating it with a PRNG (possibly implementing a PBE KDF).

these could be actions that are implemented as part of the init() method 
of the concrete Stages.  Different implementations can have different 
behaviours (interfaces) that would translate in specific implementation 
of their init() methods.  or, we can implement the different 
behaviours, in the one ModeStage, by coding the different behaviours as 
function of some set name/value pairs in their attributes Map and set 
appropriate values in the Map before calling the delegate's init() 
method.  (the latter being more practical albeit 'obscure.'  
nevertheless good documentation should address this).

let's make a list of the features we'd like the Stage to be capable of 
handling:

(a) raw user-supplied key material is obvious,
(b) source of randomness for things like IV and nonces,
(c) what else?

we may have to tackle thread-safety in our implementations to cater for 
the case where the same PRNG instance is used for both (a) and (b).


cheers;
rsn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Que du magnifique

iD8DBQE+e/L1+e1AKnsTRiERAwbvAKCxABaDWwXA+tWhnqDASyEfakP6GwCg/u6u
usdBopovHDXC739k1rj/SF0=
=eaf3
-----END PGP SIGNATURE-----