Re: [Cfrg] OpenPGP security analysis
"Michael Young" <mwy-opgp97@the-youngs.org> Wed, 18 September 2002 14:15 UTC
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14653 for <cfrg-archive@odin.ietf.org>; Wed, 18 Sep 2002 10:15:51 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8IEH9o04768 for cfrg-archive@odin.ietf.org; Wed, 18 Sep 2002 10:17:09 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8IEH9v04765 for <cfrg-web-archive@optimus.ietf.org>; Wed, 18 Sep 2002 10:17:09 -0400
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14643 for <cfrg-web-archive@ietf.org>; Wed, 18 Sep 2002 10:15:20 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8IEFGv04703; Wed, 18 Sep 2002 10:15:16 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HFMOv20476 for <cfrg@optimus.ietf.org>; Tue, 17 Sep 2002 11:22:24 -0400
Received: from xfw.transarc.ibm.com (xfw.transarc.ibm.com [192.54.226.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18557 for <cfrg@ietf.org>; Tue, 17 Sep 2002 11:20:34 -0400 (EDT)
Received: from mailhost.transarc.ibm.com (mailhost.transarc.ibm.com [9.38.192.124]) by xfw.transarc.ibm.com (AIX4.3/UCB 8.7/8.7) with ESMTP id LAA21676; Tue, 17 Sep 2002 11:08:33 -0400 (EDT)
Received: from mwyoung (dhcp-193-40.transarc.ibm.com [9.38.193.240]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id LAA13028; Tue, 17 Sep 2002 11:21:49 -0400 (EDT)
Message-ID: <003801c25e5d$b5e44280$f0c12609@transarc.ibm.com>
From: Michael Young <mwy-opgp97@the-youngs.org>
To: Trevor Perrin <Tperrin@sigaba.com>, 'David Wagner' <daw@cs.berkeley.edu>, ietf-openpgp@imc.org, cfrg@ietf.org
References: <2129B7848043D411881A00B0D0627EFEBFB188@exchange.sigaba.com>
Subject: Re: [Cfrg] OpenPGP security analysis
Date: Tue, 17 Sep 2002 11:20:08 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Content-Transfer-Encoding: 7bit
Sender: cfrg-admin@ietf.org
Errors-To: cfrg-admin@ietf.org
X-BeenThere: cfrg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@ietf.org?subject=unsubscribe>
List-Id: Crypto Forum Research Group <cfrg.ietf.org>
List-Post: <mailto:cfrg@ietf.org>
List-Help: <mailto:cfrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Subject: Re: [Cfrg] OpenPGP security analysis Trevor Perrin <Tperrin@sigaba.com> forwarded a note from... > >From: David Wagner [mailto:daw@cs.berkeley.edu] > >http://www.cs.berkeley.edu/~daw/my-posts/mdc-broken [quoted here for those new to the conversation:] I'm not sure I understand what you mean, but there's an attack. Suppose you want to make the receiver think message M was sent, even thought the sender would never authorize this. Then you should construct M' = M || H(M) || X, where X is arbitrary and where || denotes concatenation (it better be at block boundaries). Ask the sender to transmit M'; he will form M' || H(M'), encrypt it with CBC mode, and transmit the result. Now you can truncate the ciphertext, snipping it just before the "X" part, and the receiver will think M was sent, which is an integrity failure. First, I should point out that, M *was* "sent", just not by the apparent sender. An MDC is not a signature. The receiver should not treat it as such. Trevor went on to write: > I don't see any complications that would trip this attack up in OpenPGP's > encryption/integrity packet type. Assuming the usual PGP public key model, the attacker doesn't need the sender to participate in this plan. In this scenario, the attacker can alter message traffic from sender to receiver, so he could simply replace a message with is own well-formed PGP message. Nothing new here. This assumes that the receiver's public key is really public. If it's not, but you can convince the sender to encrypt arbitrary messages to it, then it's not really very private anyway. But if this is the scenario, then two facts complicate the attack: M and M' must be formatted as OpenPGP packets; and, the OpenPGP OFB scheme includes two redundant check bytes. (I'll explain in more detail in a separate note when I get time.) The MDC in OpenPGP is really no more than a checksum, intended to detect accidental damage. (In fact, during the discussion, I believe that some folks suggested that it be just a checksum.) Before the MDC, there was little ability to detect *any* sort of accident -- not just truncation, but fairly arbitrary internal damage as well. (When the payload is a compressed packet, the decompression might discover damage, but then again, it might not.) There was discussion of a stronger MAC, but I think this was dropped given that OpenPGP has a strong signature mechanism. -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQA/AwUBPYdIGFMkvpTT8vCGEQLxNwCfRfQ+SWNP0WlY+rfW3oU2z2IfAooAn2LW 5t9L+6P4AEdbQMg++aBynxdz =uu0e -----END PGP SIGNATURE----- _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg
- [Cfrg] OpenPGP security analysis David Wagner
- RE: [Cfrg] OpenPGP security analysis Trevor Perrin
- RE: [Cfrg] OpenPGP security analysis Trevor Perrin
- RE: [Cfrg] OpenPGP security analysis Trevor Perrin
- RE: [Cfrg] OpenPGP security analysis Trevor Perrin
- Re: [Cfrg] OpenPGP security analysis Michael Young
- RE: [Cfrg] OpenPGP security analysis Trevor Perrin
- RE: [Cfrg] OpenPGP security analysis Trevor Perrin
- Re: [Cfrg] OpenPGP security analysis Jon Callas
- Re: [Cfrg] OpenPGP security analysis Jon Callas
- RE: [Cfrg] OpenPGP security analysis Hal Finney
- RE: [Cfrg] OpenPGP security analysis Trevor Perrin