add sample PQC certificate + PKESK/SEIPD msg

TJ-91 commented 10 months ago

I added a PQC certificate (public and private) and a v6 PKESK + v2 SEIPD message encrypted to that certificate. The two MUST algorithms are used, i.e., ML-DSA-65 + Ed25519 and ML-KEM-768 + X25519. For the format and description and I oriented myself at the Crypto Refresh.

The RNP main branch at commit 6a15c33 has been used to produce the data.

To begin with, this test vector should be enough. Signatures are also covered since the key packets are signed. It would be good to parse and decrypt this with some other implementation as soon as one is available.

In the future we might want to add some in-depth dissection of interesting intermediate values as for example A.8. Sample X25519-AEAD-OCB encryption and decryption section of the Crypto Refresh.

falko-strenzke commented 10 months ago

The two MUST algorithms are used, i.e., ML-DSA-65 + Ed25519 and ML-KEM-768 + X25519.

To be exact, that is Dilithium_round3-65+Ed25519 (an odd spec for Dilithium, I know) and Kyber_round3-768+X25519.

fluppe2 commented 10 months ago

The two MUST algorithms are used, i.e., ML-DSA-65 + Ed25519 and ML-KEM-768 + X25519.

To be exact, that is Dilithium_round3-65+Ed25519 (an odd spec for Dilithium, I know) and Kyber_round3-768+X25519.

Then I guess we discussed that the description of the test vector should point that out and include a reference to the specification document. That would really help people verify the given bits and bytes.

i.e. add maybe something like "the test vector has been produced using the following algorithmic specifications [Dilithium_round3-65] and [Kyber_round3]".

Such a sentence could be a moving target that develops into referencing the final standard for ML-DSA and ML-KEM in the end.

fluppe2 commented 10 months ago

@TJ-91 Very nice work.

TJ-91 commented 10 months ago

I added a general note in the Test vectors section and reference the spec again when writing e.g. "ML-DSA-65" to point to the Dilithium Round3 spec.

Is further clarification needed?

Edit: Should we also point to https://github.com/ietf-wg-pquip/state-of-protocols-and-pqc#algorithm-names and give the name of the used spec according to that document??

wussler commented 10 months ago

Heyo, yesterday with @teythoon we managed to get the two implementations to partially interoperate, and spotted some bugs on both sides. These vectors here are unfortunately wrong:

The key is missing a mandatory direct sig
PKESKs v4 have the cipher identifier in the wrong place
When deriving the KEK, the cipher identifier is passed as 000...000 instead of 1d (or similar) (- The key preferences are ignored, I made a key with AES128 only and it encrypted using AES256 AFAIK)

Edit: he's gonna provide a partial patch for these issues

wussler commented 10 months ago

FYI, here are some certs and messages we generated

SK

PK

Message:

Plaintext:

Amazing!!!!11elfelfeins now with the cypher byte in the right place hopefully\n

Note that the PK does not sign the message. That's signed with a key that we didn't manage to export correctly (missing self-sig)

wussler commented 10 months ago

I've implemented the latest spec here: https://github.com/ProtonMail/go-crypto/pull/142

TJ-91 commented 10 months ago

Thanks for testing and creating the certs+msg! With RNP I can use your keys fine. Decrypting the message fails as you already pointed out due to PKESK v3 incompatibilities. Please let me know when your partial fixes are available and whether I can help you with it.

PS: Is there a specific reason why you generated PKESKv3/SEIPDv1 rather than the newer versions? I think we should generate two sets for the draft: v6 PQC keys + PKESKv6/SEIPDv2 and v4 PQC keys + PKESKv3/SEIPDv1 (but for now the main thing is to have any test vector that the implementations agree with at all)

Edit:

When deriving the KEK, the cipher identifier is passed as 000...000 instead of 1d (or similar)

Btw, this is due to a wrong initialization of a std::vector in KMAC256::fixedInfo(). To clarify, do you intend to patch the RNP code as well or should I do it?

teythoon commented 10 months ago

Hey :) I have some patches that you can use as a starting point. Unfortunately at the time we did the experiments, I didn't notice that you merged the work into RNP upstream, so I started with https://github.com/falko-strenzke/rnp branch v6_pqc_2306. Hope it will still be useful.

teythoon commented 10 months ago

I pushed my work here: https://github.com/teythoon/rnp/commits/justus/hackhack

TJ-91 commented 10 months ago

Thanks that's helpful!

teythoon commented 10 months ago

I also added the stock RNP with crypto-refresh enabled, using the stock Botan to our v6 test suite: https://tests.sequoia-pgp.org/v6.html

TJ-91 commented 6 months ago

Closing this since it's outdated. Thanks for the feedback everyone, this has been helpful and I hope to submit new test vectors soon.

openpgp-pqc / draft-openpgp-pqc

add sample PQC certificate + PKESK/SEIPD msg #65