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

[Casey Marshall]

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

Raif S. Naffah wrote:
| On Sunday 23 March 2003 12:08, Casey Marshall wrote:
|
|>Raif S. Naffah wrote:
|>| On Friday 21 March 2003 20:13, Casey Marshall wrote:
|>| [...]
|>
|>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.
|

I geddit. Sometimes it's easy to take diagrams too literally :P

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

An Assembly would contain one or more implementations of an interface
such as:

interface OutputCallback {
~   public void output(byte[] buf, int off, int len);
}

...which is implemented by the library's user, and passed (perhaps) to
the init() method of the Assembly.

Then whenever any bytes come out the end of the chain, *all* of it is
passed to the output() method of the callback objects, which do with it
what they will. This way the programmer does not have to worry about
output buffers when feeding the Assembly input.

|
| [diagrams pointing everywhere ... ]
|
| 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!
|

I was thinking of implementing modes as Transformers, for example OFB
would work as:

~   OFB(input-block) {
~      if (first time) {
~         b = Cascade(IV);
~      } else {
~         b = Cascade(b);
~      }
~      output-block = input-block ^ b;
~   }

...but now that I'm looking at this it might not make sense, or it may
be unnecessary.

Cheers,

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

iD8DBQE+fWORgAuWMgRGsWsRArLcAJ4tI4htagpxGk4K9jWBxiPd6WolngCcDSCY
KV1AAgEuPxp+jpaP4kCjbGw=
=3NDk
-----END PGP SIGNATURE-----