Blog

# A better way to define cryptographic security

The level of protection that using cryptography actually provides can be confusing to many people. An 80-bit Skipjack key provides the same level of security as a 160-bit elliptic curve key or as a 1,024-bit RSA key, but understanding why this is true requires knowing more math than most people care to learn.

When it comes to quantifying the strength of cryptographic hash functions it gets even worse, because the strength of a hash function is very dependent on how it used. Finding a collision is the easiest attack on hash functions, and is the usual metric that's used to quantify the strength of one. But even if you can find a collision in a hash function, that doesn't mean that you can actually use that collision to defeat a cryptographic protocol. It's almost always more complicated than that.

This means that an accurate answer to exactly how secure something is can be so full of arcane crypto-details that only a specialist can understand it. This also means that the answer is useless to anyone other than specialists, which includes most of the almost 7 billion or so people that are currently alive.

Maybe there's a better way to quantify security that giving it in terms of bits of security. Maybe an arcane government regulation that dates back to 1967, 32 FR 11467, provides an example of a better way to do this.

32 FR 11467 defines the United States Standards for Grades of Green Olives. It's where the olive sizes like Large, Jumbo, Giant, Colossal, Mammoth, etc., are defined. It's also why olives always sound bigger that they are. If you open a can of Large olives, you'll probably be surprised by how small they really are. You need to get Colossal or Mammoth olives to really impress your holiday guests.

But despite the way in which it tricks people into buying a can of Large olives at least once in their life, the olive standard that's defined in 32 FR 11467 has been fairly successful and people seem to understand it better than they understand the way in which cryptographic security is quantified. Because it seems to work so well, why not model a standard for cryptographic security on it?

Instead of using bits of strength to quantify the strength of cryptography, the government could define several security levels that are defined by words instead of numbers. We could have levels like Secure, Very Secure, Highly Secure, Extremely Secure, etc. The level defined by "Secure" would have to be roughly the same as a fairly low level of security, of course, so that we'd be following the model that's worked so well with the United States Standards for Grades of Green Olives.

Some people might be tricked into buying something that is only Secure, but that wouldn't happen too often. People quickly learn that Large olives aren't really very big, and they'd learn quickly that something that's called "Secure" doesn't really provide that much protection against hackers.

I'll have to mention this idea to the people at NIST the next time that I talk to them.

• #### Matt Flynn

Interesting. I guess designations would need to be updated over time. And some organization would need to be the official grader? But, I agree that finding a better way to designate than arcane letters and numbers would be very useful – especially in the consumer space. There are probably still people selling wireless modems with “built-in WEP-40 encryption” at no extra charge.
…now for some reason, I’m craving a martini.

• #### Andrew Yeomans

http://www.keylength.com does a pretty good job comparing crypto algorithms against eight different sets of recommendations. It basically helps you assess what year any given strength of crypto will be broken.
Now that’s only part of the story. In real life, we have software programs which typically take some password or passphrase, mangle it a bit to generate the crypto key, which is then fed into the crypto algorithm.And any of these parts can be done well or badly. And sometimes *very* badly.
I’m trying to collect information on the strength of a complete system, to be able to assign a security level, as you suggest. I’m inclined to use a basic measure of “how much will it cost to break the encryption”, though a “time to break” with different hardware types may correlate fairly well with cost.
I’m not so optimistic to think the scale will start with “Secure”. More likely it will follow nmap’s example of “Trivial joke”, “Easy”, “Medium”, “Formidable”, “Worthy challenge”, and “Good luck!”