[GNU Crypto] Re: Assembly (long)

[Casey Marshall]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Raif S. Naffah wrote:
| hello Casey,
|
| 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!

| * 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.

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?

|>... 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.

| 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).
|

- --
Casey Marshall || address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+fQj1gAuWMgRGsWsRAuXcAJ9umy5Y+bkceblG7QuWWrwW9UqVbgCfaqhJ
86zWUSgX37hyV+BJ2vuhefg=
=pqly
-----END PGP SIGNATURE-----