ietf-openpgp
[Top] [All Lists]

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

2006-12-14 10:38:01

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.

<Prev in Thread] Current Thread [Next in Thread>