Slashdot Mirror
Crypto Snake Oil
An anonymous reader writes "Luther Martin of Voltage Security has published an article about the perception of cryptography today with regards to quality and honesty in vendors. From the article: 'Products that implement cryptography are probably credence goods. It requires expensive and uncommon skills to verify that data is really being protected by the use of cryptography, and most people cannot easily distinguish between very weak and very strong cryptography. Even after you use cryptography, you are never quite sure that it is protecting you like it is supposed to do.'"
If you are worried about the honesty of vendors, this is exactly why you should be using free cryptography software in the first place, because you know that is going to be strong, and trustworthy, because otherwise someone would have changed it by now. :)
It is also much easier to verify strength by reading the source rather than by reading the binary or by cryptanalysis.
WEP is still a great example... it's enough of a pain that if given the choice between breaking a WEP connection and using an open WAP - well, you'll choose the open one.
In that case, WEP really does work for most people.
I said no... but I missed and it came out yes.
Many Slashdot readers are savvy enough to know that when a software product advertises itself as using, say, secret encryption algorithms with 10,000 bit keys, it's probably snake oil. But I'm seeing increasing amounts of snake oil that uses the Advanced Encryption Standard, AES, and it can be just as weak.
AES itself of course is nigh-on as trustworthy a cryptographic primitive of its kind that we have. But just because you've used the right primitive, doesn't mean you've built a secure product. You have to consider what chaining mode to use, how to handle passphrases if they exist, how to keep your secrets secret, defense against side channel attacks, and more.
What I look for is a product that provides enough information that I can actually assess its security - what attacks they've considered and how they've built the product to defend against them. What I see disturbingly often is a bald declaration that the product is secure, because it uses AES.
Xenu loves you!
>> It requires expensive and uncommon skills to verify that data is really being protected by the use of cryptography
No. It requires reading a couple of good, inexpensive books and understanding of what the heck you're doing. Math behind the whole thing can be complicated. But you don't really need to understand the math 100% here. All you need to know is whether an algorithm is considered "strong" by today's standards, understand a few key concepts, guard your keys, and aproach security related coding with a healthy amount of paranoia.
In other words, a decent developer can get a pretty good understanding of this all in two weeks or less. And these skills need to become "common" already.
If you believe that, no wonder so much insecure stuff is being written. I have been called upon to review code written by developers with your level of knowledge in crypto. They do things like use RSA without proper padding, or use predictable IVs in CBC mode, or fail to properly authenticate the message. They also add totally unnecessary complexity to the system in the mistaken belief that their improvements make it more secure. I shudder when I see a copy of "Applied Cryptography" on the shelves because it is just enough knowledge to be dangerous.
Even the experts make errors in cryptographic protocol design and implementation - I've been doing this for ten years and I've made at least one howler myself. Why do you think, contrary to the advice of pretty much everyone who really knows their stuff, that people with a couple of week's worth of knowledge can get this stuff right?
Xenu loves you!
Like a religion?!
May the Maths Be with you!
Well, I think the facts(haha - ahem - as far as is publically known) are this:
I've heard from a claimed friend of one of the inventors of RSA that [it was cracked years ago].
1. RSA is not known to be cracked and in general is still considered HARD - though the rapidly increasing amount of free and cheap CPU time will eventually defeat most of today's common length keys in 35-50 years (who knows?). That said, it may be possible that RSA gets cracked next week - I wouldn't be surprised. I too have a few friends that studied with RSA founders and ashamedly, they have not let me in on the secret crack yet, either. (Need more beer)
[Friend who does factoring moves to Numerics]
That could be anything - really - from "professional jealousy", "national secret", or "I didn't get the right vibe."
Quantum computers
Ahh, shake and bake computing at it's finest. Unortunatly, qubits are pesky little critters that tend to get bored and entangled in relationships during the course of research. Some qubits have been known to file their own myspace profile and entangle with Japanese qubits! Oh, the little horrors!
Seriously though - you don't have to make wild guesses and claims here. When somone really does crack RSA it will be widely known. The only scary stuff with crypto is wild claims and dishonesty.
I said no... but I missed and it came out yes.
Boy, you don't know that much about cryptography, do you ;)
Blasphemy #1: I've heard from a claimed friend of one of the inventors of RSA that it was cracked it years ago. Yet, it continues to get worldwide use. Sure my friend was probably full of it... but who am I suppose to trust here? The government?
That's complete BS. It hasn't been cracked, and it wont be for a long time. Just remember to use big keys and your stuff is safe. As for who you are supposed to trust, you're supposed to trust the huge mathematical community that every day is pounding and pounding and pounding on this problem. They are honest academics, and if there is even a hint of progress it will become public.
Blasphemy #2: One of my close friend's mother had to switch fields from Numerics after she published some papers considered too sensitive. It had something to do with factoring.
I'm not entirely sure what the hell you are saying. Are you saying that your friends mother is a genius mathematician who published a few papers about factoring and was somehow forced to leave the field? That's completely ridiculous, lots of people publish papers on factoring every year. Either you are lying or you have completly misunderstood the matter.
Blasphemy #3: Anybody else notice that quantum computers have been proven to be capable of factoring really well, but no one has shown that they can solve any NP-hard algorithms? Come on... factoring isn't NP hard.
This is a common misconception, that quantum computers will be like a regular computer, "but way faster". This is not so, a quantum computer works in a fundamentally different way, a way that makes it possible to invent algorithms that are way faster than anything on a classical computer. Many of these new algorithms are made for cryptanalysis, namely Shor's algorithm (integer factorization in polynomial time, breaks RSA), the discrete logarithm algorithm (breaks Diffie-Hellman) and Grovers algorithm (would speed up standard brute forcing cracking, but only a quadratic amount which means that you can just double your key length, and it's still as hard).
As for complexity, the decision-problem form of integer factorization ("Is there a factor of M smaller than N?") is indeed in NP, but the specific class is an unresolved problem. Most people doubt that it is in either P or NP-Complete which would most certainly make it NP-hard (unless P=NP ofcourse, but that's a whole 'nother discussion ;) Maybe you are thinking of primality testing, which has very recently been proven to be in P. The whole village rejoiced.
Then, there's just some silly stuff I've noticed about crypto. Why do we always seem to use encryption just a generation or so ahead of what is needed to crack it? SHA-1 for example...
Has been a problem in the past, but we've learned our lesson. 256 bit AES will (very possibly) never be cracked by an ordinary computer. A quantum computer might, but it would have to be one bad-ass quantum computer. 256 bit AES is completely safe.
And, why do we encrypt one small block at a time. Each encrypted file usually gives many independent chances to crack the key, and in many cases, some of those blocks have known data.
It doesn't matter one iota whether a block has known data or not. You still need the key to have any idea what is in there or not (that is, imagine you suspect a block of data Y has encrypted X, there is no way you can prove that if you don't have the key). There is something called chosen plaintext attack which you can do a similar thing in public key cryptography, but it is only works in bad implementations of it.
Also, public key is great, but secret key can be easily shown NP-hard to crack (in terms of secret key length) with semi-reasonable assumptions, while public key has no such simple proof. I personally have been trying to prove that no public key system can be NP-hard, but what the heck... I'm not that good. Howe
Unfortunately this is a flawed approach. A million people may have read it, but if none of them were cryptographers than it was no better than if nobody had read it. What's really important is _who_ has read the code, not how many.
Ok, lets say you're strolling around and looking to hook some free internet connection, eh?
In the amount of time it takes to walk to the nearest open WAP, you probably couldn't grab enough packets to break WEP.
But if your intentions are, ohh I don't know.. say DARKER. Then yes, WEP is not going to protect the target of your GRISLY, ABYSMAL ABOMINATION of h4x0ring.
I leave my WAP open.. because it reminds me that no communication is secure unless I MAKE it secure. I don't rely on the router or anything else to protect me - only well tested protocols and applications.
I said no... but I missed and it came out yes.
No comment.
To use an analogy, consider two locker rooms. Room A does not have locks on any of the lockers. Room B has locks, but all of them have the same combination. In which one is a person more likely to leave their wallet?
I take it you're implying the correct answer would then be "Neither". And I'd agree.
Problem is, it's not a relevant point. The context here is consumer's ignorance on the performance of crypto products. If someone is buying a crypto product, they must have determined that they need one. Or to continue your analogy: They have already decided that they're going to leave their wallet in a locker. The problem is that they can't tell the difference between a locker room where all the locks have the same combination, and the safer locker room where they don't.
And given that assumption (that they're going to put their wallet in a locker anyway), the poster who claimed that weak encryption is still better than none is right: If you're going to put your wallet in a locker, it's better to put it in one with a bad lock than none at all.
Continuing the analogy: With no lock, any casual bypasser with no particular knowledge at all can easily and quickly check the lockers for any valuables. "Opportunity makes the thief" as they say. Whereas if you at least had a bad lock, finding your wallet would at least require some knowledge of locks. It would also impede the person searching the lockers, which increases the likelyhood of them being discovered before they find your wallet. All in all, a safer situation.
Now obviously, a good and proper lock is better than a bad one. The problem here is that the consumer can't tell the difference when making the choice between the good and bad ones.
But the option of "don't store valuables in it" simply isn't on the table: They've already determined that they're going to store valuables in it, because that's why they wanted a lock in the first place.
They're only independent if you use ECB, and anyone using ECB deserves what they get. Cipher modes like CBC or CTR solve these problems.
One of the major perils facing a would-be crypto user is himself. Many people think they know it all (as evidenced in many of the posts to this article) and therefore can dictate insecure and plain silly design choices when deploying a secure solution in a non-trivial environment (for anything: authentication, the crypto itself, access enforcement, etc.).
For the vendor this creates a conflict. On the one hand, you want to satisfy the customer's request. On the other hand, you know your customer is shooting himself in the foot and very possibly becoming a vendor reputation problem later on down the line.
In my experience, most customers are accustomed to being "always right" and fail to recognize that crypto/security may be one of those things that they simply do not know enough about and to let the vendor help them. It is often the case that the vendor can explain/evangelize and detail the very attack the customer is opening himself up to with little or no effect - the customer is convinced they know it all.
Room A.
And I'll bring my own lock.
If a million people read the code, and 1 in 10,000 were cryptographers who examined the code closely, that's still 100 cryptographers examining the code. Assuming most of them were working independently or in small groups, that's good enough for me. It's probably a lot better than a closed-source solution where maybe half a dozen experts looked closely at the code.
The best thing about open-source is that if it's a real concern to you, you can hire your own experts to check out the implimentation. You don't have to take the vendor's or anyone else's word for it.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Do you care about the security of your wireless mouse?