[Cfrg] OpenPGP security analysis

David Wagner <daw@cs.berkeley.edu> Mon, 16 September 2002 02:38 UTC

Received: from www1.ietf.org (ietf.org [] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15072 for <cfrg-archive@odin.ietf.org>; Sun, 15 Sep 2002 22:38:41 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8G2e4s26104 for cfrg-archive@odin.ietf.org; Sun, 15 Sep 2002 22:40:04 -0400
Received: from ietf.org (odin.ietf.org []) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8G2e4v26101 for <cfrg-web-archive@optimus.ietf.org>; Sun, 15 Sep 2002 22:40:04 -0400
Received: from www1.ietf.org (ietf.org [] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15053; Sun, 15 Sep 2002 22:38:11 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain []) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8G2dEv26064; Sun, 15 Sep 2002 22:39:14 -0400
Received: from ietf.org (odin.ietf.org []) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8F53Sv30851 for <cfrg@optimus.ietf.org>; Sun, 15 Sep 2002 01:03:28 -0400
Received: from mozart.cs.berkeley.edu (mozart.CS.Berkeley.EDU []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20050 for <cfrg@ietf.org>; Sun, 15 Sep 2002 01:01:35 -0400 (EDT)
Received: (from daw@localhost) by mozart.cs.berkeley.edu (8.11.6/8.11.6) id g8F52GN04269; Sat, 14 Sep 2002 22:02:16 -0700
From: David Wagner <daw@cs.berkeley.edu>
Message-Id: <200209150502.g8F52GN04269@mozart.cs.berkeley.edu>
To: ietf-openpgp@imc.org, cfrg@ietf.org
Date: Sat, 14 Sep 2002 22:02:16 -0700 (PDT)
Cc: daw@cs.berkeley.edu
X-Mailer: ELM [version 2.5 PL6]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Cfrg] OpenPGP security analysis
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


I've been reading the OpenPGP RFC's, and I noticed a few areas where the
design uses some cryptographic practices that look a bit dubious to me.
I'd like to propose that we ask the ITRF Crypto Forum Research Group
(CFRG; see http://www.irtf.org/cfrg/) to help with analyzing whether
these could pose security issues in practice for OpenPGP.

In particular, I have some concerns about message integrity issues in
OpenPGP's symmetric-key encryption formats.  This issue has bitten PGP in
the past.  Witness Gary Howland's attack (Aug 1997), the "Czech attack"
(2001), and Jallad, Katz, and Schneier's attack (2002).  It has also
bitten other standards: lack of message integrity created exploitable
security holes in IPSec (e.g., Bellovin's troubling cut-and-paste attacks)
and in 802.11 WEP.  It's a subtle area where it is easy to make mistakes,
and I suggest we ask for help from the cryptographers understanding
whether this is ought to be a concern for OpenPGP.

The aforementioned attacks exploit the complete lack of message integrity
in PGP's earlier encryption formats.  The latest OpenPGP RFC (2440bis)
proposes using Hash-then-Encrypt as a defense, with an unkeyed SHA-1
hash as the MDC.  See Section 5.13 of RFC2440bis.  In other words,
the plaintext is encrypted to something like
    CFB-encrypt(random || plaintext || SHA1(plaintext)).

Unfortunately, Hash-then-Encrypt has known security weaknesses, in
general.  For instance, there is a chosen-plaintext attack that lets
you truncate a ciphertext without detection.  See, e.g.,
Other attacks are known.  See the readings below.

For this reason, the usual advice today is to use Encrypt-then-MAC (or
some other IND-CCA2-secure scheme).  Unfortunately, back in 1999 when
message integrity was discussed, people on the OpenPGP mailing list
didn't seem to realize that a MAC is needed or that an unkeyed hash
(MDC) is insufficient.  However, we've had sufficient warning of the
need for message integrity (since 1997 or so), so we might as well get
it right now.

It is not clear to me whether the weaknesses of Hash-then-Encrypt apply to
OpenPGP, or even if they do, whether they will have any practical impact
on OpenPGP.  It is entirely possible that OpenPGP might be perfectly safe.
However, I think this could use some further analysis.  What do you say?

Other security concerns:
  -  The receiver is not required to check that the MDC is correct.
     This could expose implementations to the JKS attack.
  -  If the received MDC is invalid, the receiver is not required
     to warn the user or to drop the packet.  This could expose
     implementations to the JKS attack.
  -  If no MDC packet is present (which should be a fatal security
     error), the receiver is allowed to ignore this.  This could
     expose implementations to the Howland or JKS attack.
These can be fixed by changing a few "SHOULD"s to "MUST"s, and I propose
making this change to the RFC.

(In addition, I noticed that in CFB mode, the last block is completely
unprotected against bit-flipping attacks.  The last block is used to
encrypt the SHA1 hash of the plaintext, and of course the SHA1 hash
is longer than the last block, so there doesn't seem to be any obvious
way to exploit this.  I don't see any attacks based on this property,
but I thought I'd point it out in case anyone else does.)

In summary, I'd like to suggest we encourage cryptographers to analyze the
new OpenPGP encryption format to analyze whether it provides sufficient
message integrity protection to prevent future attacks.

Further reading, for the interested:

Thanks for your attention.

-- David Wagner
Cfrg mailing list