post-quantum authentication in Prague

Merkle Tree Certificates

Merkle Tree Certificates were one of the most interesting approaches for me. the idea is to authenticate certificates through their inclusion in a signed Merkle tree, allowing many certificates to share authentication work

that changes what a connection needs to carry. a verifier with the necessary trusted tree state can use a compact inclusion proof instead of repeatedly receiving the same larger authentication material. this addresses certificate overhead; it does not automatically remove the separate signature used to authenticate a TLS handshake

there is an operational side to that saving. the Let's Encrypt paper explains why a Merkle Tree Certificate Authority needs careful coordination around its log. conflicting histories are a security problem, so issuance, replication and recovery need to preserve one consistent history. the paper describes implementation work, not a completed production rollout

TrustAsia's paper follows a test deployment through issuance, independent witnessing and browser verification. the realm is explicitly for untrusted validation testing. its integration work also makes a practical point: certificates, browser support and the distribution of trusted tree state must move together

i find this promising because it asks whether we can avoid repeating expensive authentication material, while making the new state and distribution requirements explicit

HSMs and the life of a signing key

hardware security modules matter because many important signing keys live there: certificate authorities, firmware signing systems and other infrastructure cannot simply replace a software library and declare the migration finished

the Crypto4A contribution looks at that larger problem, including interfaces, validation and the lifecycle of keys across hardware, software and firmware. support for a mathematical primitive is only one part of usable HSM support

stateful hash-based signatures add a particularly concrete constraint. with schemes such as LMS/HSS, a one-time signing key must never be reused. backups, failover and recovery therefore have to preserve signing state correctly. restoring an old copy can be a cryptographic failure, not just an availability incident. this is different from SLH-DSA, which is stateless

for me, the useful question is what happens to the key over ten years: how it is provisioned, used, backed up, replaced and recovered when something fails

migration order matters

migration is a sequence of dependencies. a device may need new firmware before it understands a new signature, a new trust anchor before it accepts a new certificate, and an updated management system before either change can be delivered safely

the Nokia and University of the Bundeswehr contribution describes these constraints in enterprise networks, including manufacturer credentials, operator trust and product validation. changing those in the wrong order can leave a device unable to authenticate the system responsible for updating it

there is also a difference between supporting post-quantum authentication and requiring it. if an attacker can still use an accepted classical authentication path, adding another algorithm has not removed that path

the cross-signed certificate paper adds another useful detail: algorithm support does not guarantee that a client and server will select a usable certificate chain. trust stores and chain-building behavior need their own interoperability checks

this connects directly to my crypto-agility.json proposal: making cryptographic capabilities, evidence and migration status discoverable. we need to know what a system uses, what it can accept and what it is allowed to fall back to before deciding how to move it. publishing a manifest helps expose those questions; it does not enforce the migration policy

the bytes around the cryptography

PQShield's embedded-systems contribution highlights a problem that primitive benchmarks can miss: the cryptographic operation may fit on a device while the surrounding middleware runs out of memory. buffers, copies and integration layers all count

the Cisco SD-WAN paper looks at another part of the same problem. larger authentication messages can mean more datagrams and more retransmission under loss. its transport modeling makes a case for considering the DTLS migration alongside the cryptographic migration, rather than treating network overhead as an afterthought

these are useful checks for my own performance work. signing and verification times matter, but so do peak memory, certificate processing, packet loss and the time until a connection becomes usable

moving authentication work earlier

Mozilla's TLS Preflight proposal explores authenticating short-lived key material before the connection, using Merkle Tree Certificates and DNS publication, then using that material to establish a TLS pre-shared key

it is a proposal, with deployment and standardization work still ahead. what interests me is the architectural question: which authentication work must happen during the handshake, and which work could happen earlier with appropriate freshness and trust checks?

that question connects several of these papers. we can optimize an implementation, reduce repeated certificate material, change when work happens, or improve the transport carrying it. each approach has different costs and assumptions

i came to Prague interested in how post-quantum authentication becomes practical. these materials give me a more concrete way to evaluate it: follow the whole path from key storage to certificate delivery, verification, failure and recovery. that is the level where a promising algorithm becomes infrastructure people can actually operate