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.'"

Comments

Snake Oil

[Anonymous Coward]

Snake oil is a traditional Chinese medicine used for joint pain. However, the most common usage of the words is as a derogatory term for medicines to imply that they are fake, fraudulent, and usually ineffective. The expression is also applied metaphorically to any product with exaggerated marketing but questionable or unverifiable quality.

'nuff said

Re:Still not too bad

[TCM]

I'm not so sure. Once a flawed implementation has been broken, there will be tools to crack it.

Take WEP for example. I personally wouldn't know how to crack it. But others do. They develop tools. Et voila, today it's trivial to download some tool and break WEP, even for novices.

Weak encryption is never good and should be strongly discouraged.

Then use OSS!!

[JimBowen]

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.

Re:Still not too bad

[Panaflex]

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.

Re:Still not too bad

[Snarfangel]

I'm not so sure. Once a flawed implementation has been broken, there will be tools to crack it.

Plus, if there is *no* encryption, people are less likely to put sensitive information in the application.

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?

Snake oil that uses AES

[Paul Crowley]

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.

Re:Still not too bad

[Lord Ender]

I would say that there is an inverse relation (at least somewhat) between price of crypto software and real security.

The cheaper the software is, the greater the number of people who could have peer-reviewed it for correctness. The more open the software, likewise.

Really expensive software could only have been peer-reviewed by a small number of people, while free, open source software could have been reviewed by a huge number of people.

I recently was asked to recommend a way for my CEO and several other executives to securie thier IMs. I recommended gaim + gaim-encryption because it was all open source and free, so if there were a flaw in the crypto implementation, it would likely have been discovered already.

I also made sure the CEO knew that he was using open source software, and I told him why. He was totally down with it :-)

No, it's much harder than you think.

[Paul Crowley]

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?

How is this different from any other product?

[njdj]

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.

Can you distinguish, by inspection, between a reliable automobile and a piece of junk that will barely last 2 years? I certainly can't. So I rely on reviews by people I trust when I buy a new car.

In the field of cryptography there are several people who have written peer-reviewed books about cryptography, are trusted in the community, and who occasionally review products. Bruce Schneier is one (there are others, use Google, this is not mean to be a puff for Schneier or his company).

There are also open-source cryptographic programs, which are peer-reviewed and definitely not snake-oil.

or

[xmodem_and_rommon]

or you could just take the common sense approach and use products that rely on algorithms that are open, widely tested and reviewed, and known secure. Algorithms like Blowfish, AES, etc. I use Apple's built-in Filevault protection to encrypt my Powerbook's hard disk, in the event that it is ever stolen. It uses AES-128, which means I know that no-one is getting in without my password.

Any vendor that relies on a custom algorithm for their encryption technology shouldn't be trusted.

Re:or

[TCM]

Any vendor that relies on a custom algorithm for their encryption technology shouldn't be trusted.

Of course.

But even then there are vendors who claim to be using AES and end up introducing implementational flaws that are not obvious to the user. It's not just algorithms that need to be reviewed but complete implementations.

Nice read: http://www.schneier.com/crypto-gram-9902.html#snak eoil

Don't use weak ROT-13

[CrazyJim1]

Get creative, use Rot-14 or something.

Some insights about the article

[owlstead]

It's pretty well known that there are many snake oil products that deploy cryptography. Bruce Sneier frequently displays snake-oil cryptography products in his newsletter, for instance. And these are just the really obvious ones.

Some time ago, I tried to evaluate if a Enterprise Service Bus (intercomponent communication) was fit enough to be put into a production environment. It said that it had AES encryption build in. When I looked at the manual, it displayed a pop up window where you could choose the key-size. It listed exactly all key sizes that were *not* possible for AES. This was a very short evaluation, I can tell you. This also shows a very important thing about cryptography: the algorithms used say very little about the security of an application.

Generally, the manual for cryptographic services is easy to find. This is simply because cryptography is added at the end of the development lifecycle. This is logical because cryptography is not part of the main functionality of most applications (e.g. mime encryption in email products). It's something that was added after the products main functionality was finished. So just look at the last paragraph, or Appendix Z and you are looking at it.

Sometimes it is easy to see why so many products contain bad cryptography. Take XML signatures for instance. XML signatures themselves contain *references* to the data that is signed and the cryptographic techniques used. If you are to verify an XML digital signature, you *must* check if these are not altered. Furthermore, you must keep the XML schema-definitions on your own disk, and not retrieve them from the internet. Nevertheless, I've not seen any API-documentation even mentioning this rather obvious cryptographic insight. You can rest assured that there will be many implementations that will get this wrong.

Cryptography is hard.

The real insight of this story is the listing of the products into "credence goods". If you can call this new insight. Otherwise, it's just stating the well known/obvious.

Re:Crypto is scary stuff

[Realistic_Dragon]

sci.crypt is a good read if you are interested in Crypto. However it does tend to get a bit antagonistic towards newbies - and it's not hard to see why.

Approximatly every 12.5 minutes someone turns up claiming to have invented a new:

Random number generator
Unbreakable encryption method
Implimentation of old methods that makes them unbreakable
Proof that shows that all crypto is worthless

The percentage of loons is *so* high that anyone who does have an interesting idea (and who doesn't publish in reputable journals) is dismissed out of hand.

For example, here is a typical conversation from the one sane new poster (posted somewhere between the 999,999 people trying to sell "200000 bit quantum crypto based on the randomness of STARS!!!!!"):

<i>** Hi, I'd like to find out if there's a RNG sandbox somewhere so I can play about with some ideas.</i>

<i>* ARGH! Dont impliment your own RNG! It'll be crap! Here, use product X.</i>

Well, yes, that's true. When it comes to crypto there is a 99% chance that what you impliment will not work properly and as a result will be insecure... but stoping on someone who wants to try some ideas out is just plain wrong. All research doesnt have to take place in academic institutions.

Truecrypt

[urikkiru]

This is something I've often considered about commercial encryption software. There's just no way to be sure of their validity, as they are closed source implementations. Open source solutions like Truecrypthttp://truecrypt.sourceforge.net/ are at least somewhat more trustworthy, in that they can be openly reviewed by anyone. Despite the fact that I know jack all about the specific math behind AES and such, at least I can read some simple explanations of the concepts, read the source, and decide if I want to trust my data to it. Honestly, unless we get down to the fraction of the population that actually does understand these bits at a deep level, that's the best any of us can do really.

Sure, large clusters of powerful servers working in tandem(or quantum computing) may render the factoral math behind crypto obsolete. A nice thing though, is that those kind of solutions are limited to those that can afford them. Still, even if it's all true, and I'm wasting my time encrypting things, what better solutions do we have?

You'd have thought so...

[jd]

But I've worked as a contractor for Government sites where their central data server was:

• Publicly accessible, outside of any firewall
• Had .rhosts on it, for the specific purpose of avoiding having to write login code for scripts that copy data
• Stored commercially sensitive (and possibly classified) information.

Ok, I'll be fair - though God alone knows why, and I think even God gave up trying to figure out the tangled mess I call a brain some time ago. They did use DES - not triple DES, just plain DES - for the really really sensitive stuff. The encryption key was visible to anyone logged in on any account, however, as the DES they used required the key to be the first parameter and they made no effort to erase it. So it was technically encrypted. (Once the passkey has been broadcast to all and sundry, I do not regard the encryption as anything more than a technicality, and in the case of DES, I seriously doubt you could even claim that.)

I've heard that security has since improved. I say "heard", because it was some time AFTER security was said to have been improved that reports started coming out of a fileswapper using NASA storage machines as extra disk space - the very same organization and very same type of mass storage device I had serious doubts about many years prior to that.

But that's a Government institution! Yes, and they're the ones with a great many experts in such matters and a great many contracts with people who can not merely withdraw business but also guarantee a disaster in the next election. The bulk of private corporations out there have neither the skills to draw on OR the incentives to maintain some sort of standard. All they have to do is ROT13 and tell you it's got digital security. Enough suckers'll buy into it to keep the CEO in champaign, caviar and girls of commercially-negotiable virtue for life.

The problem is, there is no mandated minimum standard for security, so those who can WILL use the lowest standard possible that will deceive customers into thinking they're safe whilst staying a gnat's whisker (after being compressed by the forces of a neutron star) beyond what could be sued for in courts, assuming a technically ignorant judge.

IMHO, "snake oil" could be vastly reduced - not eliminated but reduced - by placing minimum standards for crypto, compression and other easily-manipulated areas of technology, and enforcing them. Not maximum - that's what the intelligence services want, and they want it to be zero. I'm strictly talking minimum. Your good, old-fashioned lemon law - does it fill the purpose for which it was sold to the customer? Yes or no.

In the case of cryptography, that would be rephrased as follows: would a reasonable person, aware of the strengths and deficits of the technique concerned, aware of any warnings published on the block crypto lounge, hashing function lounge, etc, aware of the Usenet Crypto FAQ (ie: aware of the "common knowledge" that exists on cryptography), and aware of the grade of security the user is demonstrably expecting, agree or disagree that the cryptographic system sold meets the grade expected or not?

If it does not, it is a lemon for the purpose for which it was sold. It might be perfectly good otherwise, but it doesn't, can't, and never will do what was expected of it.

This would be enforceable, as I said very clearly that I'm talking about weighing the "common knowledge" against the "personal expectation". Both are easy to define and even a non-expert should understand a skull-and-crossbones labelled "BROKEN, DO NOT USE" in a crypto lounge. They might not understand the fine nit-picking or the advanced maths, but that's why I'm sticking solely to what is commonly known and understood, not what is derivable from axiom 327 as applies to lemma 291 as described by Professor Branestawm's obscure paper entitled "techniques for splicing dormice genes into giraffe brai