Subject: authenticated encryption

From: Trevor Perrin <[email-masked]>
Date: Mon, 05 May 2003 17:01:40 -0700

Hello S/MIME,

I'm curious what this group thinks about adopting an 
authenticated-encryption cipher mode, such as:

EAX: 
https://www1.ietf.org/mail-archive/working-groups/cfrg/current/msg00223.html
CWC: 
https://www1.ietf.org/mail-archive/working-groups/cfrg/current/msg00224.html

Such a mode could integrity-protect S/MIME encrypted-only messages.  It 
could also defend against an oracle attack on signed-then-CBC-encrypted 
messages.  I'm not sure this attack is well known, so I'll describe it:

If the plaintext is a sequence of blocks P[1],P[2],.., and the ciphertext 
is a sequence of blocks where C[0] is the IV, followed by C[1],C[2],.., 
then we assume the attacker wants to verify a guess G for P[X], and knows 
the value of P[1] (the first blocksize bytes of the ContentInfo containing 
SignedData, which is just well-known ASN.1 header).

The attacker copies C[X] over C[1], and sets C[0] = G xor C[X-1] xor 
P[1].  If his guess is correct, then the new ciphertext C[1] will decrypt 
to the same plaintext P[1] it would have without his modifications - if his 
guess if wrong, the decrypted P[1] will have bit errors, which will 
probably cause an error in the recipient's software.

If the recipient is a person, she might respond saying "I can't read 
this".  If the recipient is a server (like an S/MIME MTA), it might respond 
with an error message, allowing the attack to be iterated.

Might solving these issues in one swoop be a good rationale for 
authenticated encryption?

Trevor

---

From: Trevor Perrin <[email-masked]>
Date: Tue, 06 May 2003 11:32:11 -0700

At 05:01 PM 5/5/2003 -0700, Trevor Perrin wrote:

>to the same plaintext P[1] it would have without his modifications - if 
>his guess if wrong, the decrypted P[1] will have bit errors, which will 

well, I got this wrong - whether the attacker's guess is right or wrong, 
P[2] will also be damaged.  Whether the attacker can differentiate these 
failures, or other similar parsing failures he can induce by rearranging 
blocks (i.e. by copying C[X] over some other block besides C[1]), I suppose 
is implementation-dependent, or at least difficult to work out..

authenticated-encryption would at least remove any concerns on these lines.

Trevor

---

From: Russ Housley <[email-masked]>
Date: Tue, 06 May 2003 13:43:16 -0400

Presently, if you want integrity, then a signature is required, which 
defeats the attack that is described.  I would be interested in looking 
into the use of CCM, EAX, CWC, or any other authenticated encryption mode 
AFTER the update to RFC 2633 is published.  I would not like to delay 
publication of the update while this is investigated.

Russ
Security Area Director

At 05:01 PM 5/5/2003 -0700, Trevor Perrin wrote:

>this".  If the recipient is a server (like an S/MIME MTA), it might 
>respond with an error message, allowing the attack to be iterated.
>

---

From: Trevor Perrin <[email-masked]>
Date: Wed, 07 May 2003 16:01:13 -0700

>publication of the update while this is investigated.

makes sense.

As far as the attack, let's call that a typo where I meant to say:

There may be reason to use authenticated-encryption even when 
signing-then-encrypting.  An attacker could tamper with the CBC-encrypted 
ciphertext.  Since ASN.1 parsing of the decrypted plaintext needs to occur 
before signature verification, if the attacker could distinguish different 
parsing failures, or distinguish a parsing failure from a 
signature-verification failure (by observing timings or error messages from 
a server, for example) he could possibly learn something about the plaintext.

Example: The attacker copies some ciphertext block C[x] over C[y].  The 
attacker then adjusts C[y-1] so that P[y] will decrypt properly, if his 
guess about P[x] and P[y] is correct.  As a result of these changes, P[y-1] 
and P[y+1] will decrypt randomly.

However if he chooses y so that P[y-1] and P[y+1] are allowed to be random 
data (within the SignedInfo, they might be the content, signature, or 
SubjectKeyIdentifier blocks), but P[y] has an ASN.1 structure that has to 
be parsed correctly, then he can possibly verify guesses about P[x] xor 
P[y] by differentiating between parsing and signature verification failures 
(or whatever type of failure is caused by damaging P[y-1] and P[y+1]).

Is this possible?  I don't know, depends on all sorts of things (cipher 
blocksize, the size of the various SignedInfo OIDs, hash values, and signed 
attributes, how the recipient handles errors, etc.)..  Maybe it's not worth 
worrying about, but authenticated-encryption would eliminate any concern.

Trevor