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?

  • 1
    $\begingroup$ PGP definitely can defend against this sort of attack (which exploits the complete lack of authentication). The more important question is: What do the implementations do by default nowadays? $\endgroup$
    – SEJPM
    Commented May 19, 2016 at 18:30
  • $\begingroup$ reddit.com/r/GnuPG/comments/37mf9f/gpg_authenticated_encryption is probably an interesting read. I don't see any authentication ciphers in GnuPG at the moment and the comment linked to is only of 11 months ago... $\endgroup$
    – Maarten Bodewes
    Commented May 19, 2016 at 23:04
  • $\begingroup$ IIRC it depends on the specifications, so it is still possible. I do not remember if OpenPGP format specifies a new version of ciphertext adding an integrity check before decryption, but, if one is able to downgrade the version of ciphertext it could be posisble to implement the same attack. $\endgroup$
    – ddddavidee
    Commented May 20, 2016 at 8:49

2 Answers 2


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):


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.

  • $\begingroup$ This answer is thorough and explanatory, thank you for taking the time to write it $\endgroup$
    – Marcel
    Commented May 21, 2016 at 8:46

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.

  • $\begingroup$ Thanks for the update Steve, much appreciated! Could you augment your answer that clarifies if PGP is currently still susceptible to the attack you reference? A small description of the attack and possible ways of mitigating or removing the attack vector would also be great (although the question currently doesn't explain the attack either, so there's that). $\endgroup$
    – Maarten Bodewes
    Commented May 25 at 15:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.