I just spent a bit of time reviewing the previous discussions on fixes
for Gary Howland's message modification attack.
In general I like PRZs proposal, and it seems well thought out.
Starting from PRZs functionality list, I agree with the design.
However i think the functionality list has a gap: it doesn't cover
that many people will want to continue using IDEA, 3DES, blowfish.
There will remain no way to prevent message modification for unsigned
messages for these.
The point that PRZ made:
However, Phil points out that it is often the case that a signature
cannot be verified because the signing key is not available. In
that case there is no integrity protection at all.
is important too, and I therefore think it would be quite useful to
have a MDC in signed and encrypted messages (as well as just encrypted
messages) for the non-large ciphers too.
Now if one adds to PRZs functionality list that we want this to be
backwards compatible so that non-large ciphers can use it, you need a
way to send a MDC inside an encryption envelope such that it won't
cause current implementations to barf. For this the appended hash
method doesn't work (or at least I can see no elegant way to make it
work).
For this reason I would argue for a new signature type `symmetric
MDC', where you put a hash (or a MAC) in a signature packet.
in previous discussions Tom Zerucha made this point:
: a signature algorithm
: of 0 means the message digest is stored in the clear (maybe as a
: MPI), and leave the rest of the format alone. Old implmentations
: should fail gracefully with "unknown signature algorithm". The
: onepass signature header lets the "MAC" be at the end yet insures
: that someone can't just delete the "MAC".
Some additional benefits of a symmetric signature are that:
- the attacker is left guessing whether or not the recipient will
check the MDC, even for all existing pgp2.x, pgp5.x and pgp6.x
implementations
- if the recipient later upgrades he can at that later time check the
MDCs and detect the modification after the fact
I argue that these benefits make it worth favoring the new signature
type over appended hash approach.
I agree that the addition of large ciphers would be a good time to
phase in the other proposed changes. Perhaps even, we could clean up
the length business at the same time, which would allow eventual
deprecation of sections 4.2.1, 4.2.2 and 4.2.3 The new-format packet
lengths (4.2.2, 4.2.3) are even more complicated than the old ones
(4.2.1).
Adam