Tom Zerucha, <tzeruch(_at_)ceddec(_dot_)com>, writes:
And I am not saying it must be the signature packet or nothing. My
problem is with the 20 unencapsulated or unindicated hash bytes at the
end. Encapsulating them addresses all my major complaints. But that
would mean another new packet type or subtype.
OK, maybe we could do something along these lines.
Is he also completely and irrevocably opposed to having the hash as
anything except a naked 20 byte field at the end of the plaintext stream?
I recall that Phil and I did briefly discuss the idea of putting the
hash into a separate, following packet, and while he didn't like it as
much as integrating it, I don't think he objected to it.
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> )
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.
What about Geiger's OS/2 (mainly) implementation?
I'm not familiar with this one. Is there really such a thing?
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).
I believe we should stick with SHA-1. There is actually no need for a
cryptographically collision-resistant hash here, and in practice probably
something like a CRC would work. SHA-1 is overkill and even if it is
someday broken it will almost certainly still be more than adequate for
this purpose.
To restate my position, the MDC should be encapsulated in some kind of
packet consistent with the existing syntax and grammar. My preference is
for expanding the existing signature packet by adding a "zero" algorithm.
But I don't have any objections to a new MDC-only packet, especially if it
has a "MDC follows" prefix packet.
All I don't want is an unencapsulated fixed number of bytes implicitly at
the end of a packet.
I could go with this, along the lines Tom mentioned above, particularly
with the modification I suggested. How does this sound to others?
Hal