Add v6 SKESK

[TJ-91]

I added generating and parsing of v6 SKESK packets. They work similarly to the already implemented AEAD stuff, but use SEIPDv2 instead, and also, use HKDF for key derivation.

I added the Crypto Refresh test vectors for EAX/OCB, as well as an encrypt-decrypt test.

Further, I added the rnp_op_encrypt_enable_skesk_v6() API call that enables creating v6 SKESK. In the CLI it can be activated with --enable-v6-skesk.

The default behaviour for SKESK should be the same as before, even when compiling with ENABLE_CRYPTO_REFRESH.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 85.46%. Comparing base (0d5c2b9) to head (646380f).

Additional details and impacted files

@@           Coverage Diff            @@
##             main    #2207    +/-   ##
========================================
  Coverage   85.46%   85.46%            
========================================
  Files         126      126            
  Lines       22713    22477   -236     
========================================
- Hits        19411    19210   -201     
+ Misses       3302     3267    -35     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[falko-strenzke]

When this gets merged RNP would also need a way to control whether to use the v6 SKESK or the v5 SKESK via FFI or CLI.
@TJ-91 @ni4

[falko-strenzke]

Question: what is the meaning of skeycount in this context?

[TJ-91]

    pkeycount = handler->ctx->recipients.size();
    skeycount = handler->ctx->passwords.size();

These are the number of SKESK or PKESK packets.

When writing the code I assumed that only one of those variables is non-zero, meaning, we have distinct cases for symmetric and asymmetric encryption. I now think that is a wrong assumption and you can actually use PKESK and SKESK packets simultaniously for the same SEIPD message.

Thus, I will need to adapt the logic here to also take into account the v2-SEIPD capability of the "PKESK recipients".

[TJ-91]

@ni4 from my view this could be merged. Do you have any comments on the PR?

[ni4]

LGTM, thanks!

[ni4]

@ni4 from my view this could be merged. Do you have any comments on the PR?

@TJ-91 looks good, thanks. Let's wait for one more approval.

[ni4]

@TJ-91 Could you please resolve conflicts here? I'm not seem able to push to this branch. Thanks!

[TJ-91]

@ni4 I rebased (but now checks fail like on main)

[ni4]

@TJ-91 Thanks. Windows and lint CI failure must be fixed via the PR #2282, so it seems another rebase would be needed once that PR is merged )

[ni4]

@TJ-91 there is some merge conflict here.

[TJ-91]

@TJ-91 there is some merge conflict here.

I rebased

[TJ-91]

@ni4 I rebased again and all checks pass. Is it ready to merge?

[ronaldtse]

Rebased onto latest main (fdaea97) to resolve the merge conflicts, with one behavioral fix folded in:

Fix: AEADv2 upgrade condition in init_encrypted_dst. The previous revision gated the SEIPDv2 upgrade on an explicitly chosen AEAD algorithm (ctx.aalg != PGP_AEAD_NONE). That changed existing PKESK behavior: with enable_pkesk_v6 but no explicit AEAD algorithm, encryption to v6 keys silently fell back to v3 PKESK/SEIPDv1 instead of producing v6 PKESK/SEIPDv2 — and failed outright for TwoFish/Camellia, since AES is mandated for v3 PKESK with X25519/X448 (caught by test_ffi_encrypt_pk_with_v6_key in builds with Twofish enabled). The AEAD gate now applies only to the new SKESK v6 path (as documented: v6 SKESK is created "if AEAD is used"), while the PKESK v6 path keeps main's previous condition.

Also resolved a duplicate #include merge artifact in stream-parse.cpp. Verified locally (Botan 3.10, ENABLE_CRYPTO_REFRESH+ENABLE_PQC): all 294 rnp_tests and all CLI suites pass, plus RFC 9580 A.9.5/A.10.5 vectors.