Key Exchange Grade 90% while using only X25519KEM768

[reneposthumus]

Which version are you referring to?

3.2

Hi, we're testing with Post Quantum Key exchange using ML-KEM as Key Exchange, and only ML-KEM.
All SS Labs grades are 100% but not key Exchange. What prerequisites are there to get Key Exchange at 100% using PQC algorithms? And ultimately getting the wanted 100% Overall score?

Regards,
René

[drwetter]

Hi @reneposthumus , should be the same.

@magnuslarsen : know you're pretty busy, but if you have a chance ....

[magnuslarsen]

The calculation is pretty simple:
https://github.com/testssl/testssl.sh/blob/932c91f67cd9cbd2dc4cf9f6ecebc31c0c8ed376/testssl.sh#L1172-L1208

But the spec is written well before PQ was a thing, so we need to fish it out of Qualys' SSL tool if we want anything meaningful :^)
https://github.com/ssllabs/research/wiki/SSL-Server-Rating-Guide#key-exchange

I will see if I can get a webserver with ML-KEM setup in the near future 👍

[reneposthumus]

Hi @magnuslarsen, thanks for replying this fast. When looking at the calculation at type ML-DSA (ML-DSA is not a Key Agreement Algorithm by the way, it's a Digital Signature Algorithm). I see a very big key length, which is far beyond the key sizes for KE we know of today.

The biggest one, KEM1024, only has a 1568 bytes long key.
The one we are using for now. KEM768 has a 1184 bytes long key.

In the code, there's a strange number that limits in all circumstances, to 90%:

https://github.com/testssl/testssl.sh/blob/932c91f67cd9cbd2dc4cf9f6ecebc31c0c8ed376/testssl.sh#L1202-L1204

More info:

https://openquantumsafe.org/liboqs/algorithms/kem/ml-kem.html#parameter-set-summary

Thanks for your help!

[dcooper16]

I can't comment about how the key exchange grade should be calculated. However, if you search for places where set_key_str_score() is called, it is only in run_logjam() (which only applies to ephemeral finite field DH keys in TLS 1.2 and earlier) and in certificate_info(). In certificate_info() it is called with the certificate's subject public key, whether that key is a key exchange or digital signature key. That is the reason that set_key_str_score() considers ML-DSA keys.

For ML-DSA keys, the key size is set in https://github.com/testssl/testssl.sh/blob/932c91f67cd9cbd2dc4cf9f6ecebc31c0c8ed376/testssl.sh#L9399-L9401 based on the private key size (Table 2 in https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf). The referenced code limits the key exchange score to 90% if an ML-DSA-44 key is encountered. This seems comparable to the earlier lines that limit the score to 90% if an RSA, DSA, or DH key smaller than 4096 bits is encountered.

Since I cannot test the server referenced in the test results above, I cannot determine the reason for the key exchange score of 90. However, my reading of the source code suggests that the score must be based on the size of the subject public key in the server's certificate and not on the use of X25519MLKEM768.

Hi @magnuslarsen, thanks for replying this fast. When looking at the calculation at type ML-DSA (ML-DSA is not a Key Agreement Algorithm by the way, it's a Digital Signature Algorithm). I see a very big key length, which is far beyond the key sizes for KE we know of today.

The biggest one, KEM1024, only has a 1568 bytes long key. The one we are using for now. KEM768 has a 1184 bytes long key.

In the code, there's a strange number that limits in all circumstances, to 90%:

https://github.com/testssl/testssl.sh/blob/932c91f67cd9cbd2dc4cf9f6ecebc31c0c8ed376/testssl.sh#L1202-L1204

More info:

https://openquantumsafe.org/liboqs/algorithms/kem/ml-kem.html#parameter-set-summary

Thanks for your help!

[drwetter]

The calculation is pretty simple: https://github.com/testssl/testssl.sh/blob/932c91f67cd9cbd2dc4cf9f6ecebc31c0c8ed376/testssl.sh#L1172-L1208

But the spec is written well before PQ was a thing, so we need to fish it out of Qualys' SSL tool if we want anything meaningful :^) https://github.com/ssllabs/research/wiki/SSL-Server-Rating-Guide#key-exchange

I will see if I can get a webserver with ML-KEM setup in the near future 👍

Currently Debian 13 + Nginx is the easiest or a free account @ cloudfare forwarding traffic to another web site suffices.