{
    "id": "https://brandonrozek.com/blog/post-quantum-security-adoption/",
    "url": "https://brandonrozek.com/blog/post-quantum-security-adoption/",
    "title": "On Post-Quantum Security Adoption",
    "authors": [
        
            { "name": "Brandon Rozek" }
        
    ],
    "content_html": "\u003cp\u003eFrom Alex\u0026rsquo;s \u003ca href=\"https://alexwlchan.net/2026/post-quantum-blog/\"\u003eblog post\u003c/a\u003e, I\u0026rsquo;ve learned that there are enough recent breakthroughs in quantum computing that I should take post-quantum cryptography seriously. \u003ca href=\"https://blog.google/innovation-and-ai/technology/safety-security/cryptography-migration-timeline/\"\u003eGoogle\u003c/a\u003e and \u003ca href=\"https://blog.cloudflare.com/post-quantum-roadmap/\"\u003eCloudflare\u003c/a\u003e both set a target of 2029 for having their systems secure against quantum computers. Similarly, the \u003ca href=\"https://www.ncsc.gov.uk/guidance/pqc-migration-timelines\"\u003eUK government\u003c/a\u003e is targeting 2035.\u003c/p\u003e\n\u003cp\u003eThe issue is that cryptography is built upon math problems that are difficult to solve. Quantum computers make solving some of these problems such as integer factorization and discrete logs easier. If someone has a quantum computer that can sufficiently solve those two problems, then they can likely decrypt many ciphertexts that were produced using \u003ca href=\"https://en.wikipedia.org/wiki/Public-key_cryptography\"\u003easymmetric cryptography\u003c/a\u003e techniques (think public/private key-pairs). Wikipedia has a great article discussing \u003ca href=\"https://en.wikipedia.org/wiki/Post-quantum_cryptography\"\u003epost-quantum cryptography\u003c/a\u003e if you want to read more.\u003c/p\u003e\n\u003cp\u003eGiven all that, if the cost isn\u0026rsquo;t too high then it\u0026rsquo;s not a bad idea to look at our current systems and see what we can make quantum-resistant today. Otherwise, we risk being vulnerable to \u003ca href=\"https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later\"\u003eharvest now, decrypt later\u003c/a\u003e attacks. This is where an adversary stores encrypted packets until they have a computer powerful enough to break the encryption. You might wonder if encrypted packets from 5 years ago matter. Though if you\u0026rsquo;re like me, chances are you had to transmit personally identifiable information over the internet for jobs, housing, etc. In the US, it is \u003ca href=\"https://www.ssa.gov/faqs/en/questions/KA-02220.html\"\u003ereally difficult\u003c/a\u003e to change your social security number.\u003c/p\u003e\n\u003cp\u003eWe\u0026rsquo;ll explore three different protocols I rely on and how we can make them post-quantum resistant.\u003c/p\u003e\n\u003ch2 id=\"ssh\"\u003eSSH\u003c/h2\u003e\n\u003cp\u003eOpenSSH implemented and made default post-quantum key agreement \u003ca href=\"https://www.openssh.org/pq.html\"\u003eback in April 2022\u003c/a\u003e. At the time of writing, the \u003ccode\u003emlkem768x25519-sha256\u003c/code\u003e scheme is used. That\u0026rsquo;s a mouthful but it essentially describes what the scheme is:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ccode\u003emlkem\u003c/code\u003e: \u003ca href=\"https://en.wikipedia.org/wiki/Lattice-based_cryptography\"\u003eModule lattices\u003c/a\u003e \u003ca href=\"https://en.wikipedia.org/wiki/Key_encapsulation_mechanism\"\u003ekey encapsulation mechanism\u003c/a\u003e (also known as key-exchange)\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003e768\u003c/code\u003e: Not sure what this means, sorry.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003ex25519\u003c/code\u003e: \u003ca href=\"https://en.wikipedia.org/wiki/Curve25519\"\u003eElliptic curve\u003c/a\u003e used in the classical Diffie-Hellman key-exchange.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003esha256\u003c/code\u003e: The hash function used to \u003ca href=\"https://datatracker.ietf.org/doc/draft-ietf-sshm-mlkem-hybrid-kex/\"\u003ecombine the keys\u003c/a\u003e generated from ML-KEM and x25519 (see Section 2.4 of previous link).\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eAs you might notice, this is a hybrid quantum/classical algorithm. This is a hedge. If quantum computers arrive which break the classical algorithm, then we\u0026rsquo;re safe. Similarly if we find out that the post-quantum algorithms are insecure, then we still have the well-developed classical ones. We can only hope that they\u0026rsquo;re both not found to be insecure.\u003c/p\u003e\n\u003cp\u003eIf you are using a client released after October 2025, then you\u0026rsquo;ll receive a warning if you\u0026rsquo;re connecting to a server that doesn\u0026rsquo;t support post-quantum encryption.\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e** WARNING: connection is not using a post-quantum key exchange algorithm.\n** This session may be vulnerable to \u0026#34;store now, decrypt later\u0026#34; attacks.\n** The server may need to be upgraded. See https://openssh.com/pq.html\n\u003c/code\u003e\u003c/pre\u003e\u003ch2 id=\"tls\"\u003eTLS\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"https://en.wikipedia.org/wiki/Transport_Layer_Security\"\u003eTransport Layer Security\u003c/a\u003e is a cryptographic protocol that underlies HTTPS and many other applications. You\u0026rsquo;re likely using it to connect to this website! Similar to OpenSSH, they introduced the hybrid scheme \u003ccode\u003eX25519MLKEM768\u003c/code\u003e for post-quantum security. The main difference that I can spot (as a non-cryptographer) is that this scheme does not hash the combined key. If you\u0026rsquo;re interested, you can read more at this \u003ca href=\"https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/\"\u003eIETF draft\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eIn terms of major browsers, Firefox has supported this since \u003ca href=\"https://www.firefox.com/en-US/firefox/132.0/releasenotes/\"\u003eOctober 2024\u003c/a\u003e and Chrome since \u003ca href=\"https://developer.chrome.com/release-notes/131\"\u003eNovember 2024\u003c/a\u003e. To use this scheme, however, both sides need to handle it. At the time of writing, \u003ca href=\"https://radar.cloudflare.com/post-quantum\"\u003eCloudflare\u003c/a\u003e estimates that 70.1% of Internet traffic is post-quantum encrypted. You can even use that link to check whether your own website supports post-quantum key exchange.\u003c/p\u003e\n\u003cp\u003eIf you find that your website is not post-quantum secure, then check out the \u003ca href=\"https://configurator.tlsref.org/\"\u003eTLSRef TLS Configurator\u003c/a\u003e. This provides the configuration options needed to support modern cryptographic protocols for a variety of popular web servers.\u003c/p\u003e\n\u003ch2 id=\"wireguard\"\u003eWireGuard\u003c/h2\u003e\n\u003cp\u003eWireGuard is a popular VPN technology that is known for being efficient and simple. By default, it is \u003ca href=\"https://www.wireguard.com/known-limitations/\"\u003enot post-quantum secure\u003c/a\u003e. However, we can use the \u003ccode\u003ePresharedKey\u003c/code\u003e field to mix a symmetric key whose underlying mathematical problems are not as impacted as asymmetric cryptography.\u003c/p\u003e\n\u003cp\u003eThe simplest solution here then is to run\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003ewg genpsk\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eand then \u003cem\u003esecurely\u003c/em\u003e add the key into the \u003ccode\u003ePresharedKey\u003c/code\u003e field.\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" style=\"color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\"\u003e\u003ccode class=\"language-ini\" data-lang=\"ini\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\u003cspan style=\"color:#66d9ef\"\u003e[Interface]\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\u003cspan style=\"color:#a6e22e\"\u003eAddress\u003c/span\u003e \u003cspan style=\"color:#f92672\"\u003e=\u003c/span\u003e \u003cspan style=\"color:#e6db74\"\u003e...\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\u003cspan style=\"color:#a6e22e\"\u003e...\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\u003cspan style=\"color:#a6e22e\"\u003ePrivateKey\u003c/span\u003e \u003cspan style=\"color:#f92672\"\u003e=\u003c/span\u003e \u003cspan style=\"color:#e6db74\"\u003e...\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\u003cspan style=\"color:#66d9ef\"\u003e[Peer]\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\u003cspan style=\"color:#a6e22e\"\u003ePublicKey\u003c/span\u003e \u003cspan style=\"color:#f92672\"\u003e=\u003c/span\u003e \u003cspan style=\"color:#e6db74\"\u003e...\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\u003cspan style=\"color:#a6e22e\"\u003e...\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\u003cspan style=\"color:#a6e22e\"\u003ePresharedKey\u003c/span\u003e \u003cspan style=\"color:#f92672\"\u003e=\u003c/span\u003e \u003cspan style=\"color:#e6db74\"\u003e...\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cp\u003eBoth sides of the connection need to use the same \u003ccode\u003ePresharedKey\u003c/code\u003e in order for the connection to work.\u003c/p\u003e\n\u003cp\u003eI\u0026rsquo;ll reiterate that we need to figure out a way to transfer the key \u003cem\u003esecurely\u003c/em\u003e for this to work. WireGuard doesn\u0026rsquo;t have a built-in way to share these keys. If you want to go with this simpler static preshared key route, then I suggest that you use a post-quantum secure channel (like a modern SSH setup) to distribute the keys.\u003c/p\u003e\n\u003cp\u003eThe downside of setting the preshared key on both sides once and then moving on is that the tunnel is then not post-quantum forward secret. This means that if an adversary with access to a sufficiently powerful quantum computer additionally gets access to the preshared key, they can then decrypt all future ciphertexts.\u003c/p\u003e\n\u003cp\u003eIf we want to protect against this, then we\u0026rsquo;ll need to run a post-quantum key exchange protocol on top of WireGuard. At the time of writing, \u003ca href=\"https://github.com/rosenpass/rosenpass\"\u003eRosenpass\u003c/a\u003e seems to be the simplest way to set this up. They automatically update the preshared key securely within WireGuard every two minutes.\u003c/p\u003e\n\u003cp\u003eWhile that is one solution, the space here seems fragmented. Another approach \u003ca href=\"https://ieeexplore.ieee.org/abstract/document/9519445\"\u003eupdates the protocol itself\u003c/a\u003e and many VPN providers \u003ca href=\"https://prod-assets-cms.mtech.xvservice.net/files/xv/Post-Quantum-WireGuard_-A-Practical-Implementation-Guide.pdf\"\u003ehandle it their own way as well\u003c/a\u003e.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eEven though we\u0026rsquo;re not at \u003ca href=\"https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later\"\u003eY2Q or Q-day\u003c/a\u003e, we can still take steps to make sure that we\u0026rsquo;re transmitting information over the Internet in a quantum-resistant way. In the meantime, I\u0026rsquo;ll dream about the day when I can run a quantum computer in my pocket.\u003c/p\u003e\n",
    "date_published": "2026.06.15",
    "tags": [],
    "_syndication": {
        "mastodon": {
            "enabled": false,
            "toot_id": null,
            "toot_text": ""
        },
        "medium": {
            "enabled": false,
            "post_id": null
        }
    }
}