5 Famous Cryptography Quotes, Explained
You can become a better developer if you understand these security principles
Cryptography is the science of secrets. In the distant past, it was simply about scrambling messages so adversaries couldn’t read them. In the modern computing era (a span of time that stretches less than 50 years), cryptography has become a keystone of computer security, encompassing all the ways we hide data, verify identities, communicate privately, and prevent message tampering.
Something else has changed, too. Today, every developer needs a solid grasp of security and cryptography basics. The stakes are simply too high to ignore them. You can’t reverse an exploit that’s already happened. And you can’t bolt security onto a system after the fact, no matter how many highly paid consultants you’re willing to hire.
To help you brush up on your security smarts, I’ve compiled a few of my favorite bits of cryptography wisdom. Many of them are a decade or two old. But their advice stands the test of time.
1. On secrets
“Every secret creates a potential failure point.” — Bruce Schneier
One of the most dangerous security mistakes a programmer can make (other than rolling their own crypto) is trusting that the things that are secret during development can stay secret forever.
Imagine you write an algorithm to verify promotional codes. As soon as someone discovers its rules of logic — by research, reverse engineering, trial-and-error, or just asking questions — it ceases to be a reliable test for finding fakes. No secret lasts forever, and every secret is just one exploit away from being compromised.
This concept can seem confusing at first, because computer security does rely on secret ingredients like passwords and keys. But if you look more carefully, you’ll find that these are the exact weak points of a system, to be minimized, managed, or avoided wherever possible. Passwords are a notorious failure point — all it takes is one email spoofing attack or improperly discarded hard drive to pinch one. (Biometric data, which isn’t secret but isn’t easy to acquire, is far more secure.)
Above all else, do not rely on secrecy in the implementation details of your system. Passwords can be changed after an attack. But there’s no practical way to build a new system once its inner workings are discovered. Not only is there no lasting security through obscurity, but when obscurity fails, it fails big.
Cryptography nerds may recognize that “Every secret creates a potential failure point” is actually a generalization of Kerckhoffs’s law, a famous rule of the 19th century cryptographer.
“A cryptographic system should be secure even if everything about the system, except the key, is public knowledge.” — Auguste Kerckhoffs
This applies the same philosophy (there is no security through obscurity) to the cryptographic algorithms we use. Time and time again, it’s been shown that the most reliable encryption comes from heavily explored public algorithms. The least reliable encryption is from secret algorithms that haven’t been tested by the broader community and are almost certainly full of undiscovered vulnerabilities.
2. On system integrity
“Cryptography is typically bypassed, not penetrated.” — Adi Shamir
Most cryptography is never broken, and most attacks don’t even try. Instead, cryptography is like a dead-bolted door on a house — once it establishes a moderately high threshold of protection, it simply moves an attack elsewhere (say, to a side window or a neighbor with a spare key).
There are many ways to attack a system. Relying on known flaws in hardware or unpatched software is common. But without doubt, the weakest links in every security system are the human ones.
“Cryptography without system integrity is like investing in an armored car to carry money between a customer living in a cardboard box and a person doing business on a park bench.” — Gene Spafford
Good programmers already know that if they want to optimize the performance of their code, they need to focus on the bottlenecks. Improvements in other places won’t yield results. The same is true of security systems. You need to improve the weakest areas, and if there’s a backdoor that can evade your security measures, it doesn’t matter how fantastic your cryptographic algorithms are.
3. On randomness
“Anyone who attempts to generate random numbers by deterministic means is, of course, living in a state of sin.” — John von Neumann
As you already know, ordinary attackers rarely bother to attack the cryptography of a system. But there are exceptions. The most common cases are when the value of the encrypted data is very high—for example, it’s protecting trade secrets or the ownership of a block of cryptocurrency.
When hackers attack cryptography, they would like to attack the implementation — particularly, the way the cryptography is integrated into the rest of the system. Often, there are gaps or outright sloppiness, information leaking out of overly detailed error messages, defective hardware, or buggy software. But if that doesn’t work, another common way to break encryption is by exploiting poor randomness. It sounds like an edge case, but it’s actually a common tactic behind plenty of legendary exploits, including attacks on slot machines, lotteries, internet games, bitcoin wallets, and the digital signing system used by the PlayStation 3.
The problem is well known — computers create random-seeming numbers using algorithms, and if you know the inputs to these algorithms you can regenerate the same “random” numbers. What’s less obvious is that you can choose random-seeming inputs, and still be wide open to attacks.
For example, if you seed a basic ordinary random number generator using the current millisecond of the computer clock, you’ve narrowed down the possible random values enough that they can easily be guessed. Even using multiple inputs with one guessable value compromises the whole system, opening the door to relatively easy brute force attacks. And if you can figure out the random numbers that someone else has used, you’re well on your way to decrypting the messages they’ve sent, or even figuring out the private key that they used.
“Random numbers should not be generated with a method chosen at random.” — Donald Knuth
Humans confuse themselves about randomness all the time, because the way we use it in casual conversation (to mean something arbitrary) is different from the way we use it in solid cryptographic programming (to mean something non-deterministic). Here, computer pioneer Donald Knuth plays with this double-meaning.
4. On programmers and the urge to tinker
“Crypto is like catnip for programmers. It’s hard to keep us away from it, because it’s challenging and fun to play with. And programmers respond very badly to the insinuation that they’re not clever enough to do something.”—Maciej Cegłowski
Even before the creation of bitcoin, crypto was cool. Once we learn about cryptographic algorithms, we want to play with them. Often, we misjudge the risk. A developer that ignores security is a dangerous person to have around. But a smart developer that thinks they understand cryptography is the most dangerous company of all.
Incidentally, Maciej Cegłowski also offers the perfect solution for programmers who are curious about crypto — spend at least a little time learning to break encryption. Once you realize how tiny details (improperly sized buffers, reused nonces, careless string manipulation) open up massive, well known security gaps, you’ll think twice about blazing a new trail. To get a grasp on the scope of the problem, work through some of the Matasano Crypto Challenges. As Cegłowski explains, it’s a good way to “shake your sillies out” and make sure you never dare to pilot the cryptographic F-16 on your own.
“Anyone can create an algorithm they can’t break.” — Bruce Schneier
Often described as Schneier’s law, it’s a stark reminder not to be overconfident or use custom cryptographic solutions, even if you’re a better-than-average cryptographer. Programmers are problem solvers, and for us it’s easy to think of dozens of clever cryptography tricks. With cryptographic training, it’s trivial to defeat them all.
5. On the misplaced faith in cryptography
“All the magic crypto fairy dust in the world won’t make you secure.”— Gary McGraw
The math, science, and computing power that goes into modern day encryption is dazzling. It’s hard not be impressed by shiny things like quantum cryptography.
But there is one time that high-grade cryptography can be dangerous to the people using it. That’s when it gives them a false sense of security, and an excuse to ignore more likely attack vectors. The advice is obvious — but often overlooked.
“If you think cryptography will solve your problem, either you don’t understand cryptography, or you don’t understand your problem.” — Peter G. Neumann
It’s sometimes said that cryptography doesn’t fix problems, it changes them. You start with a data privacy problem, and cryptography replaces it with a key management problem. This quote from Peter G. Neumann has been repeated in slightly different versions by nearly a dozen famous cryptography researchers. The bottom line stays the same. Proper security is not tied up with any one technology. Instead, it’s a process that encompasses the design of an entire system.