[openpgp] encrypted packets' quick integrity check

["Neal H. Walfield" <[e-mail]>]

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