[openpgp] encrypted packets' quick integrity check

"Neal H. Walfield" <neal@walfield.org> Tue, 08 March 2016 12:56 UTC

Return-Path: <neal@walfield.org>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 7C9B212D69C for <openpgp@ietfa.amsl.com>; Tue, 8 Mar 2016 04:56:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id D3kw3PPfOhbi for <openpgp@ietfa.amsl.com>; Tue, 8 Mar 2016 04:56:45 -0800 (PST)
Received: from mail.dasr.de (mail.dasr.de []) by ietfa.amsl.com (Postfix) with ESMTP id 5A7E612D5EF for <openpgp@ietf.org>; Tue, 8 Mar 2016 04:56:44 -0800 (PST)
Received: from p508130ba.dip0.t-ipconnect.de ([] helo=mail.huenfield.org) by mail.dasr.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from <neal@walfield.org>) id 1adHBo-0002FB-5o for openpgp@ietf.org; Tue, 08 Mar 2016 12:56:40 +0000
Received: from grit.huenfield.org ([]) by mail.huenfield.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <neal@walfield.org>) id 1adHBl-0006P3-9O for openpgp@ietf.org; Tue, 08 Mar 2016 13:56:39 +0100
Received: from ip6-localhost.huenfield.org ([::1] helo=grit.huenfield.org.walfield.org) by grit.huenfield.org with esmtp (Exim 4.84) (envelope-from <neal@walfield.org>) id 1adHBk-0004Qf-2e for openpgp@ietf.org; Tue, 08 Mar 2016 13:56:36 +0100
Date: Tue, 08 Mar 2016 13:56:36 +0100
Message-ID: <87oaap86wr.wl-neal@walfield.org>
From: "Neal H. Walfield" <neal@walfield.org>
To: openpgp@ietf.org
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (Gojō) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
X-SA-Exim-Mail-From: neal@walfield.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 17:06:47 +0000)
X-SA-Exim-Scanned: Yes (on mail.huenfield.org)
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/A_r93YIukOqzvrmd44F-Jl3dHbc>
Subject: [openpgp] encrypted packets' quick integrity check
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Mar 2016 12:56:47 -0000


I recently took a look at the Mister and Zuccherato attack on the
quick integrity check in encrypted packets (i.e., that the last two
bytes of the IV are correctly repeated)and I have two suggestions for

The attack relies on finding the correct values for the quick
integrity check using an exhaustive search.  This can be defeated by
making an exhaustive search unfeasible.  Concretely, instead of just
copying the last two bytes of the random IV, we replicate the whole
IV.  This should be easy to do for SEIPD packets, since we have a
version field.  Alternatively, we could store the hash of the session
key, as Mister and Zuccherato suggest in Section 5.2 of their paper.

Also, the following text regarding this issue is in RFC 4880:

     In winter 2005, Serge Mister and Robert Zuccherato from Entrust
     released a paper describing a way that the "quick check" in OpenPGP
     CFB mode can be used with a random oracle to decrypt two octets of
     every cipher block [MZ05].  They recommend as prevention not using
     the quick check at all.

     Many implementers have taken this advice to heart for any data that
     is symmetrically encrypted and for which the session key is
     public-key encrypted.  In this case, the quick check is not needed
     as the public-key encryption of the session key should guarantee
     that it is the right session key.  In other cases, the
     implementation should use the quick check with care.

As far as I can tell, the attack applies equally well whether a PK-ESK
or SK-ESK packet is used to store the session key.  This is because
the attack just exploits the session key; it doesn't matter how it is
stored.  Does anyone know why this attack should not apply to SK-ESK
packets (FWIW, GnuPG uses the check when the session key is stored in
an SK-ESK packet, but not when it is stored in a PK-ESK packet)?  If
not, I think this text should be updated to remove "and for which the
session key is public-key encrypted".


:) Neal