Big news! NIST standardises 3 PQC algorithms
What does this mean for our work?
On 13 August 2024 the National Institute of Standards and Technology (NIST) standardised 3 post-quantum cryptography (PQC) algorithms. This is relevant for the PQC testbed that we are working on at SIDN Labs. In this blog we briefly explain what these standards mean for our work on post-quantum DNS security.
How do these standards fit into our work on the post-quantum DNS?
The 3 standardised algorithms are described in FIPS 203, 204 and 205, and they fulfil 2 different roles. ML-KEM (FIPS 203) is an algorithm for quantum-secure key exchange, whereas ML-DSA and SLH-DSA (FIPS 204 and FIPS 205) provide post-quantum options for digital signatures.
FIPS | Name | Derived from | Smallest public key size | Smallest signature size |
|---|---|---|---|---|
ML-KEM | CRYSTALS-Kyber | - | - | |
ML-DSA | CRYSTALS-Dilithium | 1,312 bytes (ML-DSA-44) | 2,420 bytes (ML-DSA-44) | |
SHL-DSA | SPHINCS+ | 32 bytes (SLH-DSA-SHA2-128s) | 7,856 bytes (SLH-DSA-SHA2-128s) |
How the new standards affect DoH
As described in a previous blog, we already enabled a hybrid KEM (namely X25519Kyber768) in our DoH and DoT resolvers to protect DNS4all.eu users’ privacy against store-now-decrypt-later attacks. Since ML-KEM is based on the same CRYSTALS-Kyber, it is likely that, in the near future, a new hybrid algorithm will emerge based on ML-KEM such as X-WING.
How the new standards could affect DNSSEC
The newly standardised algorithms for digital signatures are of limited use for our work on DNSSEC. ML-DSA-44 and SLH-DSA-SHA2-128s both result in signature sizes (2.5kB and 8kB, respectively) that would significantly increase the size of DNS answers and are therefore not straightforward to use in DNSSEC. If we want to keep supporting (the default and widely used) DNS-over-UDP transport, answers should not be bigger than 1,232 bytes to stay within the limits for UDP packet delivery on the internet. This requirement was already noted in the context of earlier research on retrofitting PQC in DNSSEC.
On the positive side, NIST is expected to standardise Falcon as FN-DSA later this year as an additional alternative to these standards. Falcon-512 is an algorithm that yields a public key size of 897 bytes and a signature size of 666 bytes, which may be usable for DNSSEC. Therefore, Falcon-512 is one of the algorithms we are currently looking at for DNSSEC implementation. But we are especially enthusiastic about a newer submission called MAYO, which has signature sizes that are even better suited for DNSSEC.
The PATAD testbed
To evaluate the working of those algorithms within the DNS, we created the PATAD testbed, in which we implemented integrations for Falcon-512, SQISign-I and MAYO-2 for PowerDNS. Additionally, there is now an alternative implementation for PowerDNS and BIND that through liboqs also supports Falcon-512.
Next steps
Last month we released our PATAD testbed that allows interested parties (you perhaps?) to experiment with PQC in DNSSEC. Meanwhile, the people at deSec and SandboxAQ already did some measurements for Falcon-512 (and other algorithms) and wrote a blog post about it. We are currently working on carrying out performance measurements with the MAYO PQC algorithm and expect to publish something on the subject soon.
For more information about our PQC work and PATAD, we encourage you to read our previous blog or listen to this PING podcast episode, in which we were interviewed about our work.
