Subject: Is there any published analysis of OpenPGP's MDC?

From: [email-masked] (Peter Gutmann)
Date: Mon, 11 Dec 2006 16:09:13 +1300

Subject line says it all, is there any published analysis of the
strengths/weaknesses of OpenPGP's use of MDCs (encrypted SHA-1 hash) for
private keys and data?  I've seen various informal arguments that it should be
OK (and also informal ones that it may not be OK), but nothing definitive.

Peter.

---

From: Adam Back <[email-masked]>
Date: Tue, 12 Dec 2006 08:02:54 -0500

I think one has to consider the attacker may know the hash, and also
given the recent issues around SHA1 be able to with some effort
compute related hashes of modified documents, tho at present with many
limtiations.

With that background, CFB and CBC encryption remain quite malleable,
and a number of surprising things have been shown to be possible
through it in attacks on other protocols.  (Part of the reason for
introducing the MDC!)

Personally I think its just more conversative to use a MAC, like
HMAC-SHA1 with a separate key.

Adam

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 13 Dec 2006 16:31:57 +1300

Adam Back <[email-masked]> writes:

>I think one has to consider the attacker may know the hash, and also given
>the recent issues around SHA1 be able to with some effort compute related
>hashes of modified documents, tho at present with many limtiations.

Yeah, I was assuming known plaintext.

(Actually one way to make this more difficult is to encrypt (say) 128 bits of
zeroes after the message for which the ciphertext gets hashed but not
transmitted.  This eliminates the known-plaintext properties).

>With that background, CFB and CBC encryption remain quite malleable, and a
>number of surprising things have been shown to be possible through it in
>attacks on other protocols.  (Part of the reason for introducing the MDC!)
>Personally I think its just more conversative to use a MAC, like HMAC-SHA1
>with a separate key.

Where would you get the separate key from?  There's no easy way to get a
separate MAC key from a PKC-encrypted conventional key.  Specifically, if
you're using something like a smart card that only supports "unwrap RSA-
encrypted key into 3DES object", you can't even get at the key.

(I realise there are various kludges possible, but I'm not aware of any
cryptographically sound way to do it.  You can't use one key for both
encryption and MAC, deriving the MAC key from the encryption key compromises
the MAC key if the encryption key is compromised, feeding both into a PRF
means you lose backwards-compatibility with existing code that doesn't know
the encryption key has to go through a PRF first, etc etc).

Peter.

---

From: Adam Back <[email-masked]>
Date: Thu, 14 Dec 2006 12:11:15 -0500

Other than backwards compatibility and smart card considerations, I
would either send two independent keys inside the key-exchange (if
there is space, should be at RSA 1024+ and standard padding), or derive
a pair from a master using KDF2 from p1363.

Are smart cards a concern with PGP implementations?

Is backwards compatibility a concern for this mode?  Aren't we talking
about a new mode... using CBC instead of CFB, and using a HMAC-SHA1
(or well so far SHA1) and using only AES.  I guess you're saying the
issue is there is no info in the v4 / v5 key to say "can read MDCs".

But are there sensible ways to put a tag that will be safely ignored,
but not deletable without screwing up the format?  Trying to
back-patch that onto the existing protocol in a way that old clients
will tolerate sounds like asking for security trouble in a kind of
"version rollback" attack of simply removing the MDC tag.

Adam