Archives May 2026

What an Australian payments paper says about NZ banks

A new arXiv preprint runs the numbers on something every Australian bank — and by extension every NZ subsidiary of one — should already have answered: can post-quantum signatures actually run inside a real-time payments SLA?

Reference: arXiv 2605.02276v1, 4 May 2026.

The simulation covers Australia’s real-time retail payments rail at production volume — 5.2 million transactions a day, two-second SLA. The headline answer is boring, which is the point: the lattice-based algorithms (ML-DSA, Falcon) add roughly 1–2 milliseconds to a transaction that already takes 40–45 ms end-to-end. The argument that real-time payments cannot afford post-quantum cryptography is, on the numbers, finished.

The interesting findings sit elsewhere.

SPHINCS+ — the hash-based signature standard NIST published as a backup to the lattice schemes — chokes the signing infrastructure at retail payment volumes. Not a little: the hardware queue saturates, transactions back up indefinitely, and the paper characterises this as a denial-of-service surface in its own right. Any insider with the wrong configuration access can effectively freeze a bank’s signing pipeline by selecting the wrong algorithm. SPHINCS+ has a legitimate role in low-frequency, high-assurance contexts — settlement, correspondent banking — but you have to architect it to stay there. The migration plan that quietly leaves it as a fallback option is the migration plan that hands an insider a DoS button.

The second finding is more mundane and more decision-forcing: the SWIFT message format that underpins international correspondent banking has a 2 KB payload limit older than post-quantum cryptography itself, and only one of the new signature algorithms (Falcon-512) is small enough to fit inside it. Every other option overflows. Banks running cross-border traffic over the legacy format don’t really have an algorithm choice — they have a Falcon choice they may not realise they’ve already made.

The NZ read

Our Big 4 are subsidiaries of theirs. The cryptographic decisions protecting retail payments in Auckland are in practice being made in Sydney and Melbourne — and our April scan showed exactly one of them, ANZ, actually running post-quantum cryptography on infrastructure they control.

The Australian regulator has put cryptographic risk on the agenda. Ours hasn’t. Retention obligations under our AML/CFT Act 2009 are the same seven-year shape as theirs. The harvest-now-decrypt-later clock is running on the same data, archived in the same data centres, governed by largely the same head offices. This paper is what a serious early answer looks like. The corresponding New Zealand work has not been done.

There is, as ever, no prize for going last.


Kaysec is the post-quantum security practice of Spinsphere, a New Zealand-based quantum technology company. We help NZ organisations with cryptographic inventory, HNDL risk assessment, and PQC migration planning. Get in touch.

The 10 KB and 40 KB Cliffs: PQC Certificate Bloat as a Network Problem

A new arXiv preprint from Chou and Cao (UIUC / NCSA) puts numbers on the network cost of PQC certificate bloat. The headline: TTFB doesn’t degrade smoothly as chains grow — it steps up at two specific points where chain size breaches TCP’s flight windows.

Reference: arXiv 2604.24869v1, 27 April 2026.

The cliffs

The first cliff sits at ~10 KB. IW=10 caps first-RTT data at ~14 KB; cross it and you’re paying an extra round-trip. The second sits around 40 KB, where slow-start doubling combines with IW to give an effective threshold near 42 KB.

ML-DSA-44 with two intermediates lands at ~12 KB — already past the first cliff. SLH-DSA-192s blows past both. The authors measure up to ~1.5x TTFB inflation in extreme RTT cases purely from threshold crossings. Propagation delay alone barely moves the needle.

What works

Three mitigations evaluated, very different effectiveness ratios:

  • MTC: ~2–3x headroom. A Merkle proof in place of X.509 intermediates keeps a chain that would otherwise breach the 10 KB cliff under it (draft-ietf-plants-merkle-tree-certs).
  • CDN chain optimisation: ~1.6x headroom. Useful, not enough on its own for SLH-DSA.
  • Session resumption: extremely effective when it applies. Their NCSA Zeek data shows 94% resumption on CDN TLS 1.3 vs 46% non-CDN. Resumed sessions skip certificate transmission entirely. CDNs realised ~2x the TTFB savings of non-CDNs.

Why it matters here

Two compounding factors for NZ.

Distance amplifies every extra RTT — 120–200+ ms intercontinental is normal for us. A 12 KB ML-DSA chain to a US-East origin becomes a 150–200 ms penalty on every cold handshake, on top of the baseline.

NZ runs heavy on CDN edges precisely because of that distance. The finding that CDN-side mitigations recover most of the loss is good news — but only if your service is actually fronted, and only if your resumption rate looks like the NCSA aggregate. For first-touch flows, it almost certainly doesn’t.

Caveats

OQS stack overhead dominated absolute TTFB in the testbed (~50–55 ms attributable to implementation, not network), and packet loss and fragmentation weren’t measured directly. The thresholds themselves are real, though, and the qualitative finding — that PQC migration risk is a network-shape problem, not just a crypto-correctness problem — is the framing worth taking forward.