Add table of PK, CT sizes

[ounsworth]

https://mailarchive.ietf.org/arch/msg/spasm/zfWx5fYjvuvohTOI7asQG4m-NDI/

Hi Mike,

Your draft:
https://datatracker.ietf.org/doc/draft-ietf-lamps-pq-composite-kem/
could do with table on Npk, Nsk, and NSig sizes. Such tables greatly help
in implementation.

The idea is from RFC 9180, Section 7.1
https://datatracker.ietf.org/doc/rfc9180/

[image: image.png]

The details of the calculations can be found here:

https://github.com/codespree/quantcrypt/blob/main/additional_info_keysize.md

All the best,
Varun

In my opinion, we should get sample keys, signatures, and ciphertexts for all algorithms, and then measure them. This sounds like a hackathon project.

[ZPDSSAI]

Hi Mike,

I am Peiduo and I am from Varun(@codespree)'s team. We have computed the public key, secrete key and signature lengths for ML-DSA and its composite variations, and the public key, secrete key, shared secret, and cipher text lengths for ML-KEM and its composite variations. The full table documentation, together with notes on overhead computation, can be found in our project repo here.

Please check if the tables meet the requirement of this issue :)

Best regards,
Zhao Peiduo

[ounsworth]

We discussed at an author's meeting, and we think that generating a toble like this is trickier than it looks because RSA public key size is not constant: things like leading zeros, or choosing a public exponent of 3, 11, 0x10001 are going to lead to a slight difference in overall size.

I am starting to think that the right answer is to not put a table, but instead when we include test vectors / samples, we could list the public key and ciphertext sizes in those samples.

[ounsworth]

It should be just Len(ml-kem) + Len(trad) ... easy since we removed the ASN.1 wrapper.

But it would be easier to just wait until we have samples ...

For now: just put in an empty table and say TBD: pending samples