Fourteen cryptography ideas that fit on a shirt

Most of what follows is something I have had to explain more than once, usually to a competent engineer who had simply never had it put plainly. That was the test for putting one on a shirt: it has to be a real distinction, it has to survive being compressed to a few words, and it has to still be true after the compression.

Fourteen of them made it. Here is what each one actually says.

Asymmetry and hidden knowledge

Trapdoor. A trapdoor function is easy to compute and hard to invert, unless you hold the secret information that makes inversion easy. Everyone can go one way. Only the holder has an efficient way back. RSA is the canonical example. Not all public-key cryptography works this way: Diffie-Hellman and hash-based signatures do not fit the trapdoor-function model at all, while lattice cryptography covers several different constructions, some of which do use trapdoors. The trick underneath is always the same, which is to make something cheap for the intended party and infeasible for everyone else. The guarantee is computational rather than absolute: without the trapdoor, inversion should stay infeasible at the chosen security level. If cryptanalysis makes it efficient enough, the construction fails without anyone having to guess the key.

Prove without telling. A zero-knowledge proof convinces a verifier that a statement is true while revealing nothing beyond its truth. In a zero-knowledge proof of knowledge the verifier is also convinced that the prover knows a corresponding witness, still without learning the witness itself. The two are not the same property and the distinction gets flattened constantly. What also gets skipped is that all of it rests on the assumptions the proof system is built from, and those assumptions are not uniform. Some hash-based systems can be built from assumptions believed to resist quantum attack, though the complete protocol still needs quantum-aware analysis. Systems whose soundness rests on discrete logarithms in the elliptic-curve or pairing groups used today are not post-quantum secure.

The algorithm is not the whole attack surface

Side channel. The algorithm can be sound and the implementation can still leak. Timing, power draw, electromagnetic emission and cache behaviour can all carry information the specification never mentions. An attacker does not need to break the cipher if the machine running it says enough. This is why "we use AES-256" answers the algorithm question and leaves the implementation question untouched.

Padding oracle. A system that tells you whether padding was valid has said more than it meant to. An attacker who can submit modified ciphertexts and distinguish valid padding from invalid gets one bit of feedback per query. Repeated adaptively, that is enough to recover the plaintext without ever recovering the key. The oracle does not have to be an error message. A timing difference works. A different response length works. Vaudenay published this against CBC in 2002, and related oracle failures kept resurfacing for more than a decade afterwards. Lucky Thirteen in 2013 was a timing attack on TLS CBC record processing; POODLE in 2014 exploited SSL 3.0 padding validation together with a downgrade. Different mechanisms, same shape: the leak lives in how the receiver handles a bad record, not in the cipher.

Constant time or it did not happen. Code that branches on secret data, or indexes memory with it, can leak information about that data through how long it takes to run. A constant-time implementation removes secret-dependent variation from its execution pattern: no secret-dependent branches, no secret-dependent memory accesses, and no operations whose timing depends on secret values. It addresses secret-dependent timing and cache leakage. It does not by itself address power, electromagnetic or fault channels, which is a different budget. The phrasing on the shirt is deliberate. An implementation that is not constant time in the paths touching secrets leaves a potential timing channel open, whatever the test vectors say.

Four distinctions that get collapsed

Encoding is not encryption. Base64 is not a cipher. Encoding changes how data is represented so it survives a transport that would otherwise mangle it, and anyone can reverse it without a key. Encryption uses a key and is designed to make recovery infeasible without the matching decryption key. The confusion is not academic: it is how credentials end up in logs, in tickets, and in config files that somebody believed were protected.

#ifndef is not #if. #ifndef FLAG asks whether FLAG exists. #if FLAG asks whether its value is nonzero, so a macro defined as zero behaves differently under the two tests. And an undefined name in #if is replaced with zero rather than raising an error: a misspelling in #if FLAG silently selects the false branch, and the same misspelling in #if !FLAG silently selects the true one. The build succeeds either way. It is a preprocessor detail rather than a cryptographic one, and in security-sensitive code silently taking the wrong branch is exactly the failure mode you do not want. Good builds enable -Wundef.

Meet in the middle. Naively applying a block cipher twice under two independent keys does not give you twice the security. Given a known plaintext and ciphertext pair, compute forward from the plaintext, backward from the ciphertext, and match in the middle. For two independent k-bit keys the attack costs roughly 2^(k+1) cipher evaluations and 2^k stored intermediates, rather than the 2^(2k) the key length suggests. That is about one extra bit of work over the single-key case, bought with an enormous amount of storage. It is one reason the multiple-encryption successor to DES was Triple DES rather than Double DES, and why "we encrypt it twice" is not a security argument.

Trust me, I am a random oracle. The random oracle model treats the hash as an ideal public random function: anyone can query it, repeated queries return the same answer, and the output at a previously unseen input behaves as an independent random value. No real hash function is that. Proofs in the model are still worth having, and Canetti, Goldreich and Halevi showed in 1998 that schemes exist which are secure in the model and insecure under every concrete instantiation. That result is existential and uses schemes built to break: it does not say an ordinary construction falls over once you instantiate it with SHA-256. What it does say is that a proof in the model is a conditional result about an idealised object, and it does not transfer to a concrete hash for free.

Keys have a lifetime, and so does trust

Forward secrecy. Forward secrecy protects past sessions against later compromise of long-term keys. Protocols that provide it use fresh per-session key-establishment secrets and erase them once they are no longer needed. Steal the server's authentication key tomorrow and yesterday's ECDHE sessions stay closed.

That guarantee has a separate quantum limit, and it is a commonly missed one. Classical ECDHE still provides forward secrecy against compromise of the long-term authentication key. It does not protect a recorded transcript from future quantum cryptanalysis of ECDHE itself, because the ephemeral exchange is in the transcript. Resisting harvest now, decrypt later therefore requires quantum-resistant key establishment as well, which is why the migration work replaces or hybridises the key exchange rather than only the signatures.

Key ceremony. A key ceremony is a scripted, witnessed and auditable procedure for generating, activating, rotating or destroying a high-value key. It often uses split knowledge, dual control or threshold shares so that no single person can act alone, though it does not have to split the key itself: ICANN's DNSSEC root ceremonies keep the key inside an HSM and distribute control of what is needed to activate it. The ceremony turns trust into a procedure that can be verified afterwards. The formality is the point: the script, the witnesses, the logs and the recordings are what produce evidence that the controls were followed. A procedure with no witness and no record is a procedure nobody can attest to.

The quantum clock is set by your data

These three are one argument in three pieces, and the argument is the one most often stated backwards.

Harvest now, decrypt later. Traffic whose session secrets are established solely through quantum-vulnerable public-key mechanisms can be recorded today and stored until it becomes readable. An adversary does not need to break the key establishment now, only to keep the ciphertext and the handshake until a cryptographically relevant quantum computer can recover the session secret from the recorded key exchange. An adversary who values the data can begin long before possessing any quantum capability.

Decrypt on Q-Day. Q-Day is shorthand for the point at which a cryptographically relevant quantum computer can practically break widely deployed quantum-vulnerable public-key cryptography such as RSA and elliptic-curve systems. Some recorded sessions may then become decryptable, depending on how their keys were established. The collection happens now. The decryption waits for hardware that, as of August 2026, is not publicly known to exist.

I survived Y2Q. Y2Q expands to years to quantum and deliberately echoes Y2K. The difference is that Y2K came with a date printed on the calendar and Y2Q does not. Nobody knows when the threshold arrives, which is exactly why the migration has to happen before it does.

Put together, they say something specific: your migration deadline is not Q-Day itself. Mosca states it as an inequality. Let x be the confidentiality lifetime, y the migration time, and z the time until a capable machine exists. Once x + y > z, starting immediately is no longer early enough to cover the full exposure window.

All three terms matter, but they are not the same kind of thing. z is about the hardware and nobody controls it. x comes from the data and the obligations attached to it, usually set by law, contract or the value of the thing rather than chosen. y comes from your systems and your programme, and it is the term you can influence most directly. In practice y and z are not known precisely enough for equality to count as a safety margin.

That is why an organisation with a two-year confidentiality requirement and an organisation with a twenty-five-year one are not on the same schedule, even though they are waiting for the same machine.

The shirts

The fourteen above are the concept designs. Three identity designs round out the shop: the Mark, the Wordmark and the Lockup, which are the shield on its own, the name on its own, and both together with the line that says what the work is. They are there because some things should be legible without explaining themselves.

Each concept listing gives the longer explanation behind the line, which is the part that took the longest. The artwork is the punchline and the description is the setup, and a punchline printed without its setup is just a private joke on a chest.

See the shirts

Sources: in order of first appearance.

1. NIST, "Zero-Knowledge Proofs", Privacy-Enhancing Cryptography project page, on the distinction between a zero-knowledge proof and a zero-knowledge proof of knowledge.
2. Serge Vaudenay, "Security Flaws Induced by CBC Padding: Applications to SSL, IPSEC, WTLS...", EUROCRYPT 2002, LNCS 2332, pp. 534-545.
3. Nadhem J. AlFardan and Kenneth G. Paterson, "Lucky Thirteen: Breaking the TLS and DTLS Record Protocols", IEEE Symposium on Security and Privacy 2013.
4. Bodo Möller, Thai Duong and Krzysztof Kotowicz, "This POODLE Bites: Exploiting the SSL 3.0 Fallback", Google Online Security Blog, October 2014.
5. Thomas Pornin, "Why Constant-Time Crypto?", BearSSL.
6. GNU Project, "Warning Options", GCC documentation, on -Wundef and undefined identifiers in #if being replaced with zero.
7. Ralph C. Merkle and Martin E. Hellman, "On the Security of Multiple Encryption", Communications of the ACM 24(7), pp. 465-467, July 1981.
8. Ran Canetti, Oded Goldreich and Shai Halevi, "The Random Oracle Methodology, Revisited", STOC 1998.
9. IETF, "RFC 9325: Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", November 2022.
10. IETF, "RFC 10024: Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3", August 2026.
11. ICANN, "The Key to the Internet and Key Ceremonies: An Explainer", 11 July 2023.
12. IANA, "Trusted Community Representative Criteria".
13. NIST, "What Is Post-Quantum Cryptography?".
14. NIST, "Quantum Computers May Put Internet Traffic at Risk", Taking Measure, July 2026, on the current state of quantum hardware.
15. University of Waterloo Institute for Quantum Computing, "Workshop tackles challenges of protecting businesses and governments from a quantum threat", 2016. Cited for the term "Y2Q, years to quantum"; its contemporaneous ten-year estimate is not a current forecast.
16. Michele Mosca, "Cybersecurity in an era with quantum computers: will we be ready?", IACR ePrint 2015/1075.