Hi,
putting the patent mess aside, there are also a few other question
involved in a new encryption mode:
1. Exactly one mode defined by a new packet number
or a new packet with a parameter to define the mode?
2. Bind the mode to a certain cipher algorithm? For example only allow
a mode with AES.
3. How can we do early detection of corruption? When decrypting
several gigs we should be able to detect corrupted data after having
processed, say, one gig. Shall such a feature be configurable?
Shall we link it to partial length headers.
My ideas here are:
re 1. A new packet with a parameter to define the actual mode. Make
one mode mandatory. Additional parameters should have a length
header so that parsers have an easier way to parse the header
even if they don't implement that mode.
The rational for this is to allow for some experimentation and
separate the packet format from the finally chosen mandatory
mode.
re 2: Binding a mode to an algorithm makes testing easier. This will
also make implementing stream cipher modes easier because it
allows to blur the distinction between cipher algorithm and mode.
re 3: The simplest idea would be to use fixed chunks of the ciphertext
and either link them together using a counter or the hash of the
previous authentication tag. The packet header would give the
length of the chunks in blocks. It needs to be decided whether a
final one-block chunk is okay.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
pgpyrZgJE65kY.pgp
Description: PGP signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp