{"id":23246,"date":"2024-09-04T21:00:39","date_gmt":"2024-09-04T17:00:39","guid":{"rendered":"https:\/\/me-en.kaspersky.com\/blog\/postquantum-cryptography-2024-implementation-issues\/23246\/"},"modified":"2024-09-04T21:00:39","modified_gmt":"2024-09-04T17:00:39","slug":"postquantum-cryptography-2024-implementation-issues","status":"publish","type":"post","link":"https:\/\/me-en.kaspersky.com\/blog\/postquantum-cryptography-2024-implementation-issues\/23246\/","title":{"rendered":"Where and how post-quantum cryptography is being used in 2024"},"content":{"rendered":"

We regularly hear news<\/a> about breakthroughs<\/a> leading to the advent of working quantum computers. For now, such a computer doesn\u2019t exist, so nobody can use one to crack encryption<\/a>. But when it does arrive, it\u2019ll already be too late to address the problem. That\u2019s why new encryption algorithms that are resistant to both classical hacking methods and quantum-computer attacks are being standardized today. These algorithms are known as post-quantum or quantum-resistant. Support for these algorithms is gradually appearing in everyday devices and applications \u2014 they were recently integrated into Google Chrome. This, by the way, immediately exposed compatibility issues within standard organizational IT infrastructures. So, where have post-quantum algorithms already been implemented, and what should IT teams prepare for?<\/p>\n

Which services already support post-quantum algorithms?<\/h2>\n

Amazon. <\/strong>The cloud giant introduced a \u201cpost-quantum\u201d variant of TLS 1.3<\/a> for its AWS Key Management Service (KMS) back in 2020. Since then, the solution has been updated, adapting its configuration settings in line with NIST recommendations.<\/p>\n

Apple iOS\/iPadOS\/macOS. <\/strong>In February 2024, Apple announced an update to the iMessage protocol<\/a>, which will use the PQ3 quantum-resistant protocol for key exchange. It\u2019s based on the NIST-recommended Kyber algorithm, but also utilizes classical elliptic-curve cryptography<\/a>, providing dual-layer encryption.<\/p>\n

Cloudflare.<\/strong> Since September 2023, Cloudflare has supported post-quantum key agreement algorithms<\/a> for establishing connections to origin servers (client websites), and is gradually rolling out support for post-quantum cryptography for client connections. The technology is used when establishing a TLS connection with compatible servers\/clients, applying a dual key agreement algorithm: classical X25519 for one part of the key, and post-quantum Kyber for the other. This popular combination is known as X25519Kyber768.<\/p>\n

Google Chrome.<\/strong> Test support for post-quantum cryptography for establishing TLS connections appeared in August 2023, and as of version 124 in April 2024, it\u2019s enabled by default. The algorithm used is X25519Kyber768.<\/p>\n

Mozilla Firefox.<\/strong> Support for X25519Kyber768 for TLS and QUIC appeared at the beginning of 2024, but it\u2019s still not enabled by default and must be activated manually.<\/p>\n

Mullvad.<\/strong> This popular VPN service uses<\/a> the following PQC method: first, a traditional encrypted connection is established, after which a new key agreement is conducted using the Classic McEliece and Kyber algorithms. The connection is then re-established with these keys.<\/p>\n

Signal. <\/strong>The messenger implemented the PQDXH protocol<\/a> in September 2023, using the same X25519Kyber768 mechanism.<\/p>\n

Tuta(nota).<\/strong> The popular secure email service allows users to send post-quantum encrypted emails<\/a> using the X25519Kyber768 algorithm. However, the obvious drawback is that this only works when communicating with other Tuta users.<\/p>\n

Although not yet a commercial product, it\u2019s also worth mentioning Google\u2019s implementation of FIDO2 hardware security keys<\/a>, which use a combination of classical ECDSA and post-quantum Dilithium.<\/p>\n

In addition to these, PQC is supported by numerous libraries that serve as the foundation for other products, from email and web servers to operating systems. Notable libraries include OpenSSL<\/a> and BoringSSL<\/a>, as well as the experimental<\/a> branch of Debian. Many of these implementations have been made possible thanks to the Open Quantum Safe<\/a> initiative, which supports post-quantum forks of popular cryptographic utilities and libraries, available for a variety of popular programming languages.<\/p>\n

The main drawbacks of quantum-resistant cryptography<\/h2>\n
    \n
  1. The algorithms haven\u2019t been sufficiently analyzed. Although the broader scientific community has been conducting cryptanalysis for several years, the mathematical principles behind post-quantum cryptography are more complex. Moreover, experience with classical cryptography shows that serious flaws or new attack methods can sometimes be discovered decades later. It\u2019s almost certain that vulnerabilities will be found in modern PQC algorithms \u2014 not just implementation vulnerabilities<\/a>, but fundamental algorithmic defects<\/a>.<\/li>\n
  2. Key sizes are significantly larger than in RSA and ECC. For example, the Kyber768 post-quantum algorithm has a public key size of 2400 bytes. This leads to a significant increase in data transmission volumes if key renegotiation occurs frequently. In tightly designed or low-power systems, there might not be enough memory for such large keys.<\/li>\n
  3. The computational load of PQC is also higher than classical, which slows down operations and increases energy consumption by 2\u20133 times. However, this issue may be resolved in the future with optimized hardware.<\/li>\n
  4. Compatibility issues. All updates to encryption standards and protocols \u2014 even classical ones \u2014 create complications when some systems have been updated and other related ones haven\u2019t.<\/li>\n<\/ol>\n

    Post-quantum compatibility problems<\/h2>\n

    Practical issues will primarily affect services using the TLS protocol for connections. TLS is implemented in numerous ways across thousands of products \u2014 sometimes with errors. As soon as Google enabled Kyber support by default in Chromium 124, administrators started reporting<\/a> that Chrome and Edge couldn\u2019t establish connections with web servers, as they would immediately disconnect with an error after the ClientHello TLS handshake. This issue was caused by problem number two: the large key size. As a result, the ClientHello TLS message, which always fitted into a single TCP packet, expanded into multiple packets, and so servers, proxies, and firewalls not prepared for this larger ClientHello message would immediately terminate the connection. Appropriate behavior would involve reading the following packets and agreeing on an older, classical encryption algorithm with the client. A list of incompatible web servers and firewalls affected by this issue is being tracked on a dedicated site<\/a>, with Cisco notably listed.<\/p>\n

    If an organization suddenly can\u2019t open any websites, the problem is likely with the proxy or firewall, which needs an update. Until the developers of incompatible applications and devices release patches, a temporary solution is to disable PQC:<\/p>\n