Implement support for v2 SEIPD packet.

[ni4]

Description

Latest OpenPGP crypto-refresh draft documents Version 2 Sym. Encrypted Integrity Protected Data Packet Format packet instead of old AEAD-encrypted data packet. We should add support for the new format (probably after the new draft is released).

[link2xt]

https://www.rfc-editor.org/rfc/rfc9580.html is now published and includes SEIPDv2. It is supported in https://github.com/rpgp/rpgp/ and Delta Chat using it can decrypt SEIPDv2 packets preceded by v6 SKESK. Thunderbird using RNP cannot decrypt them, however, as of version 136.0.

[link2xt]

Isn't this issue closed by https://github.com/rnpgp/rnp/commit/aa9a778381ef003574d1c9c12348f57d67e32039 (PR https://github.com/rnpgp/rnp/pull/2126)? Should this issue be closed? Thunderbird can just enable crypto refresh?

[link2xt]

Interoperability test suite at https://sequoia-pgp.gitlab.io/openpgp-interoperability-test-suite/results.html?impls=6146#Symmetric_Encryption_Algorithm_support__production_side__OCB__SEIPDv2_ does not indicate that SEIPDv2 is supported:

Maybe it was not released in rnp 0.17.1.

[ni4]

@link2xt currently RNP has in it's codebase experimental support of parts of rfc9580, required by (experimental as well) PQC code. Also RNP since 2018 or 2019 has support for AEAD encrypted data, compatible with GnuPG. And that AEAD format was in RFC draft until 2021 or so (please see https://librepgp.org/ for the full story).

Also no major implementations produce SEIPD v2 artifacts as far as I know, maybe something changed for now.

[link2xt]

Also no major implementations produce SEIPD v2 artifacts as far as I know, maybe something changed for now.

Delta Chat is using rPGP and it can produce SEIPD v2. Enabling it for messages is one small patch away and we even use it already to encrypt push notification tokens between the client and push gateway so email servers cannot see the token. But if we just enable it, then Thunderbird will not be able to read the messages.

[ni4]

But if we just enable it, then Thunderbird will not be able to read the messages.

Yup, like any other mail client, or do I miss something?

[link2xt]

Yup, like any other mail client, or do I miss something?

In case of Delta Chat it does not really matter in practice as most Delta Chat users send messages to other Delta Chat users and all recent releases support reading SEIPDv2.

For a proper rollout with backwards compatibility there is a feature flag: https://www.rfc-editor.org/rfc/rfc9580.html#name-features So the path forward is to set this flag and send SEIPDv2 to keys that support it while sending SEIPDv1 to keys that don't indicate this capability. In case of Thunderbird, if it implements SEIPDv2, it can set this feature flag on new keys and then other implementations that support SEIPDv2 can send SEIPDv2 messages to Thunderbird.

In my case I don't send Delta Chat messages to Thunderbird. I mostly use Thunderbird as a debugging tool to look into the mailboxes that I use with Delta Chat so I can look at the protected headers and message contents when something goes wrong or when I develop new features. If SEIPDv2 is already implemented at least for reading, then it would be nice if Thunderbird can show me the message contents as it has the decryption key that I exported from testing account in Delta Chat and imported it in Thunderbird.

Anyway, rolling out and adoption of SEIPDv2 is mostly offtopic to the issue. If SEIPDv2 is actually supported, then this issue should be closed and then enabling SEIPDv2 support can be discussed with Thunderbird. Interoperability test suite however shows that SEIPDv2 is not supported yet, so I am not sure I should open an issue in Thunderbird bugzilla yet or discuss this with Thunderbird developers.

[ni4]

@link2xt I believe this topic would be part of the discussion on the upcoming OpenPGP summit, as it was on the previous as well. Also there were some discussion in the mailing lists before, but right now cannot find a relevant topic, it seem to be buried too deep.

[link2xt]

I have looked at the test suite, "Symmetric Encryption Algorithm support, production side, OCB (SEIPDv2)" test is unhappy that PKESK packet is version 3 instead of version 6.

Relevant paragraph of the specification says: "Additionally, to avoid potentially conflicting cipher algorithm IDs, and for simplicity, implementations MUST NOT precede a v2 SEIPD payload with either v3 PKESK or v4 SKESK packets.".

So SEIPDv2 packet itself is probably fine, but it should be preceded by v6 PKESK/SKESK.

[TJ-91]

It probably is v3 PKESK + v1 SEIPD in this case (v3 PKESK + v2 SEIPD would be very bad)

[link2xt]

It probably is v3 PKESK + v1 SEIPD in this case (v3 PKESK + v2 SEIPD would be very bad)

You are right, this is the dump of the output:

$ sq packet dump msg.txt
No key to decrypt message.  The message appears to be encrypted to:

 - 7C2FAA4DF93C37B2, certificate not found

Public-Key Encrypted Session Key Packet, new CTB, 396 bytes
    Version: 3
    Recipient: 7C2FAA4DF93C37B2
    Pk algo: RSA

Sym. Encrypted and Integrity Protected Data Packet, new CTB, 63 bytes
    Version: 1
    Decryption failed: No key to decrypt message

It produces SEIPDv1.

[TJ-91]

The relevant code is this:

#if defined(ENABLE_CRYPTO_REFRESH)
bool
rnp_ctx_t::pkeskv6_capable()
{
    for (pgp_key_t *key : recipients) {
        if (key->version() < PGP_V6) {
            return false;
        }
    }
    return true;
}
#endif

Here the flag should also be checked. This is not yet done.