On Wed, 12 May 1999 hal(_at_)rain(_dot_)org wrote:
I am not arguing against an MDC packet, though I don't see as much problem
with the extra field bytes in the existing signature/validation packet.
They don't have to be in the existing signature packet (though I would
want things like version and algorithm bytes and length processing to make
them orthogonal with every other packet type). I am arguing against a
required trailing naked MDC field unique to a new encryption packet.
To clarify, it would be encrypt( literal(data), MDC ), MDC being the new
packet containing the hash of the literal. And encrypt( "mdc follows",
literal(data), MDC) would be even better.
How about if the "encrypt" is a different packet number, something like
"encryptwithmdc". Then this would be:
encryptwithmdc( <plaintext packet>, <mdc packet> )
That too would work, but if you want to give (one or more) hash algorithm
IDs, or versions (we might want to change something with the MDC for 3.0),
that would have to go into the Ew/MDC header and be subject to the attack
you pointed out. It can be an Ew/MDC function, but all MDC info will need
to go into the encrypted area. (And if encrypted, you could have an MDC
header specifying "no algorithms" for those who want to use just the new
algorithms but without MDC).
If these could be resolved, I would say the whole Ew/MDC stuff is a
SHOULD, but if so SHA1 is a MUST, rmd160 a SHOULD, none or others a MAY,
for the hash stuff. I suspect TwoFish to be the MUST, the existing
SHOULD/MUST algorithms as SHOULDs here.
(assuming we aren't locked to SHA1 by having an MDC prefix packet in the
encrypted stream - note that if this header were checksummed you might not
need any other quick-check bytes).
We would still need to decide whether to change to a more conventional
IV handling, and if so how to handle check bytes. I will tell you
frankly that Phil likes the pseudo-IV; he invented it. I have been
the main one pushing for a more conventional handling of the IV,
because I don't believe the pseudo IV offers any security advantage.
It's unusual but has no security advantages. This is generally not a
good thing in cryptography. So I'd like to make it more conventional.
Uri suggested that a conventional IV is less desirable from a security
point of view, but I'd like to hear more about the reasons.
This is not the highest priority item for me so if everyone else likes
the pseudo IV I can accept it. But I would prefer to know a good reason
for doing it that way.
I can go either way here. I either pass the data directly to the
algorithm, or through my pseudoIV handler. However I suspect it might be
nicer (especially if hardware implmentations of crypto become common) to
do things in the more conventional way.
Does GPG have any plans on allowing MDCs with the other algorithms? Other
hash algorithms besides SHA1?
I would suggest that we should allow it with other algorithms in the spec.
However initially implementations should accept it but not create it
except for Twofish.
As for other hash algs, I have described how this could potentially open
up a security hole (by letting an attacker tweak the hash-alg field).
Not if the field is encrypted.