Subject: digested-data, surreptitious forwarding, D-H

From: Trevor Perrin <[email-masked]>
Date: Fri, 26 Jul 2002 14:32:25 -0700

With more diligence I probably could've answered these from the archives.
But a few questions:

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)?

2) At some point I thought there was an Internet-Draft for a signed
attribute to address Don Davis' surreptitious forwarding concern.  I don't
see it now.  Has that been dropped, or has some other fix been incorporated
somewhere?

3) I see that Diffie-Hellman key pairs can be encrypted to, using either
static-static or ephemeral-static modes.  It seems like a Diffie-Hellman key
pair should be able to sign as well, using something like a static-ephemeral
mode.  Is there a cryptographic reason why this can't/shouldn't be done, or
is it just incidental that it isn't supported?  

The reason it seems like this might be useful is that Diffie-Hellman
agreement values can be cached, so a signer could perform lots of signatures
efficiently with such a key pair, which could be useful for something like a
DOMSEC gateway, which may have high volume mail flows and large key pairs.

Trevor

---

From: Trevor Perrin <[email-masked]>
Date: Fri, 26 Jul 2002 19:28:32 -0700

scratch question 3, this week has fried my brains more than I thought..

> -----Original Message-----
> From: Trevor Perrin [mailto:[email-masked]]
> Sent: Friday, July 26, 2002 2:32 PM
> To: [email-masked]'
> Subject: digested-data, surreptitious forwarding, D-H
> 
> 
> 
>

---

From: [email-masked] (Peter Gutmann)
Date: Sun, 28 Jul 2002 18:19:40 +1200 (NZST)

Trevor Perrin <[email-masked]> writes:

>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.

---

From: Trevor Perrin <[email-masked]>
Date: Sun, 28 Jul 2002 15:46:34 -0700

Interesting, I'd assumed that you could do multiple layers (like a
digestedData and envelopedData, or signedData and envelopedData) in a single
pass, by hashing and then encrypting each content block, then moving to the
next one, etc..  You're saying that this isn't possible, but the scheme
below can be done in one pass?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Saturday, July 27, 2002 11:20 PM
To: [email-masked]; [email-masked]
Subject: Re: digested-data, surreptitious forwarding, D-H

>In the case of encrypted but not signed mails, doesn't this leave the
message
>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.

Peter.

---

From: Trevor Perrin <[email-masked]>
Date: Sun, 28 Jul 2002 15:59:24 -0700

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: [email-masked] [mailto:[email-masked]]
Sent: Saturday, July 27, 2002 11:20 PM
To: [email-masked]; [email-masked]
Subject: Re: digested-data, surreptitious forwarding, D-H

message

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Mon, 29 Jul 2002 15:55:10 +1200 (NZST)

Trevor Perrin <[email-masked]> writes:

>next one, etc..  You're saying that this isn't possible, 

It isn't, because of ASN.1 encoding restrictions.  Changing a single byte of
inner content can change several bytes of outer content due to variable-length
length-of-length encoding, and there are some data lengths which can never be
achieved, eg. when you move from a short-encoded data length to a long-encoded
one and adding a single byte to the data also increases the length-of-length
value.  When you combine this with data blocking requirements and requirements
for PKCS #5 padding, it becomes unworkably complex to implement and test unless
you buffer an entire message, in which case you're just doing a standard two-
pass encoding.

>but the scheme below can be done in one pass?

Sure, since the encoding is one-step.  With DigestedData you're encapsulating
the entire data block just to add a 20-byte hash at the end.  All this does
it add the hash at the end of the EncryptedData.

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Mon, 29 Jul 2002 15:59:03 +1200 (NZST)

Trevor Perrin <[email-masked]> writes:

>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

You can't prevent a rollback attack, since you need to integrity-protect the
fact that integrity-protection is being used, which is a catch-22.  The fix
would be something like what was done in SSLv3 which messes with the RSA-
wrapped key data to include the version, but this is incredibly ugly for CMS
which can't assume PKCS #1 RSA padding.  I was just assuming that the MDC would
be by prior arrangement, and the recipient would reject any messages without
the MDC - for the EDI application, this is the standard way to handle message
exchange.

Peter.