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

Adam Back <adam@cypherspace.org> Thu, 14 December 2006 17:37 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuuWc-0006lL-CB for openpgp-archive@lists.ietf.org; Thu, 14 Dec 2006 12:37:42 -0500
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuuWZ-0005GV-VV for openpgp-archive@lists.ietf.org; Thu, 14 Dec 2006 12:37:42 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBEHBQig049172; Thu, 14 Dec 2006 10:11:26 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBEHBQmI049171; Thu, 14 Dec 2006 10:11:26 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from mail.off.net (off.net [66.96.28.3]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBEHBPSK049163 for <ietf-openpgp@imc.org>; Thu, 14 Dec 2006 10:11:25 -0700 (MST) (envelope-from adam@mail.off.net)
Received: by mail.off.net (Postfix, from userid 948) id 3E369770464; Thu, 14 Dec 2006 12:11:16 -0500 (EST)
Received: by bitchcake.off.net (hashcash-sendmail, from uid 948); Thu, 14 Dec 2006 12:11:15 -0500
Date: Thu, 14 Dec 2006 12:11:15 -0500
From: Adam Back <adam@cypherspace.org>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Cc: ietf-openpgp@imc.org, Adam Back <adam@cypherspace.org>
Subject: Re: Is there any published analysis of OpenPGP's MDC?
Message-ID: <20061214171115.GA1988@bitchcake.off.net>
References: <20061212130254.GA1767@bitchcake.off.net> <E1GuKqb-0001SW-00@medusa01.cs.auckland.ac.nz>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <E1GuKqb-0001SW-00@medusa01.cs.auckland.ac.nz>
User-Agent: Mutt/1.4.2.1i
X-Hashcash: 1:20:061214:pgut001@cs.auckland.ac.nz::IPRLD1pv6xkuslk1:gCl
X-Hashcash: 1:20:061214:ietf-openpgp@imc.org::TiFztnfUh5p4YAjw:RAl
X-Hashcash: 1:20:061214:adam@cypherspace.org::4Uqix0PLaIvEPLgT:0S7
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5

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.