Subject: [openpgp] encrypted packets' quick integrity check

From: "Neal H. Walfield" <[email-masked]>
Date: Tue, 08 Mar 2016 13:56:36 +0100

Hi,

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
RFC4880bis.

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".

Thanks!

:) Neal

---

From: Tom Ritter <[email-masked]>
Date: Wed, 9 Mar 2016 22:31:15 -0600

On 8 March 2016 at 06:56, Neal H. Walfield <[email-masked]> wrote:
> IV.

If we use a chunked AEAD mode that is safe for streaming (which I
think we should) - can we just do away with the quick check entirely?

-tom

---

From: Jonas Magazinius <[email-masked]>
Date: Mon, 14 Mar 2016 14:34:37 +0000

Hi,

> key, as Mister and Zuccherato suggest in Section 5.2 of their paper.

If you reuse the entire IV the check itself will be very easy to bypass, just prepend the ciphertext with two blocks of zeroes. 

Then in order for the rest of the ciphertext to make sense, you need to find a block that, when decrypted, resembles a dummy packet of appropriate size to line up with the rest of the packets. You can do that by adding another block between the zeroes and the original cipher text and bruteforce the first few bytes of it. 

If you want to go in that direction, you can use the second half of the IV, or the IV in reverse. That should fix the issue.

Regards,
Jonas