Don’t Roll Your Own Crypto

Bugs in the crypto can have a huge impact

Writing cryptography software isn’t like writing regular software. When writing regular software, little bugs tend to have little impacts. If you have an off-by-one bug, you could expect a small bug, for example, omitting one result on a search page. If you forget to check for null references, maybe a program crashes. But with cryptography, a small mistake may leave you with a system that encrypts and decrypts correctly for well-intentioned inputs but fails entirely when faced with malicious input.

The developer needs to either rediscover the entire field from scratch or subject the code to the scrutiny of others with a deep understanding of the field. Just as you can’t tickle yourself, you can’t find the mistakes you’ve made that involve flaws you haven’t learned about yet. Bruce Schneier has a nice essay on Schneier’s Law that expands on this.

Attack models

There are many different attack models to consider. A common, though misguided, mental model of a secure cryptosystem is one where the attacker gets to see a single message of modest length. If the attacker can decrypt it, then the system is insecure; otherwise, it’s suitable for any and all purposes. That certainly is an attack that a cryptosystem should be able to defend against. But there are many other models to consider, such as the following:

• An attacker who can listen to many encrypted messages between two parties
• An attacker who can replay previously transmitted encrypted messages
• An attacker who can replay modified variants of previously transmitted encrypted messages
• An attacker who can replay modified variants of previously transmitted encrypted messages to a recipient who’s expecting only well-behaved communication and who therefore displays helpful error messages if anything goes wrong during decryption
• An attacker who can listen to the encrypted communication between two parties where some of the plaintexts are known to the attacker
• An attacker who can influence the contents of encrypted communication between two other parties

Defenses that protect against more limited adversaries may fail against more advanced adversaries.

Issues with rolling your own crypto

It’s easy to see all of the security breaches in the news and decide to protect ourselves by building a new kind of encryption. That’s a laudable goal, but it’s misguided. Without a deep understanding of how systems have been compromised, it’s unlikely that someone would be able to design a safer system from first principles. Better to reign in that desire to build a new cryptosystem until you have broken a couple yourself. If you haven’t broken anything yet, you are likely to just repeat other people’s mistakes from the past. As the saying goes,

Those who do not learn history are destined to have George Santayana quoted at them.

                                                 Q U I Z