In August, NIST published FIPS 203, FIPS 204, and FIPS 205, the first standards for Post-Quantum Cryptography (PQC).

Though we do not yet have a cryptography-relevant quantum computer, it is important to begin adopting algorithms that will continue to be secure after one has been built in the future. NIST prioritized PQC to give the technology industry adequate time to migrate their cryptography. This decision was partly informed by the failure of NSA and NIST to migrate everyone off RSA and towards Elliptic Curve Cryptography, even years after they published Suite B.

As W3Techs has reported over the years, the majority of websites on the Internet whose server-side language is detectable are powered by PHP. It stands to reason that making these algorithms available to the PHP community could make an enormous difference in the adoption of Post-Quantum Cryptography.

The Roadmap to Post-Quantum PHP

We recently released an open source library that implements Hybrid Public-Key Encryption (HPKE, RFC 9180). It presently only supports the DHKEM methods, using elliptic curve cryptography libraries (libsodium and our PHPECC fork). Let's put a pin in this for a moment.

We emailed the PHP internals mailing list this morning to discuss whether OpenSSL's KEM API can be incorporated into PHP's OpenSSL extension without an RFC. If it requires one, we will create one. If it doesn't, we will instead cut a pull request (and update the documentation).

Depending on the outcome of getting KEM support in ext-openssl for PHP 8.5, we will go ahead and write a pure-PHP implementation of the NIST post-quantum cryptography standards. As with our previous efforts to deliver modern cryptography to PHP, we will defer to a native code implementation where possible. Thus, if we can use ML-KEM from ext-openssl, our code will do that instead of using our own implementations.

As far as ML-DSA and SLH-DSA go, the existing signature APIs used by OpenSSL should already be compatible with those algorithms. Therefore, we plan to provide implementations regardless of the PHP internals' discussion.

Fringe Benefits of This Work

Although there are some obvious benefits to having post-quantum cryptography available in the application layer for PHP developers, a less obvious one is the ability to implement Messaging Layer Security (MLS, RFC 9420) in PHP.

You see, MLS uses HPKE under-the-hood. When PQC adoption becomes more widespread, this will probably manifest in an extended ciphersuite for MLS. The OpenMLS Project has already added X-Wing support.

MLS is currently being sought for adoption by various private messaging apps.

Being able to use MLS from a PHP application means being able to write bots and useful automation that speak these end-to-end encrypted protocols in PHP. Ideally, other languages would follow suit soon after.

Post-Quantum PASETO and PASERK

Last year, we wrote the first draft for PASETO protocol versions 5 and 6, as well as congruent versions for Post-Quantum PASERK.

The algorithm breakdown for these new protocols (as of the current draft) would look like so:

• PASETO Version 5 (intended for FIPS / CNSA 2.0 compliant systems)
  • v5.local: Unchanged from v3.local, sans the header
  • v5.public: ML-DSA-87
  • PASERK Version 5
    • k5.seal: ML-KEM-1024, SHA-384, AES-256-CTR, HMAC-SHA-384
• PASETO Version 6 (intended for widespread use outside of government systems)
  • v6.local: Unchanged from v4.local, sans the header
  • v6.public: SLH-DSA-SHA256-128s
  • PASERK Version 6
    • k6.seal: X-Wing (ML-KEM-768 + X25519), XChaCha20, BLAKE2b

The Version 5 suite uses the CNSA 2.0 recommended algorithms (in sum, it demands the largest lattice-based keys available). Conversely, the Version 6 suite uses a hybrid post-quantum KEM for asymmetric encryption of a shared key.

Note that the encryption did not need to change from v3/v4. We briefly considered AEGIS-256 for v6.local, but the key-committing property of our construction is too valuable to give up (especially in a system with Key IDs).

The Journey Has Just Begun

It's important to note that we're still in the early days of post-quantum cryptography adoption, especially in the PHP ecosystem. Where we end up in 5, 10, or even 20 years from now might look vastly different than we've sketched out above, especially if new cryptography research yields more efficient ways to achieve the desired level of security.

This is where things stand today, and how we plan to move PHP (and, hopefully, the entire Internet) forward.