On Tue, 11 May 1999 hal(_at_)rain(_dot_)org wrote:
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
Actually 5 would be more consistent. Elsewhere 3 is used for PGP 2.6
level packets, 4 for PGP 5-6. Anything below 5 for this new packet would
be an error.
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.
The receiver would have to check the message on a later version of PGP.
If 6 was a legitimage algorithm ID the hash would work. The same problem
arises if something shifts between any two valid IDs with the same length
hash, the second of which would might not be supported.
One note is that if you use my idea of an MDC-ahead prefix packet, and
MDC-result packet bracketing the plaintext, the MDC specification is
encrypted too, making this attack difficult.
(CTB,len=2) 5 2; plaintext; (CTB, len=22) 5 2 <20 byte result>;
Note that this would allow multiple MDCs with different algorithms
(the hash would only be on the plaintext), so you could have
[MDC: rmd160 follows][MDC: SHA1 follows][plaintext][MDC: SHA1 result][MDC:
rmd result].
Or these could be merged, (CTB len = 4) 5 2 3 0;/ (CTB len = 44) 5 2 <20
byte sha1> 3 <20 byte rmd> 0; or something similar.
-----------------------
While we are on the subject, last year at this time there was a suggestion
to drop El Gamal. The objection was mainly that the only other two
alternatives had other problems - RSA was patented, and DSA limited the
hash length to 160 bits, so although you could do larger keys, they added
no security since the hash was the weakest link. ElGamal allowed for
longer hashes and (if there were no flaws in the implementation) more
functional bits in the public key.
Various suggestions were made including a doublewide DSA or something
similar including coming up with a hash system.
Has anyone followed up on this?