5 related insights
Use this topic page to move quickly through the most relevant Attomus thinking without losing the wider context across the full insights section.
Insights Topic
Cryptography
Browse Attomus insight related to cryptography, with a focus on programme delivery, operational judgement, and professional execution in demanding environments.
Metadata: The Half of Privacy That Encryption Doesn't Cover
Michael Hayden – the only person to have run both the NSA and the CIA – told a 2014 debate at Johns Hopkins, “We kill people based on metadata.” The line was not a boast about breaking encryption. It was the opposite point: for a great many purposes, nobody needs to. The earlier posts in this series looked at what encryption guarantees, and at who holds the keys. This one concerns everything those guarantees leave exposed: the data about the data. Who communicated with whom. When, how often, in what bursts, from which locations, on which devices, in messages of what size. Content encryption – even flawless, end-to-end, key-custody-correct encryption – conceals none of it.
Read articleWhy We Chose a 28-Byte Backup Header
The backup format for an authenticator app looks like a solved problem. Encrypt the secrets with a passphrase, write the ciphertext to a file, done. It is not done. The naive version fails silently in several distinct ways, and the worst of them leaves a user holding a file that will never decrypt again, reporting an error that blames their passphrase for something else entirely. The 28-byte header we settled on came out of working through those failures one at a time. The same reasoning applies to any format that combines key derivation with authenticated encryption.
Read articleHardware Roots of Trust: What 'Hardware-Backed' Actually Means
“Hardware-backed” is among the most widely used and least interrogated phrases in security. At its best it names a specific and valuable protection: a small, deliberately limited piece of hardware that holds cryptographic keys and will not surrender them, even to software that has otherwise taken over the machine. At its worst it is an adjective applied to make a product sound safer than it is. The distance between those two is the subject of this piece.
Read articleZero-Knowledge Proofs: Proving Without Revealing, Separating Substance From Theatre
A zero-knowledge proof lets one party prove to another that a statement is true whilst revealing nothing beyond the truth of the statement itself: not the evidence, not the underlying data, not the working, only the fact. It sounds like a conjuring trick, and most people, hearing it described, assume it cannot be done. It can. The technique is not new. It was set out in a 1985 paper by Goldwasser, Micali and Rackoff; two of the three, Goldwasser and Micali, went on to receive the Turing Award, in 2012, for a body of work in cryptography of which this was a part. What has changed recently is practicality. Proofs that once demanded impractical amounts of computation can now be generated quickly enough for production systems, and the phrase has duly made its way from the journals onto the product brochures. That journey has not been kind to precision. What follows sets out what the technique actually offers, where it is earning its keep, and how to spot the cases where the phrase is carrying more weight than the mathematics.
Read articlePost-Quantum Cryptography: A Migration Guide for People Who Dislike Panic
The short answer first: the quantum threat to public-key cryptography is real, it is not imminent, and almost everything needed to deal with it in an orderly fashion already exists. That combination is rare in security. One audience is told the sky is falling and sold “quantum-safe” products of uneven seriousness; another decides the whole business is decades away and files it under someone else’s problem. Both are wrong, and the material needed to see why is all in the public record.
Read article