Is This Site Post-Quantum Ready?

I write about security, so I should practise it. With NIST’s post-quantum cryptography (PQC) standards now published and Cloudflare, Chrome, and OpenSSH already shipping hybrid PQC by default, I decided to run a proper readiness assessment against this site — the infrastructure, the build pipeline, and every cryptographic touchpoint in between.

Here’s what I found.

The cryptographic inventory

Before you can assess PQC readiness, you need to know where cryptography lives. For a static Astro site on Cloudflare Pages with GitHub Actions CI, the surface is smaller than a typical web application, but it’s not zero.

TLS (visitor connections)

This site is served through Cloudflare, which has negotiated hybrid PQC key exchange (X25519MLKEM768) for TLS by default since late 2024. Any visitor with a modern browser — Chrome 124+, Firefox 128+, Edge 124+ — is already getting post-quantum key agreement on every connection to this site.

I didn’t have to configure anything. Cloudflare enables this at the edge automatically. You can verify it yourself:

openssl s_client -connect jonathanstrong.org:443 -groups X25519MLKEM768

Verdict: PQC-ready. Hybrid key exchange is active. Classical fallback (X25519) is available for older clients.

CSP script hashes (SHA-256 → SHA-512)

The site’s Content Security Policy in public/_headers uses hash-based allowlisting for inline scripts. A post-build verification script (scripts/verify-csp-hashes.mjs) recomputes these hashes and fails the build on mismatch.

Before this audit, the hashes used SHA-256. SHA-256 is quantum-resistant — Grover’s algorithm reduces brute-force preimage search from 2²⁵⁶ to 2¹²⁸, which is still computationally infeasible. So there was no immediate vulnerability.

But CSP supports SHA-512, and the change is trivial: update the hash algorithm in the verification script and regenerate the hashes in _headers. SHA-512 gives a post-quantum security margin of 2²⁵⁶ — the same margin SHA-256 provides classically today — and aligns with CNSA 2.0, which approves SHA-384 and SHA-512 for all uses.

script-src 'self' 'sha512-u6gNGUVBdYA/SC+1XRAkLH/...' ...

Running this assessment surfaced an easy win: a two-line change to the build script and a hash regeneration. Not urgent, but why leave security margin on the table when the cost is near zero?

Verdict: upgraded to PQC-ready. Moved from SHA-256 to SHA-512.

HSTS and transport security

The _headers file enforces:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

HSTS itself has no cryptographic algorithm dependency — it instructs browsers to use HTTPS, and the underlying TLS negotiation handles algorithm selection. Since Cloudflare’s TLS is already hybrid-PQC, HSTS is fine as-is.

Verdict: PQC-ready.

GitHub Actions supply chain

All workflows pin actions to full commit SHAs rather than mutable tags. This is a supply chain integrity measure, not a PQC concern directly — but the hashing matters.

Git uses SHA-1 for commit hashes. SHA-1 is not quantum-resistant (Grover’s algorithm reduces it to 2⁸⁰, and classical collision attacks already exist). However:

• GitHub is migrating to SHA-256 for Git object hashing.
• The threat model for commit SHA pinning is collision attacks on the commit hash, which are already mitigated by GitHub’s SHA-1 collision detection (shipped since the SHAttered attack in 2017).
• Quantum attacks on SHA-1 preimage resistance would require a fault-tolerant quantum computer that doesn’t exist yet, and by the time it does, the Git SHA-256 migration should be complete.

The step-security/harden-runner in all workflows monitors egress and blocks unexpected network calls, adding defence-in-depth regardless of hash algorithm.

Verdict: acceptable risk. SHA-1 in Git commit pinning is a known limitation of the Git ecosystem, not something I can fix at the repository level. The SHA-256 migration is underway upstream.

Trivy and dependency scanning

The trivy.yml workflow scans for known vulnerabilities and uploads SARIF results. Trivy’s own integrity was a concern after the March 2026 supply chain compromise, but the action is SHA-pinned and the binary integrity is verified.

No PQC-specific dependency scanning exists yet in any major tool. This is a gap across the industry, not specific to this site.

Verdict: no PQC-specific action available. Worth revisiting when tools add quantum-readiness checks.

Webmention API calls

The site makes authenticated API calls to webmention.io using a server-side API key. The key is transmitted over HTTPS (TLS to webmention.io). Whether that connection uses hybrid PQC depends on webmention.io’s server configuration, which I don’t control.

The API key itself is a bearer token — a symmetric secret. Symmetric cryptography (AES, HMAC) is quantum-resistant with sufficient key length. The risk here is HNDL interception of the TLS session carrying the token, but since the token can be rotated and has no long-term confidentiality value, this is low risk.

Verdict: low risk. The token is short-lived and rotatable. Upstream TLS PQC support is outside my control.

Node.js crypto usage

The build pipeline uses createHash("sha512") for CSP verification and crypto.randomUUID() for generating component IDs. Both are fine:

• SHA-512: quantum-resistant (as discussed above).
• randomUUID(): uses a CSPRNG. Quantum computers don’t break random number generation.

Verdict: PQC-ready.

No subresource integrity (SRI)

The site doesn’t load external scripts, so SRI attributes aren’t present. This is actually the most PQC-resilient approach — no external resources means no integrity hashes to worry about, and no third-party TLS connections to audit.

Verdict: not applicable (and that’s ideal).

Summary

What this means

This site is in a strong position. The most important cryptographic operation — TLS to visitors — was already quantum-resistant without any changes on my part. Running this audit also surfaced an easy improvement: upgrading the CSP and build-time hashes from SHA-256 to SHA-512, aligning with CNSA 2.0 guidance for near-zero cost.

The only area where a quantum-vulnerable algorithm is in use (SHA-1 in Git) is an ecosystem-wide limitation that GitHub is actively addressing. There’s nothing to do at the repository level except keep actions SHA-pinned (which is already the practice) and move to SHA-256 commit hashes when Git and GitHub complete the migration.

For a static site with no server-side computation, no database, no user authentication, and no long-lived secrets, the attack surface for quantum threats is genuinely minimal. The real PQC work — migrating key exchange, certificates, and signatures — sits with Cloudflare and GitHub, both of whom are ahead of most of the industry.

If you’re assessing your own systems, the approach is the same: inventory every cryptographic touchpoint, check whether each algorithm is quantum-resistant, and focus your energy on the gaps. For most people, the biggest win is confirming that their TLS provider already supports hybrid PQC key exchange — and in 2026, most major providers do.

This post was written with the help of Claude.