[Openpgp-dt] SEDfail and open questions

[Justus Winter <[e-mail]>]

Hello,

tl;dr: I think SED support is broken in many implementations, including
GnuPG, and this creates a accidental compatibility with SEIPD,
exacerbating the Efail problem.

I was in the process of writing a stern warning against the
Symmetrically Encrypted Data (SED) packet.  I always thought that you
could convert a Symmetrically Encrypted Integrity Protected Data (SEIPD)
packet into a SED packet by changing the header and stripping off the
MDC packet.  However, I don't think that is true, with a caveat.

The reason why you cannot (at least trivially) convert a SEIPD packet
into a SED packet is that the SED packet uses CFB with a special
re-synchronization step (see [0]) after the initialization, whereas
SEIPD does not do this step.  Therefore, the ciphers modes should not be
compatible.

0: https://openpgp-wg.gitlab.io/rfc4880bis/#name-openpgp-cfb-mode

Then, I wanted to confirm that my reading of the RFC wrt the
re-synchronization step matches what is actually implemented.  I set out
to read some implementations.

For GnuPG, this is handled in libgcrypt by the function cipher_sync.  It
is activated using the flag GCRY_CIPHER_ENABLE_SYNC.  However, I don't
think passing this flag to gcry_cipher_open actually causes the sync
operation to be executed.  I have written a program that seems to
support this (see attachment):

cargo run
   Compiling gcrypt-cfb-sync-test v0.1.0 (/home/teythoon/repos/pep/tmp/gcrypt-cfb-sync-test)
    Finished dev [unoptimized + debuginfo] target(s) in 0.26s
     Running `/home/teythoon/repos/pep/tmp/gcrypt-cfb-sync-test/target/debug/gcrypt-cfb-sync-test`
Encrypting without sync, decrypting without sync... expecting success, decryption successful.
Encrypting without sync, decrypting with sync... expecting failure, decryption successful.
Encrypting with sync, decrypting without sync... expecting failure, decryption successful.
Encrypting with sync, decrypting with sync... expecting success, decryption successful.

It follows that GnuPG (and dkgpg which also uses libgcrypt) does not
correctly implement SED, but a SED variant that does not do the CFB
re-synchronization step.

Reading OpenPGP.js, I don't see the re-synchronization either.

Reading RNP, I see that they are doing the re-synchronization.

What's the takeaway?  If SED is broken in GnuPG and noone complained,
that likely means that SED is no longer in use, and that is a good
thing.  However, the accidental compatibility allows the conversion of
SEIPD packets into SED packets, paving the way for Efail-style attacks
on implementations willing to decrypt SED packets via the packet
downgrade.

Please check my findings.

Justus