Re: [Cfrg] OpenPGP security analysis
"Michael Young" <mwy-opgp97@the-youngs.org> Tue, 17 September 2002 15:31 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 LAA19122 for <openpgp-archive@lists.ietf.org>; Tue, 17 Sep 2002 11:31:56 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8HFMWc19418 for ietf-openpgp-bks; Tue, 17 Sep 2002 08:22:32 -0700 (PDT)
Received: from xfw.transarc.ibm.com (xfw.transarc.ibm.com [192.54.226.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8HFMPk19413 for <ietf-openpgp@imc.org>; Tue, 17 Sep 2002 08:22:30 -0700 (PDT)
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
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
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-----
- 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 Trevor Perrin
- RE: [Cfrg] OpenPGP security analysis Trevor Perrin
- RE: [Cfrg] OpenPGP security analysis Hal Finney
- 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 Trevor Perrin