My weekend reading, doing a deep dive into the Rust source code for the rustls library, and its support for post-quantum key exchange.
A modern TLS library in Rust
- https://docs.rs/rustls/latest/rustls/
- https://github.com/rustls/rustls/
- https://github.com/rustls/rustls/tree/main/rustls/src
- https://github.com/rustls/rustls/blob/main/rustls/src/crypto/aws_lc_rs/mod.rs
- Note:
- "The cipher suite configuration that an application should use by default."
- "This will be [`ALL_CIPHER_SUITES`] sans any supported cipher suites that shouldn't be enabled by most applications."
- DEFAULT_CIPHER_SUITES
- TLS13_AES_256_GCM_SHA384
- TLS13_AES_128_GCM_SHA256
- TLS13_CHACHA20_POLY1305_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
- https://github.com/rustls/rustls/blob/main/rustls/src/crypto/aws_lc_rs/sign.rs
- https://github.com/rustls/rustls/blob/main/rustls/src/crypto/aws_lc_rs/tls12.rs
- Note:
- TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
- TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
- TLS12_ECDSA_SCHEMES
- ED25519
- ECDSA_NISTP521_SHA512
- ECDSA_NISTP384_SHA384
- ECDSA_NISTP256_SHA256
- TLS12_RSA_SCHEMES
- RSA_PSS_SHA512
- RSA_PSS_SHA384
- RSA_PSS_SHA256
- RSA_PKCS1_SHA512
- RSA_PKCS1_SHA384
- RSA_PKCS1_SHA256
- AES128_GCM
- AES256_GCM
- https://github.com/rustls/rustls/blob/main/rustls/src/crypto/aws_lc_rs/tls13.rs
- Note:
- TLS13_CHACHA20_POLY1305_SHA256
- TLS13_CHACHA20_POLY1305_SHA256_INTERNAL
- TLS13_AES_256_GCM_SHA384
- TLS13_AES_128_GCM_SHA256
- TLS13_AES_128_GCM_SHA256_INTERNAL
- https://github.com/rustls/rustls/tree/main/rustls-post-quantum
- https://docs.rs/rustls-post-quantum/latest/rustls_post_quantum/
- Crate rustls_post_quantum
- "X25519Kyber768Draft00 is pre-standardization, so you should treat this as experimental. You may see unexpected interop failures, and the algorithm implemented here may not be the one that eventually becomes widely deployed."
- "However, the two components of this key exchange are well regarded: X25519 alone is already used by default by rustls, and tends to have higher quality implementations than other elliptic curves. Kyber768 was recently standardized by NIST as ML-KEM-768."
 |
| [image source: https://github.com/rustls/rustls/blob/main/rustls-post-quantum/src/lib.rs] |
- See line #71: [X25519Kyber768Draft00]:
- https://datatracker.ietf.org/doc/draft-tls-westerbaan-xyber768d00/
- X25519Kyber768Draft00 hybrid post-quantum key agreement draft-tls-westerbaan-xyber768d00-03 [note: "Expired Internet-Draft", but is the latest...]
- "This memo defines X25519Kyber768Draft00, a hybrid post-quantum key exchange for TLS 1.3."
- IETF Draft: Hybrid key exchange in TLS 1.3 (version 10)
- [Note: Expires 2024-10-07]
- "Hybrid key exchange refers to using multiple key exchange algorithms simultaneously and combining the result with the goal of providing security even if all but one of the component algorithms is broken. It is motivated by transition to post-quantum cryptography. This document provides a construction for hybrid key exchange in the Transport Layer Security (TLS) protocol version 1.3."
- 3. Construction for hybrid key exchange [selected quotes]
- 3.1. Negotiation
- "Each particular combination of algorithms in a hybrid key exchange will be represented as a NamedGroup and sent in the supported_groups extension. No internal structure or grammar is implied or required in the value of the identifier; they are simply opaque identifiers."
- "Each value representing a hybrid key exchange will correspond to an ordered pair of two or more algorithms. (We note that this is independent from future documents standardizing solely post-quantum key exchange methods, which would have to be assigned their own identifier.)"
- 3.2. Transmitting public keys and ciphertexts [selected quotes]
- "Recall that in TLS 1.3 a KEM public key or KEM ciphertext is represented as a KeyShareEntry: ..."
- "These are transmitted in the extension_data fields of KeyShareClientHello and KeyShareServerHello extensions: ..."
- "For a hybrid key exchange, the key_exchange field of a KeyShareEntry is the concatenation of the key_exchange field for each of the constituent algorithms. The order of shares in the concatenation MUST be the same as the order of algorithms indicated in the definition of the NamedGroup."
- 6. Security Considerations [selected quotes]
- "The shared secrets computed in the hybrid key exchange should be computed in a way that achieves the "hybrid" property: the resulting secret is secure as long as at least one of the component key exchange algorithms is unbroken. See [GIACON] and [BINDEL] for an investigation of these issues. Under the assumption that shared secrets are fixed length once the combination is fixed, the construction from Section 3.3 corresponds to the dual-PRF combiner of [BINDEL] which is shown to preserve security under the assumption that the hash function is a dual-PRF."
- "As noted in Section 2, KEMs used in the manner described in this document MUST explicitly be designed to be secure in the event that the public key is reused, such as achieving IND-CCA2 security or having a transform like the Fujisaki-Okamoto transform applied. Kyber has such security properties. However, some other post-quantum KEMs are designed to be IND-CPA-secure (i.e., without countermeasures such as the FO transform) are completely insecure under public key reuse; for example, some lattice-based IND-CPA-secure KEMs are vulnerable to attacks that recover the private key after just a few thousand samples [FLUHRER]."
- "...this specification MUST only be used with algorithms which have fixed-length shared secrets (after the variant has been fixed by the algorithm identifier in the NamedGroup negotiation in Section 3.1)"
rustls Security Advisories:
- https://rustsec.org/packages/rustls.html
- 2024-04-19 RUSTSEC-2024-0336: Vulnerability in rustls
- "rustls::ConnectionCommon::complete_io could fall into an infinite loop based on network input"
Additional resources:
https://badssl.com/
"badssl.com is meant for manual testing of security UI in web clients."
https://github.com/chromium/badssl.com
"Memorable site for testing clients against bad SSL configs."
Cloudflare Research: Post-Quantum Key Agreement
https://pq.cloudflareresearch.com/
https://tldr.fail/
"On essentially all domains served (1) through Cloudflare, including this one, we have enabled hybrid post-quantum key agreement."
References:
NIST:
- https://csrc.nist.gov/projects/post-quantum-cryptography
- Post-Quantum Cryptography: Digital Signature Schemes
- https://csrc.nist.gov/Projects/post-quantum-cryptography/faqs
- https://csrc.nist.gov/Events/2024/fifth-pqc-standardization-conference
- 5th NIST PQC Standardization Conference from April 10-12, 2024, in Rockville, Maryland
- "The purpose of the conference is to discuss various aspects of the algorithms (both those selected and those being evaluated) and to obtain valuable feedback for informing decisions on standardization"
- "NIST will invite the submission teams for BIKE, Classic McEliece, Falcon, and HQC to give an update on their algorithms."
- See: [with links to PDFs]
- https://csrc.nist.gov/Projects/post-quantum-cryptography/selected-algorithms-2022
- https://csrc.nist.gov/projects/post-quantum-cryptography/round-4-submissions
- https://csrc.nist.gov/Topics/Security-and-Privacy/cryptography/post-quantum-cryptography
