[ruby-core:125491] [Ruby Feature#22068] Adding post-quantum cryptography (PQC) support across Ruby standard libraries
Issue #22068 has been reported by jaruga (Jun Aruga). ---------------------------------------- Feature #22068: Adding post-quantum cryptography (PQC) support across Ruby standard libraries https://bugs.ruby-lang.org/issues/22068 * Author: jaruga (Jun Aruga) * Status: Open ---------------------------------------- ## Summary and motivation Post-quantum cryptography (PQC) means cryptography algorithm which people can safely use after (post) quantum computing is practically used in the future. By using the quantum computing which is much more powerful than the current computing, it can be possible to crack the current non-PQC algorithms. The goal of this ticket is to make Ruby (including libraries: default gems + bundle gems) work in the environment where only post-quantum cryptography (PQC)-supported algorithms are enabled, and other cryptography algorithms such as RSA are disabled. PQC-supported algorithms are only ML-DSA, ML-KEM and SLH-DSA for now. ML-DSA is used for signature (certification), and ML-KEM is used for connection. As I heard from my colleagues working for OpenSSL, that SLH-DSA is not ready to be used, we can ignore SLH-DSA for now. Ruby OpenSSL (ruby/openssl) already supports PQC by the ticket [ruby/openssl#894][ruby-openssl-pqc-issue]. And there are some works are needed for other standard libraries using Ruby OpenSSL in Ruby to support PQC. I cite the following text from the [NIST][nist-wikipedia]'s [PQC document][nist-pqc]. NIST is an organization deciding cryptography specifications in my understanding.
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.
I also cite the following text from DigiCert, a security company's blog. ([link][digicert-blog-google-mtc])
Gartner predicts that by 2029, conventional asymmetric cryptography like RSA and ECC will be unsafe for protecting sensitive data due to “harvest-now, decrypt-later" threats—even before a quantum break occurs.
So, it's better to prepare PQC support now. As an example of the actual movement European Commission is trying to migrate from non-PQC to PQC.([link][ec-pqc]) ## Proof of concept I manage my proof-of-concept scripts on my [junaruga/ruby-pqc-test] repository. For now, there are only some scripts to test RubyGems and Bundler in PQC use cases. ## Tasks I checked ruby/ruby including default gems and bundled gems at the master branch commit `93f1010f70a3ac924c3b37e4ae82cf1a669fcbf0` which was the latest at that time. While ruby/ruby original code doesn't have PQC logic, the following libraries that have the own upstream project need to be modified to support PQC use cases in my investigation. And I am motivated to work on these tasks, adding the PQC features and/or tests. I will open the issue ticket for each upstream project ruby/* one by one. * [ruby/rubygems](https://github.com/ruby/rubygems) - Add PQC features * [ruby/rubygems bundler](https://github.com/ruby/rubygems/tree/master/bundler) - Add PQC features * [ruby/net-http](https://github.com/ruby/net-http) - default gem - Update code comments and add PQC tests * [ruby/open-uri](https://github.com/ruby/open-uri) - default gem - Add PQC tests * [ruby/spec](https://github.com/ruby/spec) - spec/ - Add PQC tests * [ruby/drb](https://github.com/ruby/drb): bundled gem - Add PQC features * [ruby/rbs](https://github.com/ruby/rbs): bundled gem - Not sure. There is `stdlib/openssl/0/openssl.rbs`. Note I used the following [ripgrep]'s `rg` command (an enhanced `grep` command) to check the affected files by PQC. ``` $ rg "require +['\"]openssl['\"]|OpenSSL" --type ruby ``` Please let me know what you think. [openssl-35-release]: https://openssl-library.org/post/2025-04-08-openssl-35-final-release/ [ruby-openssl-pqc-issue]: https://github.com/ruby/openssl/issues/894 [nist-wikipedia]: https://en.wikipedia.org/wiki/National_Institute_of_Standards_and_Technology [nist-pqc]: https://csrc.nist.gov/projects/post-quantum-cryptography [ec-pqc]: https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-... [digicert-blog-google-mtc]: https://www.digicert.com/blog/google-merkle-tree-certificates [junaruga/ruby-pqc-test]: https://github.com/junaruga/ruby-pqc-test [ripgrep]: https://github.com/BurntSushi/ripgrep -- https://bugs.ruby-lang.org/
Issue #22068 has been updated by hsbt (Hiroshi SHIBATA). Thanks for your detailed summary. I will handle rubygems and bundler. ---------------------------------------- Feature #22068: Adding post-quantum cryptography (PQC) support across Ruby standard libraries https://bugs.ruby-lang.org/issues/22068#change-117334 * Author: jaruga (Jun Aruga) * Status: Open ---------------------------------------- ## Summary and motivation Post-quantum cryptography (PQC) means cryptography algorithm which people can safely use after (post) quantum computing is practically used in the future. By using the quantum computing which is much more powerful than the current computing, it can be possible to crack the current non-PQC algorithms. The goal of this ticket is to make Ruby (including libraries: default gems + bundle gems) work in the environment where only post-quantum cryptography (PQC)-supported algorithms are enabled. PQC-supported algorithms are only ML-DSA, ML-KEM and SLH-DSA for now. ML-DSA is used for signature (certification), and ML-KEM is used for connection. As I heard from my colleagues working for OpenSSL, that SLH-DSA is not ready to be used, we can ignore SLH-DSA for now. Ruby OpenSSL (ruby/openssl) already supports PQC by the ticket [ruby/openssl#894][ruby-openssl-pqc-issue]. And there are some works are needed for other standard libraries using Ruby OpenSSL in Ruby to support PQC. I cite the following text from the [NIST][nist-wikipedia]'s [PQC document][nist-pqc]. NIST is an organization defining cryptographic standards.
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.
I also cite the following text from DigiCert, a security company's blog. ([link][digicert-blog-google-mtc])
Gartner predicts that by 2029, conventional asymmetric cryptography like RSA and ECC will be unsafe for protecting sensitive data due to “harvest-now, decrypt-later" threats—even before a quantum break occurs.
So, it's better to prepare PQC support now. As an example of the actual movement European Commission is trying to migrate from non-PQC to PQC.([link][ec-pqc]) ## Proof of concept I manage my proof-of-concept scripts on my [junaruga/ruby-pqc-test] repository. For now, there are only some scripts to test RubyGems and Bundler in PQC use cases. ## Tasks I checked ruby/ruby including default gems and bundled gems at the master branch commit `93f1010f70a3ac924c3b37e4ae82cf1a669fcbf0` which was the latest at that time. While ruby/ruby original code doesn't have PQC logic, the following libraries that have the own upstream project need to be modified to support PQC use cases in my investigation. And I am motivated to work on these tasks, adding the PQC features and/or tests. I will open the issue ticket for each upstream project ruby/* one by one. * [ruby/rubygems](https://github.com/ruby/rubygems) - [issue link](https://github.com/ruby/rubygems/issues/9542) - Add PQC features * [ruby/rubygems bundler](https://github.com/ruby/rubygems/tree/master/bundler) - [issue link](https://github.com/ruby/rubygems/issues/9543) - Add PQC features * [ruby/net-http](https://github.com/ruby/net-http) - default gem - Update code comments and add PQC tests * [ruby/open-uri](https://github.com/ruby/open-uri) - default gem - Add PQC tests * [ruby/spec](https://github.com/ruby/spec) - spec/ - Add PQC tests * [ruby/drb](https://github.com/ruby/drb): bundled gem - Add PQC features * [ruby/rbs](https://github.com/ruby/rbs): bundled gem - Not sure. There is `stdlib/openssl/0/openssl.rbs`. Note I used the following [ripgrep]'s `rg` command (an enhanced `grep` command) to check the affected files by PQC. ``` $ rg "require +['\"]openssl['\"]|OpenSSL" --type ruby ``` Let me know what you think. [openssl-35-release]: https://openssl-library.org/post/2025-04-08-openssl-35-final-release/ [ruby-openssl-pqc-issue]: https://github.com/ruby/openssl/issues/894 [nist-wikipedia]: https://en.wikipedia.org/wiki/National_Institute_of_Standards_and_Technology [nist-pqc]: https://csrc.nist.gov/projects/post-quantum-cryptography [ec-pqc]: https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-... [digicert-blog-google-mtc]: https://www.digicert.com/blog/google-merkle-tree-certificates [junaruga/ruby-pqc-test]: https://github.com/junaruga/ruby-pqc-test [ripgrep]: https://github.com/BurntSushi/ripgrep -- https://bugs.ruby-lang.org/
Issue #22068 has been updated by jaruga (Jun Aruga).
As I heard from my colleagues working for OpenSSL, that SLH-DSA is not ready to be used, we can ignore SLH-DSA for now.
Sorry, the above was wrong or outdated information. SLH-DSA is ready to use for signature use case (but not for TLS signature) now. I am working at Red Hat, and it seems that my colleagues meant the following page's content that RHEL 10.0 provided a draft version of SLH-DSA by the OQS provider not by OpenSSL. Interoperability of RHEL 10 post-quantum cryptography https://access.redhat.com/articles/7119430
The OQS provider (oqsprovider-0.8.0-5.el10) implements the ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) and ML-DSA (Module-Lattice-Based Digital Signature Algorithm) NIST standards. The package provides an early draft version of SLH-DSA (Stateless Hash-Based Digital Signature), the SPHINCS+ algorithm, which will not be supported in the future.
However, as OpenSSL 3.5 supports SLH-DSA, this is not the case. ---------------------------------------- Feature #22068: Adding post-quantum cryptography (PQC) support across Ruby standard libraries https://bugs.ruby-lang.org/issues/22068#change-117336 * Author: jaruga (Jun Aruga) * Status: Open ---------------------------------------- ## Summary and motivation Post-quantum cryptography (PQC) means cryptography algorithm which people can safely use after (post) quantum computing is practically used in the future. By using the quantum computing which is much more powerful than the current computing, it can be possible to crack the current non-PQC algorithms. The goal of this ticket is to make Ruby (including libraries: default gems + bundle gems) work in the environment where only post-quantum cryptography (PQC)-supported algorithms are enabled. PQC-supported algorithms are only ML-DSA, ML-KEM and SLH-DSA for now. ML-DSA is used for signature (certification), and ML-KEM is used for connection. As I heard from my colleagues working for OpenSSL, that SLH-DSA is not ready to be used, we can ignore SLH-DSA for now. Ruby OpenSSL (ruby/openssl) already supports PQC by the ticket [ruby/openssl#894][ruby-openssl-pqc-issue]. And there are some works are needed for other standard libraries using Ruby OpenSSL in Ruby to support PQC. I cite the following text from the [NIST][nist-wikipedia]'s [PQC document][nist-pqc]. NIST is an organization defining cryptographic standards.
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.
I also cite the following text from DigiCert, a security company's blog. ([link][digicert-blog-google-mtc])
Gartner predicts that by 2029, conventional asymmetric cryptography like RSA and ECC will be unsafe for protecting sensitive data due to “harvest-now, decrypt-later" threats—even before a quantum break occurs.
So, it's better to prepare PQC support now. As an example of the actual movement European Commission is trying to migrate from non-PQC to PQC.([link][ec-pqc]) ## Proof of concept I manage my proof-of-concept scripts on my [junaruga/ruby-pqc-test] repository. For now, there are only some scripts to test RubyGems and Bundler in PQC use cases. ## Tasks I checked ruby/ruby including default gems and bundled gems at the master branch commit `93f1010f70a3ac924c3b37e4ae82cf1a669fcbf0` which was the latest at that time. While ruby/ruby original code doesn't have PQC logic, the following libraries that have the own upstream project need to be modified to support PQC use cases in my investigation. And I am motivated to work on these tasks, adding the PQC features and/or tests. I will open the issue ticket for each upstream project ruby/* one by one. * [ruby/rubygems](https://github.com/ruby/rubygems) - [issue link](https://github.com/ruby/rubygems/issues/9542) - Add PQC features * [ruby/rubygems bundler](https://github.com/ruby/rubygems/tree/master/bundler) - [issue link](https://github.com/ruby/rubygems/issues/9543) - Add PQC features * [ruby/net-http](https://github.com/ruby/net-http) - default gem - Update code comments and add PQC tests * [ruby/open-uri](https://github.com/ruby/open-uri) - default gem - Add PQC tests * [ruby/spec](https://github.com/ruby/spec) - spec/ - Add PQC tests * [ruby/drb](https://github.com/ruby/drb): bundled gem - Add PQC features * [ruby/rbs](https://github.com/ruby/rbs): bundled gem - Not sure. There is `stdlib/openssl/0/openssl.rbs`. Note I used the following [ripgrep]'s `rg` command (an enhanced `grep` command) to check the affected files by PQC. ``` $ rg "require +['\"]openssl['\"]|OpenSSL" --type ruby ``` Let me know what you think. [openssl-35-release]: https://openssl-library.org/post/2025-04-08-openssl-35-final-release/ [ruby-openssl-pqc-issue]: https://github.com/ruby/openssl/issues/894 [nist-wikipedia]: https://en.wikipedia.org/wiki/National_Institute_of_Standards_and_Technology [nist-pqc]: https://csrc.nist.gov/projects/post-quantum-cryptography [ec-pqc]: https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-... [digicert-blog-google-mtc]: https://www.digicert.com/blog/google-merkle-tree-certificates [junaruga/ruby-pqc-test]: https://github.com/junaruga/ruby-pqc-test [ripgrep]: https://github.com/BurntSushi/ripgrep -- https://bugs.ruby-lang.org/
Issue #22068 has been updated by jaruga (Jun Aruga). hsbt (Hiroshi SHIBATA) wrote in #note-4:
Thanks for your detailed summary. I will handle rubygems and bundler.
Thanks! ---------------------------------------- Feature #22068: Adding post-quantum cryptography (PQC) support across Ruby standard libraries https://bugs.ruby-lang.org/issues/22068#change-117337 * Author: jaruga (Jun Aruga) * Status: Open ---------------------------------------- ## Summary and motivation Post-quantum cryptography (PQC) means cryptography algorithm which people can safely use after (post) quantum computing is practically used in the future. By using the quantum computing which is much more powerful than the current computing, it can be possible to crack the current non-PQC algorithms. The goal of this ticket is to make Ruby (including libraries: default gems + bundle gems) work in the environment where only post-quantum cryptography (PQC)-supported algorithms are enabled. PQC-supported algorithms are only ML-DSA, ML-KEM and SLH-DSA for now. ML-DSA is used for signature (certification), and ML-KEM is used for connection. As I heard from my colleagues working for OpenSSL, that SLH-DSA is not ready to be used, we can ignore SLH-DSA for now. Ruby OpenSSL (ruby/openssl) already supports PQC by the ticket [ruby/openssl#894][ruby-openssl-pqc-issue]. And there are some works are needed for other standard libraries using Ruby OpenSSL in Ruby to support PQC. I cite the following text from the [NIST][nist-wikipedia]'s [PQC document][nist-pqc]. NIST is an organization defining cryptographic standards.
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.
I also cite the following text from DigiCert, a security company's blog. ([link][digicert-blog-google-mtc])
Gartner predicts that by 2029, conventional asymmetric cryptography like RSA and ECC will be unsafe for protecting sensitive data due to “harvest-now, decrypt-later" threats—even before a quantum break occurs.
So, it's better to prepare PQC support now. As an example of the actual movement European Commission is trying to migrate from non-PQC to PQC.([link][ec-pqc]) ## Proof of concept I manage my proof-of-concept scripts on my [junaruga/ruby-pqc-test] repository. For now, there are only some scripts to test RubyGems and Bundler in PQC use cases. ## Tasks I checked ruby/ruby including default gems and bundled gems at the master branch commit `93f1010f70a3ac924c3b37e4ae82cf1a669fcbf0` which was the latest at that time. While ruby/ruby original code doesn't have PQC logic, the following libraries that have the own upstream project need to be modified to support PQC use cases in my investigation. And I am motivated to work on these tasks, adding the PQC features and/or tests. I will open the issue ticket for each upstream project ruby/* one by one. * [ruby/rubygems](https://github.com/ruby/rubygems) - [issue link](https://github.com/ruby/rubygems/issues/9542) - Add PQC features * [ruby/rubygems bundler](https://github.com/ruby/rubygems/tree/master/bundler) - [issue link](https://github.com/ruby/rubygems/issues/9543) - Add PQC features * [ruby/net-http](https://github.com/ruby/net-http) - default gem - Update code comments and add PQC tests * [ruby/open-uri](https://github.com/ruby/open-uri) - default gem - Add PQC tests * [ruby/spec](https://github.com/ruby/spec) - spec/ - Add PQC tests * [ruby/drb](https://github.com/ruby/drb): bundled gem - Add PQC features * [ruby/rbs](https://github.com/ruby/rbs): bundled gem - Not sure. There is `stdlib/openssl/0/openssl.rbs`. Note I used the following [ripgrep]'s `rg` command (an enhanced `grep` command) to check the affected files by PQC. ``` $ rg "require +['\"]openssl['\"]|OpenSSL" --type ruby ``` Let me know what you think. [openssl-35-release]: https://openssl-library.org/post/2025-04-08-openssl-35-final-release/ [ruby-openssl-pqc-issue]: https://github.com/ruby/openssl/issues/894 [nist-wikipedia]: https://en.wikipedia.org/wiki/National_Institute_of_Standards_and_Technology [nist-pqc]: https://csrc.nist.gov/projects/post-quantum-cryptography [ec-pqc]: https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-... [digicert-blog-google-mtc]: https://www.digicert.com/blog/google-merkle-tree-certificates [junaruga/ruby-pqc-test]: https://github.com/junaruga/ruby-pqc-test [ripgrep]: https://github.com/BurntSushi/ripgrep -- https://bugs.ruby-lang.org/
Issue #22068 has been updated by jaruga (Jun Aruga). @seki or other ruby/drb maintainers, I opened the issue ticket <https://github.com/ruby/drb/issues/52>, sending the PR. The PR link is on the issue ticket. I would appreciate your reviews for the PR. ---------------------------------------- Feature #22068: Adding post-quantum cryptography (PQC) support across Ruby standard libraries https://bugs.ruby-lang.org/issues/22068#change-118280 * Author: jaruga (Jun Aruga) * Status: Open ---------------------------------------- ## Summary and motivation Post-quantum cryptography (PQC) means cryptography algorithm which people can safely use after (post) quantum computing is practically used in the future. By using the quantum computing which is much more powerful than the current computing, it can be possible to crack the current non-PQC algorithms. The goal of this ticket is to make Ruby (including libraries: default gems + bundle gems) work in the environment where only post-quantum cryptography (PQC)-supported algorithms are enabled. PQC-supported algorithms are only ML-DSA, ML-KEM and SLH-DSA for now. ML-DSA is used for signature (certification), and ML-KEM is used for connection. As I heard from my colleagues working for OpenSSL, that SLH-DSA is not ready to be used, we can ignore SLH-DSA for now. Ruby OpenSSL (ruby/openssl) already supports PQC by the ticket [ruby/openssl#894][ruby-openssl-pqc-issue]. And there are some works are needed for other standard libraries using Ruby OpenSSL in Ruby to support PQC. I cite the following text from the [NIST][nist-wikipedia]'s [PQC document][nist-pqc]. NIST is an organization defining cryptographic standards.
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.
I also cite the following text from DigiCert, a security company's blog. ([link][digicert-blog-google-mtc])
Gartner predicts that by 2029, conventional asymmetric cryptography like RSA and ECC will be unsafe for protecting sensitive data due to “harvest-now, decrypt-later" threats—even before a quantum break occurs.
So, it's better to prepare PQC support now. As an example of the actual movement European Commission is trying to migrate from non-PQC to PQC.([link][ec-pqc]) ## Proof of concept I manage my proof-of-concept scripts on my [junaruga/ruby-pqc-test] repository. For now, there are only some scripts to test RubyGems and Bundler in PQC use cases. ## Tasks I checked ruby/ruby including default gems and bundled gems at the master branch commit `93f1010f70a3ac924c3b37e4ae82cf1a669fcbf0` which was the latest at that time. While ruby/ruby original code doesn't have PQC logic, the following libraries that have the own upstream project need to be modified to support PQC use cases in my investigation. And I am motivated to work on these tasks, adding the PQC features and/or tests. I will open the issue ticket for each upstream project ruby/* one by one. * [ruby/rubygems](https://github.com/ruby/rubygems) - [issue link](https://github.com/ruby/rubygems/issues/9542) - Add PQC features * [ruby/rubygems bundler](https://github.com/ruby/rubygems/tree/master/bundler) - [issue link](https://github.com/ruby/rubygems/issues/9543) - Add PQC features * [ruby/net-http](https://github.com/ruby/net-http) - default gem - Update code comments and add PQC tests * [ruby/open-uri](https://github.com/ruby/open-uri) - default gem - Add PQC tests * [ruby/spec](https://github.com/ruby/spec) - spec/ - Add PQC tests * [ruby/drb](https://github.com/ruby/drb): bundled gem - [issue link](https://github.com/ruby/drb/issues/52) - Add PQC features * [ruby/rbs](https://github.com/ruby/rbs): bundled gem - Not sure. There is `stdlib/openssl/0/openssl.rbs`. Note I used the following [ripgrep]'s `rg` command (an enhanced `grep` command) to check the affected files by PQC. ``` $ rg "require +['\"]openssl['\"]|OpenSSL" --type ruby ``` Let me know what you think. [openssl-35-release]: https://openssl-library.org/post/2025-04-08-openssl-35-final-release/ [ruby-openssl-pqc-issue]: https://github.com/ruby/openssl/issues/894 [nist-wikipedia]: https://en.wikipedia.org/wiki/National_Institute_of_Standards_and_Technology [nist-pqc]: https://csrc.nist.gov/projects/post-quantum-cryptography [ec-pqc]: https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-... [digicert-blog-google-mtc]: https://www.digicert.com/blog/google-merkle-tree-certificates [junaruga/ruby-pqc-test]: https://github.com/junaruga/ruby-pqc-test [ripgrep]: https://github.com/BurntSushi/ripgrep -- https://bugs.ruby-lang.org/
Issue #22068 has been updated by jaruga (Jun Aruga). Based on the [Dev Meeting on 6th August 2026](https://bugs.ruby-lang.org/issues/22221#note-5), I updated this ticket's first comment, adding the following sections. * What is PQC? * Goal of the ticket * PQC, non-PQC hybrid and multiple key-exchange algorithms, and multiple PQC (ML-DSA), non-PQC (RSA) certificate functionalities and migration * Standardization status for PQC ---------------------------------------- Feature #22068: Adding post-quantum cryptography (PQC) support across Ruby standard libraries https://bugs.ruby-lang.org/issues/22068#change-118491 * Author: jaruga (Jun Aruga) * Status: Assigned * Assignee: jaruga (Jun Aruga) ---------------------------------------- ## Summary and motivation ### What is PQC? Post-quantum cryptography (PQC) means cryptography algorithm which people can safely use after (post) quantum computing is practically used in the future. ### Motivation By using the quantum computing which is much more powerful than the current computing, it can be possible to crack the current non-PQC algorithms. I want to prepare for the situation. I cite the following text from the [NIST][nist-wikipedia]'s [PQC document][nist-pqc]. NIST is an organization defining cryptographic standards.
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.
I also cite the following text from DigiCert, a security company's blog. ([link][digicert-blog-google-mtc])
Gartner predicts that by 2029, conventional asymmetric cryptography like RSA and ECC will be unsafe for protecting sensitive data due to “harvest-now, decrypt-later" threats—even before a quantum break occurs.
So, it's better to prepare PQC support now. As an example of the actual movement, European Commission is trying to migrate from non-PQC to PQC.([link][ec-pqc]) ## Goal of the ticket The goal of this ticket is to add PQC support across standard libraries including default gems and bundle gems. PQC-supported algorithms are only ML-DSA, ML-KEM and SLH-DSA for now. ML-DSA and SLH-DSA used for signature (certification), and ML-KEM is used for connection. <s>As I heard from my colleagues working for OpenSSL, that SLH-DSA is not ready to be used, we can ignore SLH-DSA for now.</s> The details of the goal of this ticket is making sure that PQC, non-PQC multiple (dual) key exchange / certificate use cases work by adding unit or integration tests. I think adding ML-KEM for key exchange and ML-DSA for certification is necessary. However, I need to investigate if we need to support SLH-DSA. ## Notes ### PQC, non-PQC hybrid and multiple key-exchange algorithms, and multiple PQC (ML-DSA), non-PQC (RSA) certificate functionalities and migration ML-KEM, ML-DSA, SLH-DSA are algorithm groups. They has algorithms in them. ML-KEM has hybrid algorithms that both PQC and non-PQC client can connect: X25519MLKEM768, SecP256r1MLKEM768, SecP384r1MLKEM1024. X25519MLKEM768 is [hybrid algorithm of X25519 and MLKEM768][hybrid-ml-kem]. In my understanding, ML-DSA doesn't have such hybrid algorithm. So, TLS server need to support multiple certificates ML-DSA (PQC) and RSA (non-PQC). Supporting PQC, non-PQC hybrid and multiple key-exchange algorithms, and multiple PQC (ML-DSA), non-PQC (RSA) certificates server is important for people to migrate their TLS servers from non-PQC to non-PQC/PQC hybrid/multiple, and then to PQC only. If these are no hybrid/multiple key exchange and multiple certificates functionalities, people need to prepare multiple servers for exclusive PQC server and exclusive non-PQC servers. That's costy and complicated migration. ### Standardization status for PQC According to [nist-pqc], ML-KEM (FIPS 203), ML-DSA (FIPS 204), SLH-DSA (FIPS 205) specification is already final. However, there is uncertainty or adjustment about the future of ML-DSA. ML-DSA pricate CA is supported by some vendors. But the future of ML-DSA is [Merkle Tree Certificate (MTC)][mtc-ietf]-based or public-CA. MTC is a kind of alternative of public-CA. Google is promoting MTC on [their blog][mtc-google-blog]. MTC is [draft status][mtc-ietf] in IETF. ## Proof of concept I manage my proof-of-concept scripts on my [junaruga/ruby-pqc-test] repository. For now, there are only some scripts to test RubyGems and Bundler in PQC use cases. ## Current status & affected libraries Ruby OpenSSL (ruby/openssl) already supports PQC by the ticket [ruby/openssl#894][ruby-openssl-pqc-issue] by adding ML-KEM, ML-DSA capabilities. However, we need to work for other standard libraries using Ruby OpenSSL in Ruby to support PQC. I investigated ruby/ruby including default gems and bundled gems at the master branch commit `93f1010f70a3ac924c3b37e4ae82cf1a669fcbf0` which was the latest at that time. While ruby/ruby original code doesn't have PQC logic, the following libraries that have the own upstream project need to be modified to support PQC use cases in my investigation. And I am motivated to work on these tasks, adding the PQC features and/or tests. I will open the issue ticket for each upstream project ruby/* one by one. * [ruby/rubygems](https://github.com/ruby/rubygems) - [issue link](https://github.com/ruby/rubygems/issues/9542) - Add PQC features * [ruby/rubygems bundler](https://github.com/ruby/rubygems/tree/master/bundler) - [issue link](https://github.com/ruby/rubygems/issues/9543) - Add PQC features * [ruby/net-http](https://github.com/ruby/net-http) - default gem - Update code comments and add PQC tests * [ruby/open-uri](https://github.com/ruby/open-uri) - default gem - Add PQC tests * [ruby/spec](https://github.com/ruby/spec) - spec/ - Add PQC tests * [ruby/drb](https://github.com/ruby/drb): bundled gem - [issue link](https://github.com/ruby/drb/issues/52) - Add PQC features * [ruby/rbs](https://github.com/ruby/rbs): bundled gem - Not sure. There is `stdlib/openssl/0/openssl.rbs`. Note I used the following [ripgrep]'s `rg` command (an enhanced `grep` command) to check the affected files by PQC. ``` $ rg "require +['\"]openssl['\"]|OpenSSL" --type ruby ``` Let me know what you think. [openssl-35-release]: https://openssl-library.org/post/2025-04-08-openssl-35-final-release/ [ruby-openssl-pqc-issue]: https://github.com/ruby/openssl/issues/894 [nist-wikipedia]: https://en.wikipedia.org/wiki/National_Institute_of_Standards_and_Technology [nist-pqc]: https://csrc.nist.gov/projects/post-quantum-cryptography [ec-pqc]: https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-... [mtc-ietf]: https://datatracker.ietf.org/doc/draft-ietf-plants-merkle-tree-certs/ [mtc-google-blog]: https://blog.google/security/cultivating-a-robust-and-efficient-quantum-safe... [digicert-blog-google-mtc]: https://www.digicert.com/blog/google-merkle-tree-certificates [hybrid-ml-kem]: https://www.postquantumsecurity.org/publications/X25519+MLKEM768.html [junaruga/ruby-pqc-test]: https://github.com/junaruga/ruby-pqc-test [ripgrep]: https://github.com/BurntSushi/ripgrep -- https://bugs.ruby-lang.org/
Issue #22068 has been updated by jaruga (Jun Aruga). Note that I sent PR to support SLH-DSA in ruby/openssl. However, I don't have a plan to add the SLH-DSA tests across the standard libraries except for ruby/openssl. Because I think SLH-DSA is a kind of unpopular PQC algorithm used for the signature case like ML-DSA. I think having ML-DSA tests in the necessary standard libraries is good enough to say that Ruby supports PQC. https://github.com/ruby/openssl/pull/1113 ---------------------------------------- Feature #22068: Adding post-quantum cryptography (PQC) support across Ruby standard libraries https://bugs.ruby-lang.org/issues/22068#change-119134 * Author: jaruga (Jun Aruga) * Status: Assigned * Assignee: jaruga (Jun Aruga) ---------------------------------------- ## Summary and motivation ### What is PQC? Post-quantum cryptography (PQC) means cryptography algorithm which people can safely use after (post) quantum computing is practically used like today's personal computer in the future. ### Motivation By using the quantum computing which is much more powerful than the current computing, it can be possible to crack the current non-PQC algorithms. I want to prepare for the situation. I cite the following text from the [NIST][nist-wikipedia]'s [PQC document][nist-pqc]. NIST is an organization defining cryptographic standards.
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.
I also cite the following text from DigiCert, a security company's blog. ([link][digicert-blog-google-mtc])
Gartner predicts that by 2029, conventional asymmetric cryptography like RSA and ECC will be unsafe for protecting sensitive data due to “harvest-now, decrypt-later" threats—even before a quantum break occurs.
So, it's better to prepare PQC support now. As an example of the actual movement, European Commission is trying to migrate from non-PQC to PQC.([link][ec-pqc]) ## Goal of the ticket The goal of this ticket is to add PQC support across standard libraries including default gems and bundle gems. PQC-supported algorithms are only ML-DSA, ML-KEM and SLH-DSA for now. ML-DSA and SLH-DSA used for signature (certification), and ML-KEM is used for connection. <s>As I heard from my colleagues working for OpenSSL, that SLH-DSA is not ready to be used, we can ignore SLH-DSA for now.</s> The details of the goal of this ticket is making sure that PQC, non-PQC multiple (dual) key exchange / certificate use cases work by adding unit or integration tests. I think adding ML-KEM for key exchange and ML-DSA for certification is necessary. However, I need to investigate if we need to support SLH-DSA. ## Notes ### PQC, non-PQC hybrid and multiple key-exchange algorithms, and multiple PQC (ML-DSA), non-PQC (RSA) certificate functionalities and migration ML-KEM, ML-DSA, SLH-DSA are algorithm groups. They has algorithms in them. ML-KEM has hybrid algorithms that both PQC and non-PQC client can connect: X25519MLKEM768, SecP256r1MLKEM768, SecP384r1MLKEM1024. X25519MLKEM768 is [hybrid algorithm of X25519 and MLKEM768][hybrid-ml-kem]. In my understanding, ML-DSA doesn't have such hybrid algorithm. So, TLS server need to support multiple certificates ML-DSA (PQC) and RSA (non-PQC). Supporting PQC, non-PQC hybrid and multiple key-exchange algorithms, and multiple PQC (ML-DSA), non-PQC (RSA) certificates server is important for people to migrate their TLS servers from non-PQC to non-PQC/PQC hybrid/multiple, and then to PQC only. If these are no hybrid/multiple key exchange and multiple certificates functionalities, people need to prepare multiple servers for exclusive PQC server and exclusive non-PQC servers. That's costy and complicated migration. ### Standardization status for PQC According to [nist-pqc], ML-KEM (FIPS 203), ML-DSA (FIPS 204), SLH-DSA (FIPS 205) specification is already final. However, there is uncertainty or adjustment about the future of ML-DSA. ML-DSA private CA is supported by some vendors. But the future of ML-DSA is [Merkle Tree Certificate (MTC)][mtc-ietf]-based or public-CA. MTC is a kind of alternative of public-CA. Google is promoting MTC on [their blog][mtc-google-blog]. MTC is [draft status][mtc-ietf] in IETF. [RFC 10024][rfc10024] is about ML-KEM hybrid key algorithms X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 for TLS 1.3. ## Proof of concept I manage my proof-of-concept scripts on my [junaruga/ruby-pqc-test] repository. For now, there are only some scripts to test RubyGems and Bundler in PQC use cases. ## Current status & affected libraries Ruby OpenSSL (ruby/openssl) already supports PQC by the ticket [ruby/openssl#894][ruby-openssl-pqc-issue] by adding ML-KEM, ML-DSA capabilities. However, we need to work for other standard libraries using Ruby OpenSSL in Ruby to support PQC. I investigated ruby/ruby including default gems and bundled gems at the master branch commit `93f1010f70a3ac924c3b37e4ae82cf1a669fcbf0` which was the latest at that time. While ruby/ruby original code doesn't have PQC logic, the following libraries that have the own upstream project need to be modified to support PQC use cases in my investigation. And I am motivated to work on these tasks, adding the PQC features and/or tests. I will open the issue ticket for each upstream project ruby/* one by one. * [ruby/rubygems](https://github.com/ruby/rubygems) - [issue link](https://github.com/ruby/rubygems/issues/9542) - Add PQC features * [ruby/rubygems bundler](https://github.com/ruby/rubygems/tree/master/bundler) - [issue link](https://github.com/ruby/rubygems/issues/9543) - Add PQC features * [ruby/net-http](https://github.com/ruby/net-http) - default gem - Update code comments and add PQC tests * [ruby/open-uri](https://github.com/ruby/open-uri) - default gem - Add PQC tests * [ruby/spec](https://github.com/ruby/spec) - spec/ - Add PQC tests * [ruby/drb](https://github.com/ruby/drb): bundled gem - [issue link](https://github.com/ruby/drb/issues/52) - Add PQC features * [ruby/rbs](https://github.com/ruby/rbs): bundled gem - Not sure. There is `stdlib/openssl/0/openssl.rbs`. Note I used the following [ripgrep]'s `rg` command (an enhanced `grep` command) to check the affected files by PQC. ``` $ rg "require +['\"]openssl['\"]|OpenSSL" --type ruby ``` Let me know what you think. [openssl-35-release]: https://openssl-library.org/post/2025-04-08-openssl-35-final-release/ [ruby-openssl-pqc-issue]: https://github.com/ruby/openssl/issues/894 [nist-wikipedia]: https://en.wikipedia.org/wiki/National_Institute_of_Standards_and_Technology [nist-pqc]: https://csrc.nist.gov/projects/post-quantum-cryptography [ec-pqc]: https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-... [mtc-ietf]: https://datatracker.ietf.org/doc/draft-ietf-plants-merkle-tree-certs/ [mtc-google-blog]: https://blog.google/security/cultivating-a-robust-and-efficient-quantum-safe... [digicert-blog-google-mtc]: https://www.digicert.com/blog/google-merkle-tree-certificates [hybrid-ml-kem]: https://www.postquantumsecurity.org/publications/X25519+MLKEM768.html [rfc10024]: https://www.rfc-editor.org/info/rfc10024/ [junaruga/ruby-pqc-test]: https://github.com/junaruga/ruby-pqc-test [ripgrep]: https://github.com/BurntSushi/ripgrep -- https://bugs.ruby-lang.org/
participants (2)
-
hsbt (Hiroshi SHIBATA) -
jaruga (Jun Aruga)