If the encrypted digest is attached as an unprotected attribute, it could be
removed by an adversary, presumably? In which case, since the recipient
would have to know how to handle CMS messages either with or without the
encrypted digest for backwards compatibility, the recipient wouldn't notice
anything amiss. So maybe that's an argument for the digest to be inside the
envelopedData encryption, not as a separate thing.
-----Original Message-----
From: pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz
[mailto:pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz]
Sent: Saturday, July 27, 2002 11:20 PM
To: Tperrin(_at_)sigaba(_dot_)com; ietf-smime(_at_)imc(_dot_)org
Subject: Re: digested-data, surreptitious forwarding, D-H
Trevor Perrin <Tperrin(_at_)sigaba(_dot_)com> writes:
1) I'm surprised S/MIME doesn't use CMSs' digested-data with
enveloped-data.
In the case of encrypted but not signed mails, doesn't this leave the
message
vulnerable to things like cut-and-paste attacks (where an attacker reorders
ciphertext blocks, so upon decrypting the recipient sees reordered
plaintext)?
Funny you should mention that, I was discussing this recently with someone
who
was quite concerned about this (they were FTP'ing large encrypted EDI
messages
around). What they wanted was a modification to EncryptedData to include a
hash inside the encrypted content, rather than DigestedData, which would
require a second pass (they encrypt the content as they stream it in and
out,
so anything requiring two passes is a non-starter). I have the feeling that
more people would be asking for this if they had any idea that encryption
doesn't guarantee integrity protection.
My suggestion was to put it in as an unprotectedAttrs, just encrypting the
MDC
after the content. In other words, hash the data before you encrypt it,
then
after you've finished encrypting the data encrypt the hash and store it as
an
unprotectedAttrs. This is a bog-standard way of appending an MDC to the
data,
and is compatible with the existing format. The MDC info is put in as
originatorInfo, which is a bit of a kludge but seems to be the sensible
place
for it. This would need a new originatorInfo type, but that's the only
change
necessary.
If there's any support for this sort of thing, I could crank out an
informational RFC for this fairly quickly.
Peter.