For CMS EnvelopedData, it would be very useful to have an
UnprotectedAttribute containing a DigestInfo (as defined in PKCS#1) with a
hash of the encrypted data.
DigestInfo ::= SEQUENCE {
digestAlgorithm DigestAlgorithm,
digest OCTET STRING }
I proposed something like this a while back to get around the patent mess
surrounding the encrypt+authenticate modes of operation, and the response was
pretty underwhelming. Specifically though, you want a MAC, not a digest, to
protect the content. PGP uses a straight hash, but protects it by encrypting
it alongside the content. If you use a hash then besides the obvious weakness
of not protecting it from modification, you also leak information about the
content in the hash.
Hi Peter:
Actually since the hash is generated by digesting the encrypted data,
no information would be leaked, since that data is encrypted with
random session keys, the resulting hash would be random as well.
There is no signifigant advantage in using an HMAC, and the encrypted
data integrity, and hence the unencrypted data integrity can be verified.
You are correct though, since the hash in an UnprotectedAttribute, it can
be replaced by an attacker. This would not gain the attacker any info on
the data itself, but the attacker would be able to corrupt the encrypted
data, and the recipient would not be able to verify its integrity since
they could replace the hash.
But that is why I am interested in place a CMS SignData structure inside
the encryptedContent of a CMS Enveloped structure, since a digital
signature would verify data integrity, originality, and more.
This would be essential when the encrypted data is detached from the CMS
EnvelopedData structure, which occurs when the optional encryptedContent is
not present. If one has either the detached encrypted data or the CMS
EnvelopedData, then this hash would greatly assist in finding a match for the
other.
OK, that's a quite different use for what I was proposing it for - I was after
integrity protection of the content. This is something that no current CMS
mechanism provides, but which a great many users expect as being provided when
they use encryption (see Simpson Garfinkel's thesis). Adding a MAC as PGP has
would ensure that the behaviour of a CMS envelope met user's expectations.
Correct, using a HMAC in an UnprotectedAttribute would be a method of
verifying data integrity, but it would not be useful in finding a match
between detached encrypted data and a CMS envelopedData structure.
Prehaps we need two UnprotectedAttribute for the CMS EnvelopedData
structure. One attribute for matching of detached encrypted data, and
the other attribute for data integrity that is protected. I would be
open to any creative suggestions on a way for us to solve both problems
with a single attribute.
Thanks in advance.
Alicia.