[Fwd: Yes, they have found a serious PGP vulnerability...sort of]

[Ben Laurie]

This is a multi-part message in MIME format.
--------------FEFA3DD54EFFDFF34B6C17CD
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


--
http://www.apache-ssl.org/ben.html

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

ApacheCon 2001! http://ApacheCon.com/
--------------FEFA3DD54EFFDFF34B6C17CD
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

X-Sieve: cmu-sieve 2.0
Return-Path: <owner-bugtraq@SECURITYFOCUS.COM>
Received: from mailgate.algroup.co.uk (mailgate.algroup.co.uk [194.128.162.5])
	by scuzzy.ben.algroup.co.uk (Postfix) with SMTP id 96F7913603
	for <ben@scuzzy.ben.algroup.co.uk>; Wed, 21 Mar 2001 21:57:52 +0000 (GMT)
Received: (qmail 3288 invoked by uid 1002); 21 Mar 2001 21:57:52 -0000
Delivered-To: aldigit-ben@ALGROUP.CO.UK
Received: (qmail 6731 invoked from network); 21 Mar 2001 21:57:51 -0000
Received: from lists.securityfocus.com (66.38.151.7)
  by mailgate.algroup.co.uk with SMTP; 21 Mar 2001 21:57:51 -0000
Received: from lists.securityfocus.com (lists.securityfocus.com [66.38.151.7])
	by lists.securityfocus.com (Postfix) with ESMTP
	id 40AA124E6BB; Wed, 21 Mar 2001 13:08:29 -0700 (MST)
Received: from LISTS.SECURITYFOCUS.COM by LISTS.SECURITYFOCUS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 29657530 for
          BUGTRAQ@LISTS.SECURITYFOCUS.COM; Wed, 21 Mar 2001 13:08:12 -0700
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Received: from securityfocus.com (mail.securityfocus.com [66.38.151.9]) by
          lists.securityfocus.com (Postfix) with SMTP id 7A25024E977 for
          <bugtraq@lists.securityfocus.com>; Tue, 20 Mar 2001 13:16:10 -0700
          (MST)
Received: (qmail 9317 invoked by alias); 20 Mar 2001 20:16:10 -0000
Delivered-To: bugtraq@securityfocus.com
Received: (qmail 9313 invoked from network); 20 Mar 2001 20:16:10 -0000
Received: from kerberos2.troja.mff.cuni.cz (195.113.28.3) by
          mail.securityfocus.com with SMTP; 20 Mar 2001 20:16:10 -0000
Received: (qmail 28729 invoked from network); 20 Mar 2001 20:16:08 -0000
Received: from argo.troja.mff.cuni.cz (195.113.28.11) by mail.securityfocus.com
          with SMTP; 20 Mar 2001 20:16:08 -0000
Received: (qmail 13173 invoked by uid 501); 20 Mar 2001 20:16:08 -0000
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID:  <20010320203604.31AA.0@argo.troja.mff.cuni.cz>
Date:         Tue, 20 Mar 2001 21:16:08 +0100
Reply-To: Pavel Kankovsky <peak@ARGO.TROJA.MFF.CUNI.CZ>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Pavel Kankovsky <peak@ARGO.TROJA.MFF.CUNI.CZ>
Subject:      Yes, they have found a serious PGP vulnerability...sort of
To: BUGTRAQ@SECURITYFOCUS.COM

ICZ has published some real information about their new attack against
(Open)PGP. Their annoucement, in the English language, can be found at
http://www.i.cz/en/onas/tisk4.html. They say they will make a research
paper available at http://www.i.cz/ soon.

They stress how bad the problem is but there is an important detail you
should not miss: in order to exploit the vulnerability, you must be able
to modify a file containing your victim's encrypted private key in a
special way (and get one message signed with that "bugged" key). Well,
it is true such a thing can often be "performed without knowledge of the
user's passphrase" ("behind the user's back" is a more colourful phrase
used in the Czech version of the press release) but if anyone can modify
your files without your consent, he can *probably* steal your private key
and other sensitive data in 42 different ways.

The vulnerability is said to be inherent to the OpenPGP format. It seems
that the integrity of OpenPGP encrypted private ("secret" in somewhat
confusing RFC 2440 lingo) key blocks is protected by a rather lame 16-bit
checksum only (see RFC 2440, section 5.5.3. Secret Key Packet Formats),
and I guess the problem lies here. Perhaps their attack is something like
a combination of the attack against Chinese remainder theorem-based
implementations of RSA in the presence of computational errors and the
SSH1 CRC compensation attack.

Anyway, there is *probably* a rather simple defence: make your software
check generated digital signatures against corresponding public keys
automatically. It is unlikely an attacker could find a (feasible) way to
modify both an unencrypted public key and a private key encrypted using an
unknown passphrase to pass such a check. As a free bonus, you will make
your software more resistant to the fault cryptanalysis in general.

--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."

--------------FEFA3DD54EFFDFF34B6C17CD--