Security When the Enemy Knows the System
So if the entire implementation of our cryptosystems is known to the adversary, how can we be secure? The adversary can just run our code after all.
The key is key
The key is key. Encryption algorithms don’t just take plain text as input, they take a key as well. A well-written encryption algorithm will produce wildly different outputs when encrypting a given plaintext with keys that differ only slightly. The key is the only part that needs to be kept secret. Rather than keeping an entire algorithm secret, we just need to keep our key secret.
An encryption algorithm should be so strong that even if an attacker had full access to the source code, the attacker would have no better option than to brute force all possible passwords. We won’t cover how the encryption libraries recommended in this chapter achieve this goal. We’ll merely note that they’ve been found to do so.
If we’ve built a system like this, all the implementer has to do is to pick a suitably large random encryption key. Encryption keys are commonly bits. That means that there are possible values for an encryption key. That’s , or s all multiplied together. is an awfully big number.
How big? Well, it’s even bigger than the number of different ways you can order a standard deck of playing cards. There are about (or followed by zeroes) different ways to order a deck of playing cards. The number is about (or 1 followed by zeroes). So there are about 1.4 billion times more 256-bit encryption keys than there are ways to order a standard deck of playing cards.
Joe asks: What’s so great about a deck of playing cards?
I have to turn your attention to one of the most fun bits of math I’ve ever read. It’s a great way to help visualize just how many different ways you can order a standard deck of playing cards. When you order a deck, there are 52 possibilities for the first card. You pick the first one, and that leaves 51 possibilities for the second card, 50 for the third card, and so on. That makes for different possibilities. The shorthand for this is (pronounced “52 factorial”) and it’s so big, that, well, just read the linked story. It’s fun.
Kerckhoffs’s and Shannon’s advice comes primarily from witnessing firsthand the futility of keeping implementations secret. An additional benefit to building systems where the only secret is the key is that it’s really hard to keep secrets. If a password is compromised, suspected of being compromised, or has just been in use for too long, a secure system should be able to replace it with a new one and recover. (The problem of discovering what, if anything, an adversary did with compromised passwords and recovering from that is outside the scope of this course.)
Consider the relative difficulty of changing out all the passwords in a system versus the difficulty of changing out the entire system itself.
Q U I Z