Re: Anybody know details about Schneier's "flaw"?

Jon Callas <jon@callas.org> Thu, 15 August 2002 06:29 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 CAA14814 for <openpgp-archive@odin.ietf.org>; Thu, 15 Aug 2002 02:29:08 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g7F6KLr14151 for ietf-openpgp-bks; Wed, 14 Aug 2002 23:20:21 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7F6KKw14144 for <ietf-openpgp@imc.org>; Wed, 14 Aug 2002 23:20:20 -0700 (PDT)
Received: from [63.73.97.184] (63.73.97.184) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.2); Wed, 14 Aug 2002 23:20:14 -0700
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Wed, 14 Aug 2002 23:20:20 -0700
Subject: Re: Anybody know details about Schneier's "flaw"?
From: Jon Callas <jon@callas.org>
To: <john.dlugosz@kodak.com>, <warlord@mit.edu>
CC: OpenPGP <ietf-openpgp@imc.org>
Message-ID: <B9809634.727B%jon@callas.org>
In-Reply-To: <OF9923FC72.471DB72D-ON86256C15.0075AE1A@kodak.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
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

On 8/14/02 2:27 PM, "john.dlugosz@kodak.com" <john.dlugosz@kodak.com> wrote:

> According to the link posted by someone else,
> (www.counterpane.com/pgp-attack.html), "We also recommend changes in the
> OpenPGP standard [3 ]to educe the
> effectiveness of ou attacks in these settings."
> 
> Are the people activly working on the -bis draft aware of this?

Yes, we are aware of it. We released bis-06 on Monday with language in it to
address this. We were advised about this a month ago, and have had quite a
good email conversation with the authors about it.

The text that is in there is some talk in the sections on compression, which
say that a decompression error should be considered to be a security
problem, not a data problem (in other words, don't typically let the user
have the damaged plaintext), and some language that recommends encouraging
people to use MDCs. There is also a relatively long section in Security
Considerations. Take a look, I think you'll like it.

    Jon