[CFRG] Re: Progressing NTRUPrime/Classic McEliece drafts

["D. J. Bernstein" <[e-mail]>]

Martin Thomson writes:
> With a 240 byte ciphertext (I had trouble finding a specific value, so
> this might be incorrect), that's quite a lot smaller than ML-KEM-768.

https://classic.mceliece.org/impl.html includes a table of sizes. In
particular, the ciphertext sizes are

    * 96 bytes for mceliece348864 (2^150.59),
    * 156 bytes for mceliece460896 (2^190.50),
    * 194 bytes for mceliece6960119 (2^257.14),
    * 208 bytes for mceliece6688128 (2^257.36), and
    * 208 bytes for mceliece8192128 (2^287.21),

plus 32 bytes if you use the "pc" variants (for pros and cons of those
see https://classic.mceliece.org/nist/mceliece-mods3-20221023.pdf)

The numbers I've put in parentheses here come from the CAT software from
Crypto 2024 predicting bit-operation counts for attacks. The sizes
recommended for long-term security are mceliece6*, so if you were
hearing about 240 bytes then that was probably mceliece6688128pc, but it
could also have been mceliece8192128pc.

> But the likelihood that messages fit in a single packet is a huge gain
> that has value far beyond what a simple tally might suggest.

https://rosenpass.eu and the new end-to-end https://www.pqconnect.net
are examples of squeezing Classic McEliece ciphertexts into corners of
packets. Of course, the keys are split across multiple packets.

---D. J. Bernstein (speaking for myself)