ietf-smime
[Top] [All Lists]

Re: Strawman for adding a MDC to encrypted data

2006-12-08 13:46:15

Peter:

I have no objection to the proposed unauthenicated attribute. It seems like a straightforward addition.

I think that authenticated encryption (like AES-CCM and AES-GCM) are also highly desirable solutions. I would like to see a CMS protection content type that supports these. The AES-CCM and AES-GCM algorithms are not encumbered, but as you say, other authenticated encryption modes are.

I have thought about support for AES-CCM and AES-GCM with EnvelopedData, but these algorithms have the cool feature that they can authenticate some data that is not encrypted. This is not one of your concerns, but it seems desirable to support both authenticated and unauthenticated attributes as is done with SignedData.

Russ

At 01:36 AM 12/8/2006, Peter Gutmann wrote:

Over the years there have been various papers published on messing with CBC-
encrypted data to perturb the plaintext in a predictable way.  The OpenPGP
folks addressed this issue fairly quickly by adding an MDC to their encrypted
content, but S/MIME doesn't address it at all.  What makes this issue a lot
more troublesome is that the public perceives encryption as providing data
integrity protection, a service it in fact doesn't provide (they also perceive
signing as providing no data integrity protection, see Garfinkel 2006).  Short
of educating the entire world's email-using population about cryptographic
security issues, the other possible alternative is to make the encryption act
in the way they think it acts.

(There are other useful applications of the added MDC as well, e.g. when
 wrapping private keys for storage the MDC protects against the Klima-Rosa
 attack, which OpenPGP keys are protected against but S/MIME ones aren't).

A simple fix for the problem is to add an MDC to EnvelopedData.  There are
alternatives, but none are practical: wrapping the EnvelopedData in
AuthenticatedData collapses under the weight of key management and
implementation issues, using a combined encrypt+authenticate mode is either
impractical due to patent concerns or has severe implementation problems
because these new modes will take an arbitrarily long amount of time to become
widely supported, etc etc.

The MDC approach is a relatively straightforward change that simply runs a
hash over the ciphertext and attaches the encrypted form of the hash (using
the content-encryption key used to encrypt the rest of the content) to the
EnvelopedData as UnprotectedAttributes.  So the process becomes:

  ciphertext = encrypt( plaintext );
  MDC = encrypt( hash( ciphertext ) );

Hashing the ciphertext protects against other attacks relating to manipulating
of PKCS #5 padding content.  The use of the content-encryption key/cipher for
the MDC tag avoids key management issues.  The OpenPGP folks have been doing
this for some years now, and it has the approval of the crypto community.

The only problematic issue is how to indicate the use of the MDC algorithm.
Some options are:

  Use a version number of 5 to indicate (implicitly) the use of a SHA-1 MDC.

  Add something to the RecipientInfos as an OtherRecipientInfo that simply
  contains the hash algorithm details.

  (As above, but with OriginatorInfos).

The second option is a bit of a kludge, but seems to be the cleanest way to do
it.  The overall changes are very minimal, a new UnprotectedAttribute type
with the MDC, a new OtherRecipientInfo type, and a bit of code to run a hash
alongside the en/decrypt.  In my trial implementation (excluding the
attribute-handling) there were only about a dozen lines of code required
because the hashing is already performed for SignedData so all it required was
turning on the hash flag if an MDC was specified in the RecipientInfo.

Is there any support for adding this?  I should be able to get a draft out
fairly quickly, and from a check with two other implementors producing
interoperable implementations should be fairly easy.

Peter.