Werner Koch, <wk(_at_)isil(_dot_)d(_dot_)shuttle(_dot_)de>, writes:
We should invent a new encrypted data packet which is used for
encrypted messages with MDC. Suggestion:
Packet number ???
1 byte version (should be 1)
1 byte MDC method (should be 2 to match SHA, or 0 to disable MDC)
1 byte number of extra bytes (m) at the end of the encrypted text
From now on CFB encrypted with an IV of all zeroes without
any strange syncing.
n byte random data used as IV (n=blocksize of the cipher)
2 byte the last two bytes of the random data.
k byte message
m byte hash used for MD
In my other message I pointed out the problem that an attacker could
perturb some of these header values. With that in mind let us look at
these fields:
1 byte version (should be 1)
This is probably a good idea. If perturbed by an attacker to a later
version, the software will refuse to process the packet. We need
to consider though whether, if we later move to a higher version, an
attacker could execute a rollback attack by changing a V2 to a V1.
We can deal with that at that time by making sure that V2 and V1 look
very different (assuming we ever need to create a V2).
1 byte MDC method (should be 2 to match SHA, or 0 to disable MDC)
This one worries me. It allows an attacker to turn a 2 into a 0. Also,
is there an implication that it can be something other than 2 or 0? Like,
1 means MD5? If so, this again offers an attacker more opportunities to
mess with the receiver. The attacker could change the hash algorithm to
something like 6. Now the receiver doesn't know if this is a legitimate
message from a later version of PGP that supports hash algorithm 6, or
whether it is a messed up message by an attacker. If we choose a fixed
hash algorithm this ambiguity cannot arise.
I would prefer to leave this field out. If you use the new packet format
at all, you get the MDC, using a fixed hash of SHA-1.
1 byte number of extra bytes (m) at the end of the encrypted text
From now on CFB encrypted with an IV of all zeroes without
any strange syncing.
We would then not need this, as the value would always be 20.
n byte random data used as IV (n=blocksize of the cipher)
OK. I continue to believe that a *conventional* IV is most desirable in
terms of explaining what we are doing to others in the field. The "pseudo
IV" we have now is hard to explain. I had to go to some lengths in
getting our FIPS 140 certification (a standard security certification)
to show that our way was just as good as the regular way.
2 byte the last two bytes of the random data.
You have not shown whether these are encrypted. I presume that they are,
and that these are meant to be check bytes used to detect when we have the
right session key. This way of doing it does not work well when the IV
is unencrypted, as is done in virtually every other cipher in the world
except PGP. With an unencrypted IV the two check bytes are known, thus
putting two bytes of known plaintext right at the start of the message.
Since one of the goals of the new encryption packet is to regularize our
methods and bring them into conformance with the practices used by other
professionals, I believe we should do check bytes slightly differently.
My proposal was that we have four bytes, two random ones and then those
same two random ones repeated. These would all be encrypted. It's not
known plaintext although there is a certain amount of redundancy in the
data, which redundancy is necessary for them to serve as check bytes.
k byte message
m byte hash used for MD
These, too, would both presuambly be encrypted. The hash size should be
fixed if we fix a hash algorithm.
Uri proposed another scheme for better detection of wrong keys - we
should consider to use this.
His proposal, from http://www.imc.org/ietf-open-pgp/mail-archive/msg02471.html:
Make the "pseudo-IV" prefix partially non-random - i.e. the last two
bytes being checksum for the other 14. No big deal security-wise and
noticeable help in detecting the right key.
This isn't too bad for 128 bit block ciphers like Twofish or AES, but as
a general principle we would need to apply it to all ciphers, including
64 bit block ciphers. I don't like taking away 16 of the 64 bits of IV
in that case. I can't name a specific attack this would cause but it
doesn't feel right to give up that much of the IV.
Also, of course this only works with the pseudo-IV. As I wrote above, our
use of a pseudo-IV is an oddball quirk that no one else does. In order to
generate support for the standard we should try to move away from peculiar
features like this and towards the conventional ways of doing things.
"If a cipher with a blocksize > 64 bits is used, this new packet
format SHOULD be used".
I agree that it would be sensible to encourage the new format when we go
to new block ciphers. Unfortunately the next version of PGP will have
Twofish support without MDC, since we were not able to come to consensus
here (and it doesn't look like we are coming any closer).
To clarify thinks for the old encypted data packet (9), we should
say that the special CFB mode is used with all blocksizes.
By this, do you mean the special sync operation after reading the pseudo
IV and check bytes?
Hal Finney
Network Associates, Inc.