Tom Zerucha, <tzeruch(_at_)ceddec(_dot_)com>, writes:
1 byte version (should be 1)
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.
Maybe, although with a new packet type it is questionable whether you
have to start that high. It's not like there are any V1-V4 packets of
this type out there. But for consistency maybe V5 is best.
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.
The point is that if no such new version of PGP is available, the
integrity protection is lost. I think we can make a design where
integrity protection can't be stripped away. Shouldn't we do so?
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.
But still possible - you can make tweaks to encrypted data as I described
earlier.
(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.
There is no point in having multiple MDC's with different algorithms.
There is not even any point in supporting more than one algorithm.
The attacker, when he makes his changes, either truncates the message
or can't help unpredictably corrupting a block of the message. A simple
SHA hash will detect either of these changes with overwhelming security.
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?
We have spoken to NIST about this, and they say that they are acutely
aware of the need to standardize on a larger hash algorithm, and that
they are working very activelly on it. However they have not given us
a fixed date for when they will have a result.
Hal Finney