Re: authenticated encryption

Trevor Perrin <trevp@trevp.net> Wed, 07 May 2003 23:32 UTC

Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23436 for <smime-archive@lists.ietf.org>; Wed, 7 May 2003 19:32:30 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h47N2Ei2005691 for <ietf-smime-bks@above.proper.com>; Wed, 7 May 2003 16:02:14 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h47N2Enf005684 for ietf-smime-bks; Wed, 7 May 2003 16:02:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from smtp-out.comcast.net (smtp-out.comcast.net [24.153.64.116]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h47N2Bi2005636 for <ietf-smime@imc.org>; Wed, 7 May 2003 16:02:11 -0700 (PDT) (envelope-from trevp@trevp.net)
Received: from TREVOR.trevp.net (12-208-8-45.client.attbi.com [12.208.8.45]) by mtaout04.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HEJ00DEXHA4G1@mtaout04.icomcast.net> for ietf-smime@imc.org; Wed, 07 May 2003 19:01:17 -0400 (EDT)
Date: Wed, 07 May 2003 16:01:13 -0700
From: Trevor Perrin <trevp@trevp.net>
Subject: Re: authenticated encryption
In-reply-to: <5.2.0.9.2.20030506133007.03243b90@mail.binhost.com>
X-Sender: trevp00@pop.comcast.net
To: Russ Housley <housley@vigilsec.com>, ietf-smime@imc.org
Message-id: <5.2.0.9.0.20030507152401.02fad560@pop.comcast.net>
MIME-version: 1.0
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Content-type: text/plain; charset="us-ascii"; format="flowed"
Content-transfer-encoding: 7bit
References: <5.2.0.9.0.20030505170135.034c6a40@pop.comcast.net>
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit

At 01:43 PM 5/6/2003 -0400, Russ Housley wrote:

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

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