Subject: Re: Agree with PRZs MDC suggestion

From: [email-masked]
Date: Wed, 12 May 1999 13:21:06 -0700

Tom Zerucha, <[email-masked]>, 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

---

From: Tom Zerucha <[email-masked]>
Date: Thu, 13 May 1999 12:50:03 -0400

> 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).

> the pseudo IV I can accept it.  But I would prefer to know a good reason

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.

> up a security hole (by letting an attacker tweak the hash-alg field).

Not if the field is encrypted.