Hi All
Large-scale quantum computers are capable of breaking all of the common forms of asymmetric cryptography used on the Internet today. Luckily, they don’t exist yet. The Internet-wide transition to post-quantum cryptography began in 2022 when NIST announced their final candidates for key exchange and signatures in the NIST PQC competition. There is plenty written about the various algorithms and standardization processes that are underway.
The conventional wisdom is that it will take a long time to transition to post-quantum cryptography, so we need to start standardizing and deploying things now, even though quantum computers are not actually visible on the horizon. We’ll take the best of what comes out the NIST competitions, and deploy it.
Unfortunately, there has not been enough discussion about how what NIST has standardized is simply not good enough to deploy on the public web in most cases. We need better algorithms. Specifically, we need algorithms that use fewer bytes on the wire—a KEM that when embedded in a TLS ClientHello is still under one MTU, a signature that performs on par with ECDSA that is no larger than RSA-2048, and a sub-100 byte signature where we can optionally handle a larger public key.
To understand why, we’ll look at the current state of HTTPS. Cryptography is primarily used in five ways for HTTPS on the public web:
- Symmetric Encryption/Decryption: The actual data for HTTP(2) is transmitted as data inside a TLS connection using some authenticated cipher (AEAD) such as AES-GCM. This is largely already secure against quantum computers.
- Key Agreement: Symmetric cryptography requires a secret key. Key agreement is the process in which two parties mutually generate a secret key. TLS 1.3 traditionally used Elliptic Curve Diffie-Hellman for key agreement. All non-post-quantum key exchange mechanisms, including Diffie-Hellman, are broken by quantum computers.
- Server Identity: Servers are authenticated via X.509 certificates. At minimum, a server certificate (leaf certificate) contains a public key, and a signature from an intermediate certificate. The intermediate certificate contains another public key, and a signature from an trusted root certificate.
- Issuance Transparency: The public Web PKI relies on trusted third-parties known as Certification Authorities to validate domain ownership. Certificates are publicly logged, and servers attest that their certificates are included in the logs. This provides a deterrent for malicious certificate issuance, since any certificate that is maliciously issued to an attacker for some site will be publicly visible, and has the potential to be detected. Servers achieve issuance transparency by providing at least two Signed Certificate Timestamps, usually embedded in the certificate itself.
- Handshake Authentication: The identity of the server needs to be bound to the connection itself during the TLS handshake. In TLS 1.3, this is provided by a signature over the server key share message from the key in the server certificate in the CertificateVerify message.
https://dadrian.io/blog/posts/pqc-signatures-2024
Regards
Caute_Cautim
