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
- authenticated encryption Trevor Perrin
- Re: authenticated encryption Trevor Perrin
- Re: authenticated encryption Russ Housley
- Re: authenticated encryption Trevor Perrin