I've written a short "Snake Oil FAQ" below. It's incomplete and
needs some work (adding a few definitions, rewording, aesthetic
formatting, etc.), so think of it as a 'beta' FAQ (please don't post
it on web pages, though I don't mind if it's distributed among
anyone interested in criticizing or contributing). Comments and
suggestions would be appreciated. Note that the aim is to write
something accessible to 'newbies'. (Jeremy Barrett contributed to
this, BTW)
Snake-Oil Warning Signs
Encryption Software to Avoid
(Revision 0.1)
Introduction
======================================================================
Good cryptography is an excellent and necessary tool for almost
anyone.
However, there are a multitude of choices for what products to use.
Many good cryptographic products are available, both commercial and free. However there are also some extremely bad cryptographic
products (known in the field as "Snake Oil"), which not only fail do
their job of providing security, but are based on, and add to, the many misconceptions and misunderstandings surrounding cryptogra
phy and security.
It is extremely important that users of cryptography actively
question the product they are considering using, to insure the security and integrity of their data-- be it personal or business informat
ion. In order to make a more informed decision, it is necessary to
understand
some of the "red flags" to watch out for, and what they mean.
For a variety of reasons, this document is general in scope and does
not mention specific products or algorithms as being "good" or "Snake Oil".
Some Common Snake-Oil Warning Signs
======================================================================
The following are some of the "red flags" one should watch for when
looking at an encryption product:
Technobabble
------------
The vendor's descrption of the product may contain a lot of
hard-to-follow use of technical terms to describe how the product
works. If this appears to be confusing nonsesense, it may very well
be (even to someone familiar with the terminology). Technobabble is
a
good means of confusing a potential user and masking the fact that
the
vendor doesn't understand anything either.
A sign of technobabble is a descrption which drops a lot of technical
terms for how the system works without actually explaining how it
works.
New Type of Cryptography?
-------------------------
Beware of any vendor who claims to have invented a "new type of
cryptography".
Avoid software which claims to use 'new paradigms' of computing such
as cellular automata, neural nets, genetic algorithms, chaos theory,
etc. Just because software uses to different mehtod of computation
doesn't make it more secure.
Anything that claims to have invented a new public key cryptosystem
without publishing the details or underlying mathematical principles
is highly suspect.
Proprietary Algorithms
----------------------
Avoid software which uses "proprietary" or "secret" algorithms.
Security through obscurity is not considered a safe means of
protecting your data. If the vendor does not feel confident that the
method used can withstand years of scrutiny by the academic
community,
neither should you.
Beware of specially modified versions of well-known algorithms. This
may unintentionally weaken the cipher.
The use of a trusted algorithm, along with technical notes explaining
the implementation (if not availablity of the source code for the
product) are a sign of good faith on the part of the vendor that you
can take apart and test the implementation yourself.
Old Ciphers Never Die...
------------------------
Beware of something that sounds like a sophisticated nineteenth-
century or even World War II scheme, or something based on a
mechanical system.
If the product's authors sound like they are entirely unfamiliar
with the state of the art, that's a good warning sign.
Experienced Security Experts
----------------------------
Beware of any product claiming that "experienced security experts"
have analyzed it, but it won't say who (especially if the scheme has
not been published in a reputable journal).
Unbreakability
--------------
Some vendors will claim their software is "unbreakable". This is
marketing hype, and a common sign of snake-oil. Avoid any vendor that
makes unrealistic claims.
No algorithm is unbreakable. Even the best algorithms are breakable
using "brute force" (trying every possible key), but if the key size
is large enough, this is impractical even with vast amounts of
computing power.
Be wary of marketing gimmicks related to "if you can crack our
software" contests.
One-Time-Pads
-------------
A snake-oil vendor may claim the system uses a one-time-pad (OTP),
which is theoretically unbreakable.
A OTP system is not an algorithm. It involves generating a random
key
at least the size of the message and garbling the message with it.
When the message is decrypted, the key is destroyed. Only one
message
is encrypted with a OTP, and it is used only once. They key is
random: generated using a real random source, such as specialized
hardware, radioctive decay timings, etc., and not from an algorithm
or
cipher. Anything else is not a one-time-pad.
The vendor may confuse random session keys or initialization vectors
with OTPs.
Algorithm or product XXX is insecure
------------------------------------
Avoid anything that makes claims that particular algorithms or
other products are insecure without backing up those claims (or at
least siting references to them).
Avoid anything that misrepresents 'weaknesses' of other algorithms.
(For example, if the product claims it doesn't use public key crypto,
citing timing attacks or factoring as reasons.)
Keys and Passwords
------------------
The "key" and the "password" are often not the same thing. The "key"
generally refers to the actual data used by the cipher algorithm. The "password" refers to the word or phrase the user types in,
which the software converts into the key (usually through a process
called "hashing" or "key initialization").
The reason this is done is because the characters a user is likely to
type in do not cover the full range of possible characters. (Such keys would be more redundant and easier for an attacker to gues
s.) By hashing a key can be made from an arbitrary password that
covers the full range of possible keys. It also allows one to use longer words, or phrases and whole sentences as a "passphrase", wh
ich is more secure.
Anything that restricts users passwords to something like 10 or 16 or
even 32 characters is foolish. If the actual "password" is the cipher's key (rather than hashing it into a key, as explained abo
ve), avoid it.
Anything that claims to solve the "key management problem" is also
be to avoided. (Key management is an inherent problem with crypto.)
Convenience is nice, but be wary of anything that sounds too easy
to use. Avoid anything that lets anyone with your copy of the
software to access files, data, etc. without having to use some sort of key
or passphrase.
Avoid anything that doesn't let you generate your own keys (ie,
the vendor sends you a key in the mail).
Avoid anything by a vendor who does not seem to understand the
difference between public-key cryptography and private-key cryptography.
Lost keys and passwords
-----------------------
If there's a third-party utility that can crack the software, avoid
it. If the vendor claims it can recover lost passwords (without
using a key-backup or escrow feature), avoid it.
Exported from the USA
---------------------
If the software is made in North America, can it be exported? If the
answer is yes, chances are it's not very strong. Strong cryptography
is considered munitions in terms of export from the United States,
and
requires approval from the State Department. Chances are if the
software is exportable, the algorithm is weak or it is crackable (hence it was approved for export).
If the vendor is unaware of export restrictions, avoid the software:
the vendor is not familiar with the state of the art.
Because of export restrictions, some legitimate (not-Snake Oil)
products may have a freely exportable version for outside of the USA, which is different from a separate US/Canada-only distribution.
---
No-frills sig.
Befriend my mail filter by sending a message with the subject "send help"
Key-ID: 5D3F2E99 1996/04/22 wlkngowl@unix.asb.com (root@magneto)
AB1F4831 1993/05/10 Deranged Mutant
-----BEGIN PGP SIGNED MESSAGE----- On Sat, 20 Jul 1996, Deranged Mutant wrote:
Date: Sat, 20 Jul 1996 16:37:40 +0000 From: Deranged Mutant
To: cypherpunks@toad.com Subject: A Snake-Oil FAQ I've written a short "Snake Oil FAQ" below. It's incomplete and needs some work (adding a few definitions, rewording, aesthetic formatting, etc.), so think of it as a 'beta' FAQ (please don't post it on web pages, though I don't mind if it's distributed among anyone interested in criticizing or contributing). Comments and suggestions would be appreciated. Note that the aim is to write something accessible to 'newbies'. (Jeremy Barrett contributed to this, BTW)
Snake-Oil Warning Signs Encryption Software to Avoid
(Revision 0.1)
Looks very nicely done. I think you pretty much covered it... but...
Be wary of marketing gimmicks related to "if you can crack our software" contests.
Even the best cryptographers and security professionals have done this. RSA did it with their Public Key system, which took 20+ years to break. Throughout history, many security mechanisms, even the best ones, including Cyphers, Locks, Firewalls, etc. have been known to go as far as to offer prizes (some extremely high, upwards of a million dollars, some as low as RSA's famous $100 prize) I think that this one really is just a bit too broad. --Deviant -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBMfHIJDAJap8fyDMVAQEucAf+JxcuBAIoI0pamvlryqLQETpwrBPoVaPi EUMNWNY1B3iG9nuQ/3U5mhdMNK0ih4RoCDifMPnKGD+iDIjUoMHmGEDtScBCLVe2 cDaAQ54JXpwNvlzhmfvaPc4wUZD/gDgtHBHLOoLZNarEPNgVLtYuFgeJeCEruqTX UU5usrgoMUZrxT/dRnYcPs6YRT7cgOxnOWNnTsZBiIpDyEkvGPZBxZhDp25DESTq q0zE9BLmWCgpHyi3QYXCfOTMLhkd4k/mt/LSZtEDHl55kLphtQN4N1Y1xgNK5BIs o5cjzh7aRLc0fvw8WG1i85dxtRBhXIPAUA8sRVyPhHu9qiw82D1qcA== =01xE -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Agreed... but there should be mention of stuff like "Here's our new cryptosystem, try and crack it. If you do, we'll give you the software free," or "here's a big block of ciphertext we encrypted with our proprietary algorithm which we won't describe, try and crack it, but it is unbreakable, however if you do crack it you win a free trip to visit us." Distinguishing what sounds to be a real contest and what sounds like a marketing gimmick would be good. On Sun, 21 Jul 1996, The Deviant wrote:
Be wary of marketing gimmicks related to "if you can crack our software" contests.
Even the best cryptographers and security professionals have done this. RSA did it with their Public Key system, which took 20+ years to break. Throughout history, many security mechanisms, even the best ones, including Cyphers, Locks, Firewalls, etc. have been known to go as far as to offer prizes (some extremely high, upwards of a million dollars, some as low as RSA's famous $100 prize)
I think that this one really is just a bit too broad.
--Deviant
- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jeremey Barrett Senior Software Engineer jeremey@forequest.com The ForeQuest Company http://www.forequest.com/ "less is more." -- Mies van de Rohe. Ken Thompson has an automobile which he helped design. Unlike most automobiles, it has neither speedometer, nor gas gage, nor any of the numerous idiot lights which plague the modern driver. Rather, if the driver makes any mistake, a giant "?" lights up in the center of the dashboard. "The experienced driver", he says, "will usually know what's wrong." -- 'fortune` output -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMfJpFy/fy+vkqMxNAQEq3gP+MKgGjr/hW/IFnl4SDchCPyqy/MwXWjLj LSW+p7BoZJBNcYuK9HhPAH2myKGnXsGfVSAayV6ldTVToQDVsDKBsmFiAc8ONL4y wDMwAp/S69D8kJWRPODMyUbmBZH5cCSxB65/lN4sm/PIbByF/323w8axX0Q2/WTZ 30bnSBr3ep0= =srzc -----END PGP SIGNATURE-----
"Deviant" == The Deviant
writes:
On Sat, 20 Jul 1996, Deranged Mutant wrote:
Subject: A Snake-Oil FAQ
Be wary of marketing gimmicks related to "if you can crack our software" contests.
Deviant> I think that this one really is just a bit too broad. Not really. What about the `unbreakable OTP' system challenge that went through this list a couple of months ago? ``Break our algorithm, and we sell you the company for $1''. The algorithm was broken, and the vendor slithered away never to be heard from again (but did not sell the worthless company). It's a good metric. -- steve@miranova.com baur Unsolicited commercial e-mail will be proofread for $250/hour. Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone except you in November.
At 11:03 PM -0700 7/20/96, The Deviant wrote:
Snake-Oil Warning Signs Encryption Software to Avoid
(Revision 0.1)
Looks very nicely done. I think you pretty much covered it... but...
Be wary of marketing gimmicks related to "if you can crack our software" contests.
Even the best cryptographers and security professionals have done this. RSA did it with their Public Key system, which took 20+ years to break. Throughout history, many security mechanisms, even the best ones, including Cyphers, Locks, Firewalls, etc. have been known to go as far as to offer prizes (some extremely high, upwards of a million dollars, some as low as RSA's famous $100 prize)
I think that this one really is just a bit too broad.
So is your comment. What was broken was not public key, but a particular key length (and by implication shorter ones). You can do that with just about any system, even a one-time pad, by brute force, but it won't buy you much more than sharpening your skills, for longer keys. One particular public key algorithm (you aren't too specific here) WAS broken a few years ago, but that was not RSA and isn't used any longer. If memory isn't playing tricks on me it was the knapsack algorithm. David
[sorry Perry] On Sun, 21 Jul 1996, David Sternlight wrote:
So is your comment. What was broken was not public key, but a particular key length (and by implication shorter ones). You can do that with just about any system, even a one-time pad, by brute force, but it won't buy you
Really? The only way I know of forcing a one-time pad is to use a hardware QM-based random number generator to generate every possible decrypt, thus creating a number of universes equal to the number of possible keys. Since you can't tell if you're universe is the right one, one should always verify the information obtained against a second source. IANAL, so I can't say if such a decrypt would count as probably cause. Simon --- Cause maybe (maybe) | In my mind I'm going to Carolina you're gonna be the one that saves me | - back in Chapel Hill May 16th. And after all | Email address remains unchanged You're my firewall - | ........First in Usenet.........
-----BEGIN PGP SIGNED MESSAGE----- On Sun, 21 Jul 1996, Simon Spero wrote:
Date: Sun, 21 Jul 1996 16:05:59 -0400 (EDT) From: Simon Spero
To: David Sternlight Cc: The Deviant , Deranged Mutant , cypherpunks@toad.com Subject: Re: A Snake-Oil FAQ [sorry Perry]
On Sun, 21 Jul 1996, David Sternlight wrote:
So is your comment. What was broken was not public key, but a particular key length (and by implication shorter ones). You can do that with just about any system, even a one-time pad, by brute force, but it won't buy you
Really? The only way I know of forcing a one-time pad is to use a hardware QM-based random number generator to generate every possible decrypt, thus creating a number of universes equal to the number of possible keys. Since you can't tell if you're universe is the right one, one should always verify the information obtained against a second source. IANAL, so I can't say if such a decrypt would count as probably cause.
Simon
Yes, but this is even more un-revealing than the OTP'd message, cause now you have a list of messages that say Nuke Siam. Nuke Ohio. Nuke Hell. Nuke Shit. and so on and so forth, and any of them could be right. Its better just to rely on other techniques (physical key compromise, etc) than to have the _complete_ list of possibilities on OTP...
--- Cause maybe (maybe) | In my mind I'm going to Carolina you're gonna be the one that saves me | - back in Chapel Hill May 16th. And after all | Email address remains unchanged You're my firewall - | ........First in Usenet......... ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Umm... that would be Duke, next door in Durham...
Of course, I'm an NCSU fan anyway, but... --Deviant -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBMfKYgjAJap8fyDMVAQEHugf/QWCkRVsP4TYEUIp6ImA4NyDtnOCoI3qe pGWvcEC/4qbuwXnYJR9yO+OSQ3Kh0zYOzhLxKCPwVHtm8uwjaELxSUD7qGJOVRU5 4rw/envcubQ+hYxzxIkPZnq7tosJpDp9mNZOLcwhmE+g4oAMv6dKMJautqB737CE 5AWQU2+Nb2/HQ7ZUSNae/CCDjZRVnTSbuKapCCz5YaYk7QwIOK2komVKmA1fI8xi zLhdBagoS5Gtnt5nxnlHM+Gv57wxXZABJ4+woDbgr5/4grHkYW5Or3lqyNqV271A gvGkxYE6eO9IJH50Ryf8eTXLU4J81iGxDLglM3KlgF4hdWi8RnRvUw== =/egV -----END PGP SIGNATURE-----
To all who do not like to read Sternlight and anything about him: the following procmail recipe will solve all problems easily. :0 B * ^TOcypherpunks * Sternlight /dev/null This is much easier than trying to organize boycotts, etc. Saves lots of bandwidth too. Honestly, this boycott campaign looks out of place on Cypherpunks, at least to me. I mean, we are for freedom of speech, aren't we? Sternlight is talking about on-topic things. How come that renowned defenders of freedom of speech resorted to name calling and attempts to push their opponent out of the public forum? - Igor.
At 1:05 PM -0700 7/21/96, Simon Spero wrote:
[sorry Perry]
On Sun, 21 Jul 1996, David Sternlight wrote:
So is your comment. What was broken was not public key, but a particular key length (and by implication shorter ones). You can do that with just about any system, even a one-time pad, by brute force, but it won't buy you
Really? The only way I know of forcing a one-time pad is to use a hardware QM-based random number generator to generate every possible decrypt, thus creating a number of universes equal to the number of possible keys. Since you can't tell if you're universe is the right one, one should always verify the information obtained against a second source. IANAL, so I can't say if such a decrypt would count as probably cause.
Theoretically Simon is right. Nevertheless one-time pads have been broken through trial and error when they have been reused either out of laziness or force majeure. It's not a "monkeys in the British Museum" problem, since when you hit the right key sequences both encrypted text streams will fall cleanly out--otherwise the chances are overwhelming (given a decently long run) that one of the two streams will contain garbles or more likely be complete gibberish. It's a pretty simple computer program--all you need is a decent test for plaintext so you don't have to examine most of the test decryptions. David
On Sun, 21 Jul 1996, David Sternlight wrote:
It's not a "monkeys in the British Museum" problem, since when you hit the right key sequences both encrypted text streams will fall cleanly out--otherwise the chances are overwhelming (given a decently long run) that one of the two streams will contain garbles or more likely be complete gibberish.
Not with one-time-pads... the key is as long as the plaintext. Our Hamlet writing monkeys will produce, amongst others, numerous versions of the play where the prince's name is telmaH. As well as vastly more where the monkeys get all the way to the last sentence and then One-Time-Pads offer perfect security as long as they're only used once. If they're used more than once, they're not one-time-pads. --- Cause maybe (maybe) | In my mind I'm going to Carolina you're gonna be the one that saves me | - back in Chapel Hill May 16th. And after all | Email address remains unchanged You're my firewall - | ........First in Usenet.........
At 8:16 PM -0700 7/21/96, Simon Spero wrote:
On Sun, 21 Jul 1996, David Sternlight wrote:
It's not a "monkeys in the British Museum" problem, since when you hit the right key sequences both encrypted text streams will fall cleanly out--otherwise the chances are overwhelming (given a decently long run) that one of the two streams will contain garbles or more likely be complete gibberish.
Not with one-time-pads... the key is as long as the plaintext. Our Hamlet writing monkeys will produce, amongst others, numerous versions of the play where the prince's name is telmaH. As well as vastly more where the monkeys get all the way to the last sentence and then
One-Time-Pads offer perfect security as long as they're only used once. If they're used more than once, they're not one-time-pads.
This is getting silly. I made a comment about brute force search, explained what I meant, and now some want to pick nits about semantics. My meaning was clear. Things called "one time pads" have been broken when they were reused. Breaking them is a matter of brute force search and checking both decrypt streams for plaintext. If they are used correctly and not reused, that approach isn't available. End of story. David
On Sun, 21 Jul 1996, David Sternlight wrote:
This is getting silly.
And here I reach agreement with both you and Perry. --- Cause maybe (maybe) | In my mind I'm going to Carolina you're gonna be the one that saves me | - back in Chapel Hill May 16th. And after all | Email address remains unchanged You're my firewall - | ........First in Usenet.........
Good faqs have pointers to other good sources of information, even when they're pretty near authoritative. I'd point to Schneier, Rivest, and Blaze as people whose endorsements carry real weight, and point to the sci.crypt faq for more info. Other than that, it looked like a good start. I look forward to being able to point people to it. Adam Deranged Mutant wrote: | I've written a short "Snake Oil FAQ" below. It's incomplete and | needs some work (adding a few definitions, rewording, aesthetic | formatting, etc.), so think of it as a 'beta' FAQ (please don't post | it on web pages, though I don't mind if it's distributed among | anyone interested in criticizing or contributing). Comments and | suggestions would be appreciated. Note that the aim is to write | something accessible to 'newbies'. (Jeremy Barrett contributed to | this, BTW) -- "It is seldom that liberty of any kind is lost all at once." -Hume
participants (9)
-
Adam Shostack
-
David Sternlight
-
Deranged Mutant
-
dlv@bwalk.dm.com
-
ichudov@algebra.com
-
Jeremey Barrett
-
Simon Spero
-
Steven L Baur
-
The Deviant