I've made some comments below.
Some deletions are marked with <<double brackets>> and insertions in
[square brackets].
Other comments preceded with >>.
thx for looking over the comments.
g.
----------
From: Deranged Mutant[SMTP:WlkngOwl@unix.asb.com]
Sent: Saturday, July 20, 1996 9:37 AM
To: cypherpunks(a)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)
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.
>> Additionally you will see terms that are
* specially coined to sound as if they mean something
* used in a way that the profession generally doesn't do.
Check for other references to the "technologies" referred to, and if you
find nothing in any literature (even by doing a not search) then you should
be suspect.
Examples include:
New Type of Cryptography?
-------------------------
Beware of any vendor who claims to have invented a "new type of
cryptography".
>> Or "new breakthroughs"; extremely smart people have been working on
modern cryptographic systems for decades; the chances of someone reputable
coming up with a viable "revolutionary, breakthrough" cryptosystem without
exhaustive peer review and analysis are about zero.
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.
>> any cryptosystem, no?
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.
>> Note: the newbie won't know what those are. Descriptions of Vernam,
Enigma, etc. would be a Good Thing here, or pointers to descriptions. I am
not qualified to describe them adequately here, but the FAQ should somehow
clarify this.
If the product's authors sound like they are entirely unfamiliar
with the state of the art, that's a good warning sign.
>> How would that be manifest? See above comment about invented or misused
terms. Maybe you could say: if a program's author cannot explain the
historical precedents of his technology ("it's a substitution/permutation
network..." or "it's a system relying on solving the discrete log problem
in GF(9999999)" .... etc." then it's probably bogus.
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.
>> Other comments on cpunks have addressed this. Here's how it could be
caveat-ed: Any such contest which seems to be OVERSTATED (e.g. "I'll give
you the keys to the company ...") in relation to the size, maturity, and
reputability of the offering entity (company or individual) is to be
suspect. Netscape offering tee-shirts and such for breaking a system is
one thing. Someone you have never heard of offering his entire company is
something else. I think there will necessarily be some fuzziness here.
One-Time-Pads
-------------
A snake-oil vendor may claim the system uses a one-time-pad (OTP),
which, when implemented ABSOLUTELY CORRECTLY, is 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 [perhaps deliberately] confuse random session keys or
initialization vectors
with OTPs.
>> The vendor may try to capitalize on the well-known unbreakability
property of (properly used) OTP's and try to call whatever it is he is
offering an OTP. Any variation from the fundamental rules of what an OTP
is makes the claim bogus. Any vendor who tries to pass off his invention
as OTP when it is not has, by definition, reduced his credibility to
dangerously low levels.
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>> [citing] 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.)
>> Maybe some elaboration: the reputable cryptosystems in use today are all
subject to various attacks with various levels of vulnerability. A vendor
claiming this as some fatal flaw in those systems making them unusable also
demonstrates that the vendor has no credibility. The reality is that these
reuptable systems are and can be engineered to provide required security
levels depending on the value of the data and the costs of mounting the
attacks, and these parameters are known and understood. How? By years of
academic research and analysis by the best minds in the field. Someone
coming along and claiming new earthshattering weaknesses in those
cryptosystems, who has not presented those findings to the crypto research
community in the appropriate forums and had them subject to rigorous
examination, is a fool and/or not to be trusted. This is a corollary to
the warnings about claims of "new revolutionary" cryptosystems; it is just
as fatal to credibility to claim that a trusted system is weak.
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.
>> Again, how is the newbie to be helped detect this ?? Hmmm.
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(a)unix.asb.com (root@magneto)
AB1F4831 1993/05/10 Deranged Mutant <wlkngowl(a)unix.asb.com>
Send a message with the subject "send pgp-key" for a copy of my key.
