Re: [GNU Crypto] Re: Assembly (long)

[Raif S. Naffah]

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

On Sunday 23 March 2003 12:08, Casey Marshall wrote:
> Raif S. Naffah wrote:
> | On Friday 21 March 2003 20:13, Casey Marshall wrote:
> | [...]
> | 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
> |                                       +-----+
>
> If I'm reading this right, wouldn't the backward direction need to
> run Cascade -> T2 -> T1? If one of these were an inflater, we
> certanly would want to decompress the data after it was decrypted,
> not before!

of course not :-)

but since the Cascade is block-based, it's the Transformers that know 
how/when to invoke its update() method.  whether they call it before or 
after they do some intelligent things to the data, it's up to them.  
from the outset, it all looks like they (the Transformers) get the 
first byte of the cherry.


> | * 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.
>
> Another option for this case could be to implement output from an
> assembly with a *callback*. This way whenever data has come all the
> way through the chain, all of it is fed into a user's function, no
> buffering needed, except for internal buffering for algorithms that
> require it.

i'm not quite sure what you mean.  can you give an example?

would wrapping the Assembly into a stream, do the same thing?


> Callbacks seem to be popular with codec writers, since the emphasis
> is on transforming data, not buffering data that has been coded.
>
> | 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.
>
> A pre/post-processing pair can also implement an "outer mode" -- a
> mode that is applied to a Cascade as though it were a simple cipher.
> I think this may in fact be *necessary* in order to implement certain
> modes with multiple ciphers, since wouldn't "3DES-OFB" with Cascades
> look something like this:
>
> ~         IV1              IV2              IV3
> ~          |                |                |
> ~          +---<---+        +---<---+        +---<---+
> ~          |       |        |       |        |       |
> ~          V       |        V       |        V       |
> ~      +-------+   |    +-------+   |    +-------+   |
> ~      | E(K1) |   ^    | D(K2) |   ^    | E(K3) |   ^
> ~      +-------+   |    +-------+   |    +-------+   |
> ~          |       |        |       |        |       |
> ~          +--->---+        +--->---+        +--->---+
> ~          |                |                |
> ~          V                V                V
> ~  IN --> XOR -----------> XOR -----------> XOR ------> OUT
>
> Which, unless the maths somehow work out, would be different than
> real 3DES in OFB mode?

i think it is indeed different, OFB(DES-EDE) looks more like this:

   IV ->--+---<----------------<----------------<---+
          |                                         |
          |       +--------+       +--------+       |
          V       |        V       |        V       |
      +-------+   |    +-------+   |    +-------+   |
      | E(K1) |   ^    | D(K2) |   ^    | E(K3) |   ^
      +-------+   |    +-------+   |    +-------+   |
          |       |        |       |        |       |
          +--->---+        +--->---+        +--->---+
                                            |
                                            V
  IN ------------------------------------> XOR ------> OUT

nevertheless, it may threoretically be the case; but this (if i 
underrstood you correctly) would imply building a Cascade from 3 
Assemblies.  i'm sure we can coerce the Stage --the building block for 
a Cascade-- to resemble an Assembly and v/v, but i'm not convinced it 
would be the right thing to do.

the above is a visualisation of _the/a_ Cascade.  i havent tried it but 
my guess is that the Cascade structure we have can do this with no 
sweat.  we probably would get more value in allowing Modes to take 
Cascades besides BlockCiphers --because inherently Cascades _are_ block 
ciphers-- but that's how far i can see.

the latter can be as simple as adding a getInstance() method to the 
ModeFactory and one CascadeAdapter class in the mode package!


> |>... 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?
>
> Generating keys and IVs from passwords, of course.
>
> Public-key exchange methods would be useful, but since they usually
> require multiple steps it doesn't seem practical to implement them
> within the init() method...

agreed.  i'll work on the KDF and randomness bits this week and will 
post my results later.


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

iD8DBQE+fTLi+e1AKnsTRiERAwsFAKCsscDvPXdxMLqlMhVuvjOA6u7IsACfS8vu
8ro5grpVZDTtYl4hz1b51Ow=
=XADT
-----END PGP SIGNATURE-----