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:
Implementers treat MDC errors and decompression failures as
security problems.
Implementers implement Modification Detection with all due
speed and encourage its spread.
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.