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

[Raif S. Naffah]

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

On Sunday 23 March 2003 18:34, Casey Marshall wrote:
> 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:
> |>| [...]
> |>| * 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.

ok; i (think i) see.  i'd like us to offer both PUSH and PULL models.  
implementing the callbacks instead of the update() and lastUpdate() 
returning some bytes, would simply replace the PUSH with a PULL model.  
instead, leaving the PUSH model as is, and offering a stream layer on 
top, would give us both.  e.g.

class AssemblyInputStream extends java.io.FilterInputStream{
   ...
}


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

yes, the two (Modes and Transformers) are not the same: Modes are 
block-based, Transformers are not.

i'm happy with what we have so far:

BlockCipher ------------------------------------>
    v
    +--> Mode ---------------------------------->
    ^     v
    +-->--+--> Cascade ------------------------->
    ^             v
    +----------<--+
                  v
Transformer --->--+--> Assembly ---------------->
                          v
                          +--> AssemblyStream -->


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

iD8DBQE+fa61+e1AKnsTRiERAxAjAJ9cwbCjGzTYQFa4iu1p8QpdLcRsywCg4ZUl
ln1kPKtsEJpUnS53eDJpilI=
=oXoX
-----END PGP SIGNATURE-----