Adding post-quantum cryptography tests

[junaruga]

Summary and motivation

I am considering contributing unit-tests to test post-quantum cryptography (PQC) [1] cases in this repository. In my understanding, the PQC is a kind of enhanced crypto which people can use safely in the age of the quantum computing which is more powerful computer than the current computing. I would cite the [1]'s Background section below. That means the practical use of quantum computers which break the current cryptography may come after 20 years. However, I think it's better to prepare for that from now according to the document in the section.

Some engineers even predict that within the next twenty or so years sufficiently large quantum computers will be built to break essentially all public key schemes currently in use. Historically, it has taken almost two decades to deploy our modern public key cryptography infrastructure. Therefore, regardless of whether we can estimate the exact time of the arrival of the quantum computing era, we must begin now to prepare our information security systems to be able to resist quantum computing.

One of the approved cryptographies for the PQC is ML-DSA (FIPS 204)[2]. So, my plan is to contribute one unit test case to the test/openssl/test_ssl.rb, running TLS dual certificates server with ML-DSA (PQC supported) and RSA (PQC not supported) using the test/openssl/utils.rb#start_server, then the 1st client with ML-DSA certificate connects to the server, then 2nd client with RSA certificate connects to the server. Both clients use the test/openssl/test_ssl.rb#server_connect. Both client connections should succeed because the TLS server has the dual certificates. Note that the [3] is a Red Hat's document about PQC. I referred to the document to select the test case and understand the implementation using the openssl s_server and openssl s_client.

Proof of Concept

I created a proof-of-concept using the Bash and Ruby scripts.[4] I tested the scripts with the current latest openssl/openssl master branch.

Let me explain the scripts in [4].

The following command in a Bash script is to run the TLS server with dual certificates, ML-DSA and RSA.

$ /path/to/openssl s_server \
  -cert localhost-mldsa.crt -key localhost-mldsa.key \
  -dcert localhost-rsa.crt -dkey localhost-rsa.key

And the following command in a Bash script is to connect to the server the ML-DSA certificate. And I see the expected result.

$ /path/to/openssl s_client \
  -connect localhost:4433 \   
  -CAfile localhost-mldsa.crt </dev/null
...
Peer signature type: mldsa65
Negotiated TLS1.3 group: X25519MLKEM768
...

And the following command in a Bash script is to connect to the server the RSA certificate. And I see the expected result.

$ /path/to/openssl s_client \
  -connect localhost:4433 \
  -CAfile localhost-rsa.crt \
  -sigalgs 'rsa_pss_pss_sha256:rsa_pss_rsae_sha256' </dev/null
...
Peer signing digest: SHA256
Peer signature type: rsa_pss_rsae_sha256
Negotiated TLS1.3 group: X25519MLKEM768
...

And I want to implement the TLS server and client implemented in Ruby that behave the same as the Bash scripts above. The file start-dual-cert-server.rb is for the TLS server. I confirmed the script behaves as the above openssl s_server. And the script connect.rb is for the TLS client with ML-DSA or RSA certificate.

Questions

So, here are 2 questions.

First. How to get the following header values that openssl s_client outputs, in a Ruby TLS client script?

Peer signing digest:
Peer signature type:
Negotiated TLS1.3 group:

Second, on the [4], the TLS server implemented in Ruby behaves as expected. However, the TLS client connecting with an RSA certificate behaves differently in the following output from the openssl s_server between the Bash and Ruby scripts. I am looking for a way for the Ruby TLS client to behave the same as the Bash script. Do you know how to do it?

Below is the output from the openssl s_server when connecting from a TLS client with an RSA certificate implemented in Bash (./pqc.sh connect-rsa = openssl s_client).

Shared ciphers:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA
Signature Algorithms: rsa_pss_pss_sha256:RSA-PSS+SHA256
Shared Signature Algorithms: rsa_pss_pss_sha256:RSA-PSS+SHA256
Supported groups: X25519MLKEM768:x25519:secp256r1:x448:secp384r1:secp521r1:ffdhe2048:ffdhe3072
Shared groups: X25519MLKEM768:x25519:secp256r1:x448:secp384r1:secp521r1:ffdhe2048:ffdhe3072

Below is the output from the openssl s_server when connecting from a TLS client with RSA certifiate implmented in Ruby (ruby -I/path/to/ruby/openssl/lib connect.rb rsa).

Shared ciphers:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA
Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:ed25519:ed448:rsa_pss_pss_sha256:rsa_pss_pss_sha384:rsa_pss_pss_sha512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:RSA+SHA224
Shared Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:ed25519:ed448:rsa_pss_pss_sha256:rsa_pss_pss_sha384:rsa_pss_pss_sha512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:RSA+SHA224
Supported groups: x25519:secp256r1:x448:secp521r1:secp384r1:ffdhe2048:ffdhe3072:ffdhe4096:ffdhe6144:ffdhe8192
Shared groups: x25519:secp256r1:x448:secp521r1:secp384r1:ffdhe2048:ffdhe3072

What do you think?

Tasks (added this section later)

Below are the tasks to complete this issue ticket.

• Add the SSLContext#sigalgs=: ssl: add SSLContext#sigalgs= and #client_sigalgs=  #895
• Rename the SSLContext#ecdh_curves= to #groups=: ssl: rename SSLContext#ecdh_curves= to #groups= #900
• Support provider-only pkeys (reported at this comment): pkey: add support for OpenSSL 3 provider-only pkeys #898
• Add features to get the following data from a TLS client
  • Peer signing digest
  • Peer signature type
  • Negotiated TLS1.3 group
• Add PQC unit tests

References

• [1] Post-Quantum Cryptography: https://csrc.nist.gov/projects/post-quantum-cryptography
• [2] FIPS 204: https://csrc.nist.gov/pubs/fips/204/final
• [3] https://www.redhat.com/en/blog/post-quantum-cryptography-red-hat-enterprise-linux-10
• [4] https://github.com/junaruga/ruby-openssl-pqc-test

[rhenium]

I think ML-DSA and ML-KEM should already be usable in OpenSSL::SSL::SSLSocket, but it seems we lack convenient methods to control the usage better as you have pointed out.

To use them outside TLS, we need some additional work: some OpenSSL::PKey methods don't handle provider-only pkeys well, and we'd also need to add new bindings for the EVP_KEM interface EDIT: EVP_PKEY_encapsulate(); EVP_KEM struct itself does not seem useful.

First. How to get the following header values that openssl s_client outputs from a Ruby TLS client script?

It appears we need the following functions, which haven't been exposed ruby/openssl yet because no one has requested them so far:

• Peer signing digest: SSL_get_peer_signature_nid(), added in OpenSSL 1.1.1a according to the man page
• Peer signature type: SSL_get0_peer_signature_name(), added in OpenSSL 3.5
• Negotiated TLS1.3 group: SSL_get_negotiated_group() is needed for (ML-)KEM, added in OpenSSL 3.0

Second, on the [4], the TLS server implemented in Ruby behaves as expected. However, the TLS client connecting with RSA certificate behaves differently about the following output from the openssl s_server between the Bash and Ruby scripts. I am looking for a way for the Ruby TLS client to behave as the same as the Bash script. Do you know how to do it?

ruby/openssl currently can't restrict signature algorithms.

The pqc.sh script uses openssl s_client -sigalgs. #769 adds a wrapper for SSL_CTX_set1_sigalgs_list() that corresponds to this. The PR hasn't been merged yet due to missing tests.

• [4] https://github.com/junaruga/ruby-openssl-pqc-test

FYI, about connect.rb: setting SSLContext#cert= only, without a matching #key=, has no effect.

[junaruga]

Thanks for your reply and advice!

I think ML-DSA and ML-KEM should already be usable in OpenSSL::SSL::SSLSocket, but it seems we lack convenient methods to control the usage better as you have pointed out.

To use them outside TLS, we need some additional work: some OpenSSL::PKey methods don't handle provider-only pkeys well, and we'd also need to add new bindings for the EVP_KEM interface EDIT: EVP_PKEY_encapsulate(); EVP_KEM struct itself does not seem useful.

As a note, all of the algorithms FIPS-approved for the PQC are, ML-KEM (FIPS 203), ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) according to the [1] and [3]. However, I heard from my colleagues working for OpenSSL, that SLH-DSA in NIST or OpenSSL is not ready to be used. We can ignore SLH-DSA case.

Interestingly, while these algorithms are FIPS-approved, I heard these algorithms are used from the default provider in OpenSSL 3.5, and the fips provider doesn't have these algorithms in it. I tested the [4] with the default provider without fips provider.

I found the design documents about ML-KEM and ML-DSA.

• ML-KEM: https://github.com/openssl/openssl/blob/master/doc/designs/ML-KEM.md
• ML-DSA: https://github.com/openssl/openssl/blob/master/doc/designs/ml-dsa.md

First. How to get the following header values that openssl s_client outputs from a Ruby TLS client script?

It appears we need the following functions, which haven't been exposed ruby/openssl yet because no one has requested them so far:

* Peer signing digest: `SSL_get_peer_signature_nid()`, added in OpenSSL 1.1.1a according to the man page

* Peer signature type: `SSL_get0_peer_signature_name()`, added in OpenSSL 3.5

* Negotiated TLS1.3 group: `SSL_get_negotiated_group()` is needed for (ML-)KEM, added in OpenSSL 3.0

All right. Thank you for your investigation!

Second, on the [4], the TLS server implemented in Ruby behaves as expected. However, the TLS client connecting with RSA certificate behaves differently about the following output from the openssl s_server between the Bash and Ruby scripts. I am looking for a way for the Ruby TLS client to behave as the same as the Bash script. Do you know how to do it?

ruby/openssl currently can't restrict signature algorithms.

The pqc.sh script uses openssl s_client -sigalgs. #769 adds a wrapper for SSL_CTX_set1_sigalgs_list() that corresponds to this. The PR hasn't been merged yet due to missing tests.

Thanks for the info. I missed considering the openssl s_client -sigalgs used in my Bash script ./pqc.sh connect-rsa. I will take a look at the PR.

• [4] https://github.com/junaruga/ruby-openssl-pqc-test

FYI, about connect.rb: setting SSLContext#cert= only, without a matching #key=, has no effect.

Oh okay. I see the SSLContext#cert=, SSLContext#key= and SSLContext#extra_chain_cert= are marked as deprecated, and the SSLContext#add_certificate are encouraged as alternative.

So, is the correct implementation below in the connect.rb?

$ git diff
diff --git a/connect.rb b/connect.rb
index bbf6749..03ad506 100644
--- a/connect.rb
+++ b/connect.rb
@@ -20,8 +20,9 @@ begin
   tcp_sock = TCPSocket.new("127.0.0.1", 4433)
   ctx = OpenSSL::SSL::SSLContext.new
   cert = OpenSSL::X509::Certificate.new(File.read("localhost-#{crypto}.crt"))
-  ctx.cert = cert
-  ctx.key = nil
+  # ctx.cert = cert
+  # ctx.key = nil
+  ctx.add_certificate(cert, nil)
   ssl_sock = OpenSSL::SSL::SSLSocket.new(tcp_sock, ctx)
   ssl_sock.sync_close = true
   ssl_sock.connect

Edit: I see the nil for the key argument doesn't work.

$ ruby -I/home/jaruga/git/ruby/openssl/lib connect.rb mldsa
connect.rb:25:in 'OpenSSL::SSL::SSLContext#add_certificate': wrong argument type nil (expected OpenSSL/EVP_PKEY) (TypeError)

  ctx.add_certificate(cert, nil)
                      ^^^^^^^^^
	from connect.rb:25:in '<main>'

So, what is your intention about the current behavior of the method #add_certificate? There is a case that we only need the certificate file without private key file like this.

$ openssl s_client -connect localhost:4433 -CAfile localhost-mldsa.crt

[rhenium]

Oh okay. I see the SSLContext#cert=, SSLContext#key= and SSLContext#extra_chain_cert= are marked as deprecated, and the SSLContext#add_certificate are encouraged as alternative.

Yes, I'd recommend using it whenever possible.

So, is the correct implementation below in the connect.rb?

SSLContext#add_certificate still requires a private key (but produces a better error). However I don't see why a certificate is set to the SSLContext here at all, since the server (pqc.sh or start-dual-cert-server.rb) does not request a client certificate.

[junaruga]

Oh okay. I see the SSLContext#cert=, SSLContext#key= and SSLContext#extra_chain_cert= are marked as deprecated, and the SSLContext#add_certificate are encouraged as alternative.

Yes, I'd recommend using it whenever possible.

So, is the correct implementation below in the connect.rb?

SSLContext#add_certificate still requires a private key (but produces a better error). However I don't see why a certificate is set to the SSLContext here at all, since the server (pqc.sh or start-dual-cert-server.rb) does not request a client certificate.

In the Red Hat blog [3] which I mentioned on the first comment, you see the examples of the openssl s_client -CAfile .... And I confirmed their intention of the -CAfile option, by talking with my colleagues working for OpenSSL.

The intention is the openssl s_client -CAfile file.crt tries to verify the server's certificate(s), printing the information Verification:, Verification error: and Verify return code: in the output of the openssl s_client. Users can verify the server certificate from the information.

For example, when running the following TLS dual certificates server with ML-DSA and RSA bits (= ./qpgc.sh start-dual-cert-server):

$ $HOME/.local/openssl-3.6.0-dev-fips-debug-10bd6fa8ca/bin/openssl s_server \
  -cert localhost-mldsa.crt -key localhost-mldsa.key \
  -dcert localhost-rsa.crt -dkey localhost-rsa.key

The following openssl s_client successfully verifies the server's certificate, printing the line Verification: OK and Verify return code: 0 (ok). Because the -CAfile localhost-mldsa.crt is the server's certificate.

$ $HOME/.local/openssl-3.6.0-dev-fips-debug-10bd6fa8ca/bin/openssl s_client \
  -connect localhost:4433 \
  -CAfile localhost-mldsa.crt \
  </dev/null
...
Peer signature type: mldsa65
Negotiated TLS1.3 group: X25519MLKEM768
...
Verification: OK
...
Verify return code: 0 (ok)
...
DONE

$ echo $?
0

However, when using another MLDSA certificate which is not the server certificate:

$ $HOME/.local/openssl-3.6.0-dev-fips-debug-10bd6fa8ca/bin/openssl req \
  -x509 \
  -newkey mldsa65 \
  -keyout localhost-mldsa-2.key \
  -subj /CN=localhost \
  -addext subjectAltName=DNS:localhost \
  -nodes \
  -out localhost-mldsa-2.crt

The following openssl s_client fails to verify the server certificate, printing Verification error: self-signed certificate and Verify return code: 18 (self-signed certificate).

$ $HOME/.local/openssl-3.6.0-dev-fips-debug-10bd6fa8ca/bin/openssl s_client \
  -connect localhost:4433 \
  -CAfile localhost-mldsa-2.crt \
  </dev/null
...
Peer signature type: mldsa65
Negotiated TLS1.3 group: X25519MLKEM768
...
Verification error: self-signed certificate
...
Verify return code: 18 (self-signed certificate)
...
DONE

$ echo $?
0

The openssl s_client without the -CAfile also prints the Verification error: self-signed certificate and Verify return code: 18 (self-signed certificate).

$HOME/.local/openssl-3.6.0-dev-fips-debug-10bd6fa8ca/bin/openssl s_client \
  -connect localhost:4433 \
  </dev/null
...
Peer signature type: mldsa65
Negotiated TLS1.3 group: X25519MLKEM768
...
Verification error: self-signed certificate
...
Verify return code: 18 (self-signed certificate)
...
DONE

$ echo $?
0

As a note, the openssl s_client -verify_return_error option makes the openssl s_client command fail with non-zero exit-status when the server verification fails.

With the -CAfile localhost-mldsa.crt, the command succeeds.

$ $HOME/.local/openssl-3.6.0-dev-fips-debug-10bd6fa8ca/bin/openssl s_client \
  -connect localhost:4433 \
  -CAfile localhost-mldsa.crt \
  -verify_return_error \
  </dev/null
...
Verify return code: 0 (ok)
---
DONE

$ echo $?
0

With the -CAfile localhost-mldsa-2.crt, the command fails.

$ $HOME/.local/openssl-3.6.0-dev-fips-debug-10bd6fa8ca/bin/openssl s_client \
  -connect localhost:4433 \
  -CAfile localhost-mldsa-2.crt \
  -verify_return_error \
  </dev/null
...
Verify return code: 18 (self-signed certificate)
---
808B67D96D7F0000:error:0A000197:SSL routines:SSL_shutdown:shutdown while in init:ssl/ssl_lib.c:2820:

$ echo $?
1

[rhenium]

I think the option openssl s_client -CAfile would correspond to SSLContext#ca_file or SSLContext#cert_store, which is used for verifying the certificate sent by the server.

[junaruga]

I think the option openssl s_client -CAfile would correspond to SSLContext#ca_file or SSLContext#cert_store, which is used for verifying the certificate sent by the server.

Thank you for the info! I was wrongly using the SSLContext#cert and SSLContext#add_certificate. Now I updated the connect.rb in my proof-of-concept repository [4] with the SSLContext#ca_file. I also applied the commits on the PR #895. And I compared the outputs of the openssl s_server running the dual certificates (= ./pqc.sh start-dual-cert-server).

Interestingly the following ruby script with setting ctx.client_sigalgs = "rsa_pss_pss_sha256:rsa_pss_rsae_sha256" have still differences for the following headers in the output of the openssl s_server, showing many allowed signature algorithms (Signature Algorithms:, Shared Signature Algorithms:).

$ ruby -I/path/to/ruby/openssl/lib connect.rb rsa

Shared ciphers:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA
Signature Algorithms: id-ml-dsa-65:id-ml-dsa-87:id-ml-dsa-44:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:ed25519:ed448:ecdsa_brainpoolP256r1_sha256:ecdsa_brainpoolP384r1_sha384:ecdsa_brainpoolP512r1_sha512:rsa_pss_pss_sha256:rsa_pss_pss_sha384:rsa_pss_pss_sha512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:RSA+SHA224:DSA+SHA224:DSA+SHA256:DSA+SHA384:DSA+SHA512
Shared Signature Algorithms: id-ml-dsa-65:id-ml-dsa-87:id-ml-dsa-44:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:ed25519:ed448:ecdsa_brainpoolP256r1_sha256:ecdsa_brainpoolP384r1_sha384:ecdsa_brainpoolP512r1_sha512:rsa_pss_pss_sha256:rsa_pss_pss_sha384:rsa_pss_pss_sha512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:RSA+SHA224

The headers in the output of the openssl s_server are below when running the openssl s_client -sigalgs 'rsa_pss_pss_sha256:rsa_pss_rsae_sha256. The Signature Algorithms: and Shared Signature Algorithms: print only rsa_pss_pss_sha256:RSA-PSS+SHA256.

Shared ciphers:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA
Signature Algorithms: rsa_pss_pss_sha256:RSA-PSS+SHA256
Shared Signature Algorithms: rsa_pss_pss_sha256:RSA-PSS+SHA256

So, what's wrong with my use of the SSLContext#client_sigalgs in the connect.rb?

[rhenium]

Does SSLContext#sigalgs in #895 work? SSL_CTX_set1_sigalgs_list() will affect signature algorithm selection by the server, i.e., the server certificates selection.

SSL_CTX_set1_client_sigalgs_list() on the other hands affects client certificates. Since the scripts don't use any, this would be no-op.

(BTW I don't quite like how these functions work differently depending on whether the SSL_CTX ends up with being a client or a server, but I think exposing these functions as-is is the least confusing for users who are familiar with the OpenSSL C API.)

[junaruga]

Does SSLContext#sigalgs in #895 work? SSL_CTX_set1_sigalgs_list() will affect signature algorithm selection by the server, i.e., the server certificates selection.

SSL_CTX_set1_client_sigalgs_list() on the other hands affects client certificates. Since the scripts don't use any, this would be no-op.

You are right! I used the SSLContext#sigalgs instead of the SSLContext#client_sigalgs. The SSLContext#sigalgs works! And now the content of the headers: Shared ciphers:, Signature Algorithms: and Shared Signature Algorithms: in the output of the openssl s_server is the same between the cases of the openssl s_client -sigalgs 'rsa_pss_pss_sha256:rsa_pss_rsae_sha256' and ruby -I/path/to/ruby/openssl/lib connect.rb rsa! I updated my proof-of-concept repository [4].

(BTW I don't quite like how these functions work differently depending on whether the SSL_CTX ends up with being a client or a server, but I think exposing these functions as-is is the least confusing for users who are familiar with the OpenSSL C API.)

I see. Okay.

[junaruga]

Okay. I see the openssl s_client -help shows the -sigalgs and -client_sigalgs options.

$ openssl s_client -help
...
 -sigalgs val               Signature algorithms to support (colon-separated list)
 -client_sigalgs val        Signature algorithms to support for client certificate authentication (colon-separated list)
...

[junaruga]

@rhenium According to the above Red Hat blog [3], also the following OpenSSL change log[5], 3 TLS groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 are supported for post-quantum crypto. Though I don't find NIST documents about the supported TLS groups. We talked about the X25519MLKEM768 cases, and now I added the SecP256r1MLKEM768 cases to my proof-of-concept repository[6].

Run the following dual ML-DSA and RSA server enabling the TLS group SecP256r1MLKEM768 (= ./pqc.sh start-dual-cert-mldsa-and-rsa-server-SecP256r1MLKEM768). I needed to enable TLS group explicitly by the -groups "SecP256r1MLKEM768".. Because the SecP256r1MLKEM768 is disabled as a default on the OpenSSL 3.6 (openssl/openssl@10bd6fa) which I tested.

$ openssl s_server \
  -cert localhost-mldsa.crt -key localhost-mldsa.key \
  -dcert localhost-rsa.crt -dkey localhost-rsa.key \
  -groups "SecP256r1MLKEM768"

Run the following openssl s_client (= ./pqc.sh connect-mldsa-SecP256r1MLKEM768 ). I also needed to enable the TLS group SecP256r1MLKEM768.

$ openssl s_client \
  -connect localhost:4433 \
  -CAfile localhost-mldsa.crt \
  -groups "SecP256r1MLKEM768" \
  </dev/null
...
Peer signature type: mldsa65
Negotiated TLS1.3 group: SecP256r1MLKEM768
...

Run the following openssl s_client (= ./pqc.sh connect-rsa-SecP256r1MLKEM768).

$ openssl s_client \
  -connect localhost:4433 \
  -CAfile localhost-rsa.crt \
  -sigalgs 'rsa_pss_rsae_sha256' \
  -groups "SecP256r1MLKEM768" \
  </dev/null
...
Peer signing digest: SHA256
Peer signature type: rsa_pss_rsae_sha256
Negotiated TLS1.3 group: SecP256r1MLKEM768
...

So, now I want the instance method SSLContext#groups which is equivalent from the openssl s_server -groups and openssl s_client -groups. Though the SSLContext#sigalgs's priority is higher than the SSLContext#groups.

It seems the SSL_CTX_set1_groups_list is the C-API to implement the SSLContext#groups.

What do you think?

References

• [5] https://github.com/openssl/openssl/blob/07c772847de682412448daea07582f566d30f7ac/CHANGES.md?plain=1#L165-L172
• [6] https://github.com/junaruga/ruby-openssl-pqc-test/blob/main/README.md#tls-group-secp256r1mlkem768

[rhenium]

It seems we already have it, but as a different method name. It appears OpenSSL 1.1.1 introduced SSL_CTX_set1_groups_list() as an alias of SSL_CTX_set1_curves_list() because the extension is not just for ECDH in TLS 1.3.

I guess we should also rename SSLContext#ecdh_curves= to #groups=.
https://ruby.github.io/openssl/OpenSSL/SSL/SSLContext.html#method-i-ecdh_curves-3D

[jackorp]

When testing with the PQC keys from Ruby, key loading and generation for PQC algorithms in style of OpenSSL::PKey.generate_key('mldsa65'), the OID in the #inspect's string is null and raises argument error when trying to use it. For mldsa type pkeys -1 is returned resulting in NULL from the OBJ_nid2sn when the -1 is provided as an argument:

openssl/ext/openssl/ossl_pkey.c

Line 713 in 43d1b53

nid = EVP_PKEY_id(pkey);

$ irb
irb(main):002> require 'openssl'
irb(main):003> key = OpenSSL::PKey.generate_key('mldsa65')
=> #<OpenSSL::PKey::PKey:0x00007fe53005dc88 oid=(null)>
irb(main):004> key.oid
(irb):4:in 'OpenSSL::PKey::PKey#oid': NULL pointer given (ArgumentError)
	from (irb):4:in '<main>'
	from <internal:kernel>:168:in 'Kernel#loop'
	from /usr/share/gems/gems/irb-1.14.3/exe/irb:9:in '<top (required)>'
	from /usr/bin/irb:25:in 'Kernel#load'
	from /usr/bin/irb:25:in '<main>'

offline discussion with openssl developers (@beldmit), revealed that NID shouldn't really be used. There isn't any for new algos. There was some discussion in upstream OpenSSL regarding the -1 return value openssl/openssl#27738

EVP_PKEY_is_a was mentioned as a way to find the key type. EVP_PKEY_get0_type_name might be a way for the #inspect method to provide the type in the inspect Ruby string.

[junaruga]

It seems we already have it, but as a different method name. It appears OpenSSL 1.1.1 introduced SSL_CTX_set1_groups_list() as an alias of SSL_CTX_set1_curves_list() because the extension is not just for ECDH in TLS 1.3.

I guess we should also rename SSLContext#ecdh_curves= to #groups=. https://ruby.github.io/openssl/OpenSSL/SSL/SSLContext.html#method-i-ecdh_curves-3D

All right! That's good news!
I tested the SSLContext#ecdh_curves= in the TLS group SecP256r1MLKEM768 and SecP384r1MLKEM1024 cases, adding the features in my proof-of-concept repository[4], and confirmed the method worked as expected.

I would agree with you. I think we should rename the SSLContext#ecdh_curves= to #groups=, then keep the #ecdh_curves= as an alias of the #groups= as a backward compatibility for a certain term, marking it as deprecated.