7

In a paper from 2002 (pdf), Jallad et al describe a chosen ciphertext attack on PGP by taking advantage of the CFB mode that the block ciphers use under PGP. It's quite a devastating attack.

Is this attack still viable in 2016 or has PGP made changes?

otus
  • 32,462
  • 5
  • 75
  • 167
Marcel
  • 185
  • 2

2 Answers2

9

RFC 4880, OpenPGP (superseded RFC 2440 which was up to date in 2002) contains a chapter on security considerations, which also discusses the decryption oracle attack Jallad et al described:

In late summer 2002, Jallad, Katz, and Schneier published an interesting attack on the OpenPGP protocol and some of its implementations [JKS02]. In this attack, the attacker modifies a message and sends it to a user who then returns the erroneously decrypted message to the attacker. The attacker is thus using the user as a random oracle, and can often decrypt the message.

Compressing data can ameliorate this attack. The incorrectly decrypted data nearly always decompresses in ways that defeat the attack. However, this is not a rigorous fix, and leaves open some small vulnerabilities. For example, if an implementation does not compress a message before encryption (perhaps because it knows it was already compressed), then that message is vulnerable. Because of this happenstance -- that modification attacks can be thwarted by decompression errors -- an implementation SHOULD treat a decompression error as a security problem, not merely a data problem.

This attack can be defeated by the use of Modification Detection, provided that the implementation does not let the user naively return the data to the attacker. An implementation MUST treat an MDC failure as a security problem, not merely a data problem.

In either case, the implementation MAY allow the user access to the erroneous data, but MUST warn the user as to potential security problems should that data be returned to the sender.

While this attack is somewhat obscure, requiring a special set of circumstances to create it, it is nonetheless quite serious as it permits someone to trick a user to decrypt a message. Consequently, it is important that:

  1. Implementers treat MDC errors and decompression failures as security problems.

  2. Implementers implement Modification Detection with all due speed and encourage its spread.

  3. Users migrate to implementations that support Modification Detection with all due speed.

As a consequence, the OpenPGP packets "Sym. Encrypted Integrity Protected Data Packet (Tag 18) " and "Modification Detection Code Packet (Tag 19) " have been introduced, together forming an modification detection system (which is the proposed mitigation by Jallad et al):

NON-NORMATIVE EXPLANATION

The MDC system, as packets 18 and 19 are called, were created to provide an integrity mechanism that is less strong than a signature, yet stronger than bare CFB encryption.

It is a limitation of CFB encryption that damage to the ciphertext will corrupt the affected cipher blocks and the block following. Additionally, if data is removed from the end of a CFB-encrypted block, that removal is undetectable. (Note also that CBC mode has a similar limitation, but data removed from the front of the block is undetectable.)

[...]

At least GnuPG uses these packets per default, which you can verify through gpg --list-packets or pgpdump:

$ echo "foo" | gpg --recipient a4ff2279 --encrypt | pgpdump
Old: Public-Key Encrypted Session Key Packet(tag 1)(524 bytes)
    New version(3)
    Key ID - 0xCC73B287A4388025
    Pub alg - RSA Encrypt or Sign(pub 1)
    RSA m^e mod n(4093 bits) - ...
        -> m = sym alg(1 byte) + checksum(2 bytes) + PKCS-1 block type 02
New: Symmetrically Encrypted and MDC Packet(tag 18)(63 bytes)
    Ver 1
    Encrypted data [sym alg is specified in pub-key encrypted session key]
        (plain text + MDC SHA1(20 bytes))

In GnuPG, you can enforce usage of the new packets through the --force-mdc option (which can also be applied permanently in gpg.conf). From man gpg:

Force the use of encryption with a modification detection code. This is always used with the newer ciphers (those with a blocksize greater than 64 bits), or if all of the recipient keys indicate MDC support in their feature flags.

Community
  • 1
Jens Erat
  • 1,383
  • 11
  • 18
2

A subsequent 2005 paper came out just before RFC4880 with a different attack on the PGP CFB mode. Both attacks are mentioned in the RFC's Security Considerations section.

The attack leverages OpenPGP's "quick check" relation between two 16-bit sub-words of the modified-CFB ciphertext. The attacker must first guess two bytes of the plaintext, e.g., from header syntax. The attacker substitutes ciphertext blocks into the first position and, using an oracle returning the "quick check" error message, exhaustively searches over a 16-bit value to determine an additional 16 bits of the plaintext. Eventually the first two bytes of each plaintext block are revealed.

The SEIP packet does not resolve the 2005 attack. The proposed solution is to not implement the key integrity "quick check" that was the purpose of the modified-CFB mode. The RFC, however, recommends keeping the quick check for the convenience of typical use cases where the oracle attack is not practical.

Use caution deploying PGP in server applications. It appears that OpenPGP.js v5.11.1 does not implement the "quick check", avoiding the 2005 attack.

Steve Mitchell
  • 251
  • 1
  • 5