tlshd: Allow the use of post-quantum cryptography #121
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The client and server variants of tlshd_config_get_* are identical except for 1) the stanza they're looking at in the config file, and 2) whether the word "client" or "server" gets written in a log message Add new parameter 'peer_type' to each of these functions so we can use the same function for both the client and server code. Signed-off-by: Scott Mayhew <[email protected]>
Specifying either of the SECURE256 or SECURE128 keywords in the priority string results in the ML-DSA algorithms being disabled because the post-quantum algorithms do not map nicely to the security classifications based on "bits of security" used for traditional algorithms [1]. Use @System instead, which will allow PQC on systems with newer versions of GnuTLS. It will also allow users to disable PQC via a policy module (on systems with the crypto-policies package). [1] https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-Cryptography/documents/call-for-proposals-final-dec-2016.pdf#page=15 Link: oracle#113 Signed-off-by: Scott Mayhew <[email protected]>
Add two new config options, "x509.pq.certificate" and "x509.pq.private_key" to configure tlshd to use an ML-DSA certificate. If the cert callback determines that the client supports ML-DSA, it will select this certificate. Otherwise, it will fall back to the traditional certficate (i.e. the certificate configured via "x509.certificate" and "x509.private_key"). Note that we check to ensure that the PQ certificate is using a post-quantum public-key algorithm (ML-DSA-44, ML-DSA-65, or ML-DSA-87), and we store the algorithm value so we can later compare it to the list of signing algorithms supported by the client in the cert callback. Link: oracle#113 Signed-off-by: Scott Mayhew <[email protected]>
Add two new config options "x509.pq.certificate" and "x509.pq.private_key", this time to the "[authenticate.client]" stanza of tlshd.conf. This is for client-side handling of the server's certificate request when the client is mounting with "xprtsec=mtls". This commit also makes sure the client-side x509.pq.certificate is using a post-quantum public-key algorithm, and we make sure that the server supports that algorithm before returning that cert in the cert callback (unlike the server-side cert callback, the pk_algos list is populated, so this check is more straightforward than on the server-side). Link: oracle#113 Signed-off-by: Scott Mayhew <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
These patches allow tlshd to use post-quantum cryptography. The first
patch does a bit of refactoring to reduce some code duplication. The
second fixes the priority string and allows the PQ algorithms to be
used. The other two implement dual certificate support. Dual
certificates are necessary to enable a smooth transition period,
allowing servers to work with both clients that are PQ-enabled and
clients that are not. The server will prefer the ML-DSA certificate but
will fall back to the traditional certificate for clients that do not
support ML-DSA.
To use these patches, you need a recent version of gnutls as well as
crypto-policies (if used by your distro). These commands will help you
determine if your gnutls has the necessary stuff:
You'll need to generate a cert using ML-DSA-44/ML-DSA-65/ML-DSA-87. For
example, here's how I generate a self-signed cert using ML-DSA-65:
Obviously if you're using openssl to generate your certs, you'll need a
recent openssl too. Or you can use certtool if you prefer the gnutls
utilities.
You'll need to add the cert and key to the relevant sections of
tlshd.conf and you should be good to go.
If you have debug logging turned on, you should see this if you perform a
handshake with a PQ-enabled peer you should see something like this:
Aug 28 17:58:25 rhel10.smayhew.test tlshd[3291]: Session description: (TLS1.3)-(HYBRID-X25519-MLKEM768)-(ML-DSA-65)-(AES-256-GCM)and if you perform a handshake with a non-PQ-enabled peer:
Aug 28 18:04:21 rhel10.smayhew.test tlshd[3352]: Session description: (TLS1.3)-(ECDHE-X25519)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)