Is there any published analysis of OpenPGP's MDC?

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.

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

On Mon, Dec 11, 2006 at 04:09:13PM +1300, Peter Gutmann
wrote:
> 
> 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.

Adam Back <adamcypherspace.org> 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.

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

On Wed, Dec 13, 2006 at 04:31:57PM +1300, Peter Gutmann
wrote:
> 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.