[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GNU Crypto] Assembly (long)
From: |
Raif S. Naffah |
Subject: |
[GNU Crypto] Assembly (long) |
Date: |
Sat, 22 Mar 2003 16:21:56 +1100 |
User-agent: |
KMail/1.4.3 |
-----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-----
- [GNU Crypto] Cascade Cipher API (long), Raif S. Naffah, 2003/03/17
- Re: [GNU Crypto] Cascade Cipher API (long), Casey Marshall, 2003/03/19
- Re: [GNU Crypto] Cascade Cipher API (long), Raif S. Naffah, 2003/03/19
- Re: [GNU Crypto] Cascade Cipher API (long), Casey Marshall, 2003/03/21
- Re: [GNU Crypto] Cascade Cipher API (long), Raif S. Naffah, 2003/03/21
- [GNU Crypto] Assembly (long),
Raif S. Naffah <=
- [GNU Crypto] Re: Assembly (long), Casey Marshall, 2003/03/22
- Re: [GNU Crypto] Re: Assembly (long), Raif S. Naffah, 2003/03/22
- Re: [GNU Crypto] Re: Assembly (long), Casey Marshall, 2003/03/23
- Re: [GNU Crypto] Re: Assembly (long), Raif S. Naffah, 2003/03/23