Hi, I just turned some wycheproofs into static dalek test cases via codegen

• dalek-cryptography/curve25519-dalek#640

If I send a PR to parse these CCTV JSON to codegen into static Rust w/ similar API to wycheproofs

Would there be interest here to maintain it in this repo together alongside the Go impl ?

It would also make sure the files reflect testing the codegen on downstream tests.

I'm aiming to abstract similar high level API for between CCTV and wycheproofs where possible so it's easier to plug into all.

I am having trouble reproducing your "modulus" KATs for ML-KEM-768.

Each line of your input file contains 1184 bytes, which is 384*K+32, as specified in the "Type Check" condition (line 982) of the spec.

BUT... the ByteDecode12 function only works for exact multiples of 384 bytes.

In our official comments to NIST, we wrote:

"Line 984. Similarly, the application of ByteDecode12(EK_Tilde) cannot be correct, since EK_Tilde is 1184 bytes when K = 3, which is not an integer multiple of 384. Perhaps ByteDecode12(EK_Tilde[0:384k]) is intended (as in line 2 of Algorithm 13) so that the final 32 bytes are eliminated?"

Do you draw the same interpretation?

Should I eliminate the final 32 bytes before performing the Modulus Check?
Thanks,
Rod, AWS

Hi @C2SP, @bdd @botovq @pornin

What do you consider important for anyone thinking about helping here?

Hey. I have been playing with AGE and using your comprehensive test vectors to try my code.

I tried this one

I had difficulties decrypting it using pyage library, HMAC verification and file key were reproduced but there was just payload problem. Details here jojonas/pyage#13 (comment)

I downloaded the file and investigated it using a hex editor. Copying the encrypted payload otherwise leads to tag issues, probably because github and other file browsers attempt to decode the binary payload.

I find the hex encoded payload to be decryptable it has to be

eecf62c7ce91b433274e68d4f2f9134cb74c5bfef7beaa52c8f0bc0e992c1e8331fb66

so the 16 byte nonce is eecf62c7ce91b433274e68d4f2f9134c and ciphertext is b74c5bfef7beaa52c8f0bc0e992c1e8331fb66. This is not at all equal to

if I attempt to decrypt 013f54400c82da08037759ada907a8b864e97de81c088a182062c4b5622fd2ab I find the tag is invalid. However if I decrypt eecf62c7ce91b433274e68d4f2f9134cb74c5bfef7beaa52c8f0bc0e992c1e8331fb66 I get valid tag and decrypted payload is age string (three bytes 616765 hex encoded).

I assume this is correct because of

could you double check this test vector and see if the payload 013f54400c82da08037759ada907a8b864e97de81c088a182062c4b5622fd2ab shouldn't be replaced by eecf62c7ce91b433274e68d4f2f9134cb74c5bfef7beaa52c8f0bc0e992c1e8331fb66?

The code that decrypts the payload and gives age plaintext is available here jojonas/pyage#13 (comment)

I'm trying to add armored support to dage and I'm struggling to understand which textual encoding of RFC7468 should be supported, because the test vectors seem to allow whitespace before and after which would imply lax encoding, but at the same time, whitespace in armored body is not allowed so it can't be the lax encoding...

Interestingly enough this bug has appeared in implementations, including at longer AAD lengths (~10k bytes). This is a tracking issue to remember there would be some value in creating some test vectors for this 😄