Security-vendor snake oil: 7 promises that don't deliver

Beware bold promises from a multibillion-dollar industry that can't prevent your IT systems from being routinely hacked

Page 2 of 5

Good crypto is hard to make; even the best in the world don't have the guts (or sanity) to claim theirs can't be broken. In fact, you'll be lucky to get them to concede that their encryption is anything but "nontrivial" to compromise. I trust the encryption expert who doesn't trust himself. Anything else means trusting a snake-oil salesman trying to sell you flawed crypto.

Case in point: A few years ago a vendor came on the scene claiming he had unbreakable crypto. What made his encryption so incredible was that he used a huge key and distributed part (or parts) of the secret key in the cloud. Because the key was never in one place, it would be impossible to compromise. And the encryption algorithm and routine was secure because it was a secret, too.

Most knowledgeable security pros recognize that a good cipher should always have a known encryption algorithm that stands up to public review. Not this vendor.

But the best (and most hilarious) part was the vendor's claim that his superior cipher was backed by a million-bit key. Never mind that strong encryption today is backed by key sizes of 256-bit (symmetric) or 2,048-bit (asymmetric). This company was promising an encryption key that was orders of magnitude bigger.

Cryptologists chuckled at this for two reasons. First, when you have a good encryption routine, the involved key size can be small because no one can brute-force all the possible permutations of even relatively small encryption keys -- think, more than the "number of atoms in the known universe" type of stuff. Instead, to break ciphers today, cryptologists find flaws in the cipher's mathematics, which allow them to rule out very large parts of the populations of possible keys. In a nutshell, found cryptographic weaknesses allow attackers to develop shortcuts to faster guessing of the valid possible keys.

All things being equal, a proven cipher with a smaller key size is considered more secure. A prime example is ECC (elliptic curve cryptography) versus RSA. Today, an RSA-protected key must be 2,048 bits or larger to be considered relatively secure. With ECC, 384 bits is considered sufficient. RSA (the original algorithm) is probably nearing the end of its usefulness, and ECC is just starting to become a primary player.

So saying you have a million-bit key is akin to saying your invented cipher is so sucky it takes a million bits of obscurity (versus 384 bits) to keep the protected data secure. Five thousand bits would be overkill from any good cipher, because no one is known to be able to come close to breaking even 3,000-bit keys from a really good cipher. When you make a million-bit key, you're absolutely saying you don't trust your cipher to be good at smaller key sizes. This paradox is perhaps only understood by cipher enthusiasts, but, believe me, you'd slay the audience at any crypto convention by repeating this story.

Second, if you were required to use a million-bit key, that means you would somehow have to communicate that huge mother from sender to receiver, making that communication at least a megabyte. Suppose you encrypted an email containing a single character. The resulting encrypted blob would be 1MB. That's pretty wasteful.

A "secret" million-bit cipher being split among the cloud was enough to do that crypto in. No one took it seriously, and at least one impressive encryption expert, Bruce Schneier, publicly mocked it.

The worst part was that the vendor claimed to have proof that it sold $5 million of its crypto to the military. I hope the vendor was lying; otherwise, the military purchaser has a lot of explaining to do.

Security snake oil No. 3: 100 percent accurate antivirus software

Also akin to the claim of unbreakable software is the claim from multiple vendors that their anti-malware detection is 100 percent accurate. And they almost all say this detection rate has been "verified independently in test after test."

| 1 2 3 4 5 Page 2