Adam Back says:
Re. the discussion of how to cope with combined random-prefix/checksum
method with stream ciphers, this is a not an immediate problem because
there are no stream ciphers listed as MAY/SHOULD/MUST algorithms
I agree. However this shouldn't stop us from figuring out how to
deal with them, especially if a straightforward solution can be
found (I even claim it's obvious :-).
A stream cipher would suffer even worse from attacks modifying known
plaintext than conventionally encrypted data without MACs.
Certainly. Picking nits, it's not MACs that you mean, it's MDCs.
[Modification Detection Codes].
A stream cipher would also be problematic if used for conventionally
encrypted messages, and conventionally encrypted private keys on the
private keyring -- the symmetric key is derived from the passphrase,
which means you get the same key each time.
First - an observation. Just like a block cipher must have an IV (PGP
side-stepped this by prepending the message with random stuff), a
stram cipher must have a stream offset.
For messages it may be not as crucial, as the symmetric cipher key is
supposed to be random anyway (still IMHO having an offset helps).
For the keys to have a stream offset can mean the difference between
secure and insecure.
Even using the Symmetric-Key Encrypted Session Key packets are dubious
unless you start using a block cipher for the SKESK packet.
I do not see why.
This suggests to me that stream ciphers need to be designed for
properly before being put in, and that this can wait for next version.
(:-) No arguments from me.
: Note that for an algorithm that has a larger block size than 64
: bits, the equivalent function will be done with that entire block.
Though Jon and Tom are it sounds like suggesting changing 8 and 10 to
blocksize and blocksize+2 to clarify.
This clarification is needed, I think.