RE: [Cfrg] OpenPGP security analysis

Trevor Perrin <Tperrin@sigaba.com> Wed, 18 September 2002 20:43 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 QAA29478 for <openpgp-archive@lists.ietf.org>; Wed, 18 Sep 2002 16:43:19 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g8IKVjE12946 for ietf-openpgp-bks; Wed, 18 Sep 2002 13:31:45 -0700 (PDT)
Received: from bulwinkle.sigaba.com (bulwinkle.sigaba.com [67.113.238.132]) by above.proper.com (8.11.6/8.11.3) with SMTP id g8IKVek12932 for <ietf-openpgp@imc.org>; Wed, 18 Sep 2002 13:31:40 -0700 (PDT)
Received: from bsd.sigaba.com (67.113.238.131) by bulwinkle.sigaba.com (Sigaba Gateway v3.5) with SMTP; Wed, 18 Sep 2002 13:25:07 -0700
Received: from exchange1.sigaba.com (exchange1.sigaba.com [10.10.10.10]) by bsd.sigaba.com (8.12.2/8.12.2) with ESMTP id g8IKVZE3016724; Wed, 18 Sep 2002 13:31:37 -0700
Received: by exchange.sigaba.com with Internet Mail Service (5.5.2653.19) id <TA7Z61TG>; Wed, 18 Sep 2002 13:31:28 -0700
Message-id: <2129B7848043D411881A00B0D0627EFEBFB192@exchange.sigaba.com>
From: Trevor Perrin <Tperrin@sigaba.com>
To: Trevor Perrin <Tperrin@sigaba.com>, 'Michael Young' <mwy-opgp97@the-youngs.org>, 'David Wagner' <daw@cs.berkeley.edu>, "'ietf-openpgp@imc.org'" <ietf-openpgp@imc.org>, "'cfrg@ietf.org'" <cfrg@ietf.org>
Subject: RE: [Cfrg] OpenPGP security analysis
Date: Wed, 18 Sep 2002 13:31:27 -0700
MIME-Version: 1.0
X-mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
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


[I apologize for holding a monologue here, just wanted to close this up]

>From: Trevor Perrin 
>
>There may other ways of making predictable modifications of 
>the plaintext, which can also take advantage of the fact that 
>you only need to find a collision on 4 bytes of the hash, then 
>can bit-flip the rest.

For example, copying-and-pasting a sequence of ciphertext blocks, or
deleting a sequence, will cause a scrambled block just after each splice
point, but these scrambled blocks will be predictable by an attacker who
knows the plaintext, because CFB mode lets an attacker with known plaintext
reconstruct the keystream block that follows each ciphertext block.  Thus
the situation is similar to Bellovin's cut-and-paste attacks against
non-integrity-protected CBC, with the caveats:

 - the attack requires the attacker know the entire plaintext string, so he
can compute the hash value of the modified plaintext that corresponds to his
ciphertext modifications

 - the attack depends on the attacker trying out a large number of potential
modifications, until he finds one that collides with the first X bytes of
the current hash, where X is the number of hash bytes that reside in all but
the last encryption block, (with a 16-byte block size and 20-byte hash,
X=4,5,6,..,19 with probability 1/16th each)

So in practice the attacker would choose a targeted modification he wanted
to make, then choose some imperceptible modifications that he can make in an
out-of-the-way corner of the document, and search through their permutations
until he finds a collision.

Trevor