Re: [openpgp] OpenPGP SEIP downgrade attack

Watson Ladd <> Mon, 05 October 2015 14:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2310A1ACE20 for <>; Mon, 5 Oct 2015 07:10:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bcfrGmaM1ilC for <>; Mon, 5 Oct 2015 07:09:58 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 03E8F1ACE1B for <>; Mon, 5 Oct 2015 07:09:57 -0700 (PDT)
Received: by wiclk2 with SMTP id lk2so116566413wic.1 for <>; Mon, 05 Oct 2015 07:09:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=PyXaEPB63cvHQAL9YqwgxoJu8/ZxA2uM9Pu/le0++5w=; b=Sf5eZMA3tAPCqdoKsuhnHFrhde/2vGt0RtKpkh/LRHiPOL09bSzjt/AYmHjJRZvd3+ BgR2H4WST4DimNWuklrAcXVwB6129a+CSlmwxKaaQYgeeSBj+MV0N3fridKm4bUGnpmZ GBehl0kP+tnurQEwm8zyZFJbvKpdpH3GaGR6guBRAN+vB8NVoKKGi6XAu9B1gLuPmFWV xQ1NYqRP7LweyTrOWfIL/qm+JTB1gCFWgNvkjkQlxUhgep8wll5/wsqVN2BuX9t2rbKh eYk5YnQ7hZuQl1wbDX9cGSb/OPsInuzMtsB/f3vcMG6ibqSVpsZ8fgczZkBGyYeoykqj C8yg==
MIME-Version: 1.0
X-Received: by with SMTP id fg10mr12203817wic.30.1444054196359; Mon, 05 Oct 2015 07:09:56 -0700 (PDT)
Received: by with HTTP; Mon, 5 Oct 2015 07:09:56 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Mon, 5 Oct 2015 10:09:56 -0400
Message-ID: <>
From: Watson Ladd <>
To: Jonas Magazinius <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc:, IETF OpenPGP <>, Cryptography <>
Subject: Re: [openpgp] OpenPGP SEIP downgrade attack
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 05 Oct 2015 14:10:05 -0000

On Mon, Oct 5, 2015 at 10:07 AM, Jonas Magazinius
<> wrote:
> Hi,
> I've recently been analysing the OpenPGP standard and have found that it is
> vulnerable to a chosen-ciphertext attack to downgrade an SEIP packet to a
> plain SE packet. Due to the properties of CFB mode and OpenPGP’s predictable
> message structure, it is possible to switch the SEIP tag to SE, strip the
> MDC (and signature), and align and manipulate the encrypted packet. The
> implications are, among others, that an encrypted and signed message can be
> stripped of its signature and modified arbitrarily, with certain
> restrictions, by an attacker without knowing the key. This attack also
> resurrects attacks from as early as 2000 [4,5]. Part of the reason SEIP and
> MDC was introduced ~15 years ago was to deal with exactly this problem.
> Looking back at the OpenPGP mailinglist arhive it seems that the correctness
> of the integrity protection has been questioned now and then over the years
> [1,2], but it's been maintained that it is secure against this kind of
> attack [3]. It also seems like thoughts along this line is not new [6], so
> question remains why it has not been dealt with before.
> Different implementations handle SE packets differently. GPG throws a
> warning [3] that the message could have been modified, but other
> implementations do not differentiate between SE and SEIP. A quick fix for
> this issue would be to throw an error for all SE packets, though I
> understand the legacy issues it would bring (as was also suggested [3]). A
> large part of the problem here is due to CFB mode, but it seems we're stuck
> with that. It would make sense to use a different mode, but again I
> understand the legacy issues.
> To try it out in practice and to see how hard it would be for someone else
> to come to the same conclusion, I created this challenge:
> I thought it would be tough to crack, but to my great surprise it was solved
> in less than 12 hours. So far only one person has solved it though. I was
> going to submit a paper about the attack, but considering how quickly the
> challenge was cracked I realised the urgency to report this.

I  don't think we need to fix this, so much as completely redesign the
packet format to be correct. If the WG wants to go down this path, I
can definitely do it, but we would need to junk a lot.

> The attack in more detail:
> To start out, some important properties of CFB mode. (Sorry for restating
> the obvious, it's just for completeness.)
> 1) A modification of the length of the ciphertext will cause the same effect
> on the plaintext. Addition of blocks to the ciphertext will extend the
> plaintext equally. Any number of bytes cut off the end of the ciphertext
> will cut the same number of bytes from the plaintext.
> 2) The decryption of a block depends only on the preceding block, regardless
> of where in the ciphertext it appears. Sequences of blocks can be cut,
> duplicated, or injected amidst two blocks. (When injecting the surrounding
> blocks will fail to decrypt correctly, but under the right circumstances
> that does not matter.)
> 3) If part of the plaintext is known, the corresponding part of the
> ciphertext can be modified to produce arbitrary text.
> It is important to note that none of these properties depend on the
> encryption key, which implies that knowing the key is not required to abuse
> them.
> Now, turning a SEIP packet into a SE packet, can be done in three steps:
> 1) Changing the tag.
> 2) Aligning the encrypted blocks to match the resynchronized structure of
> the SE packet.
> 3) Ensure correct parsing of the decrypted text into packets.
> The first step is obvious. To deal with the second step we can abuse
> property 1 and 2, and simply prepend two bytes to the encrypted string.
> Because of the resynchronization step in SE packet encryption, these two
> bytes will only affect decryption of the last two bytes of the IV. The rest
> of the blocks will now be aligned with the SE structure and decrypt
> correctly. Because the blocks have been shifted the decrypted text will
> however not parse correctly due to the now missplaced checkbytes.
> The last step is to make the decrypted text parse as a set of packets. To
> parse correctly, the first two bytes of the plaintext must match the header
> of a packet such that it allows the rest of the text to parse as the
> original packets. This can be achieved by abusing property 2 and 3. Either,
> if the first two bytes of plaintext of any block is known, then that block
> and the preceeding one can be repurposed to create such a packet, or if no
> plaintext is known it can be bruteforced (given a decryption oracle).
> Unfortunately OpenPGP packets are very predictable and there are a number of
> ways this can be done. In fact, if the message is signed it is pretty
> straight forward because of the predictable one pass signature packet.
> This is supposed to convey the idea of the attack, but not be a complete
> recipe on how to do it. If more info is needed on the specifics of the
> attack in order to fix it, then this can be provided.
> Best regards,
> Jonas Magazinius
> Assured AB, Sweden
> [1] Is there any published analysis of OpenPGP's MDC?
> [2] security fixes (KDF, MDC->MAC)?
> [3] Re: security fixes (KDF, MDC->MAC)? -
> [4] A Chosen Ciphertext Attack against Several E-Mail Encryption Protocols -
> [5] Implementation of Chosen-Ciphertext Attacks against PGP and GnuPG -
> ISC'02
> [6] OpenPGP security analysis -
> _______________________________________________
> openpgp mailing list

"Man is born free, but everywhere he is in chains".