Cryptography-Digest Digest #59
Cryptography-Digest Digest #59, Volume #14Mon, 2 Apr 01 02:13:01 EDT Contents: Avoiding bogus encryption products: Snake Oil FAQ (C Matthew Curtin) From: C Matthew Curtin [EMAIL PROTECTED] Crossposted-To: alt.security,comp.security.misc,comp.infosystems,comp.answers,sci.answers,alt.answers,news.answers Subject: Avoiding bogus encryption products: Snake Oil FAQ Date: 2 Apr 2001 05:39:02 GMT URL: http://www.interhack.net/people/cmcurtin/snake-oil-faq.html Version: 1.9 Archive-name: cryptography-faq/snake-oil Posting-Frequency: monthly Snake Oil Warning Signs: Encryption Software to Avoid Copyright © 1996-1998 Matt Curtin [EMAIL PROTECTED] April 10, 1998 Contents * Contents * Introduction * Basic Concepts o Symmetric vs. Asymmetric Cryptography o Secrecy vs. Integrity: What are you trying to protect? o Key Sizes o Keys vs. Passphrases o Implementation Environment * Snake Oil Warning Signs o ``Trust Us, We Know What We're Doing'' o Technobabble o Secret Algorithms o Revolutionary Breakthroughs o Experienced Security Experts, Rave Reviews, and Other Useless Certificates o Unbreakability o One-Time-Pads o Algorithm or product X is insecure o Recoverable Keys o Exportable from the USA o ``Military Grade'' * Other Considerations * Glossary * Index * References Administrativia Distribution Distribution of this document is unlimited. We're specifically trying to reach people who are not experts in cryptography or security but find themselves making decisions about what sorts of crypto (if any) to use, both for their organizations and for themselves. The Snake Oil FAQ is posted monthly to sci.crypt, alt.security, comp.security, comp.answers, and comp.infosystems. It is available in PostScript and PDF form (ideal for printing) via the web at http://www.interhack.net/people/cmcurtin/snake-oil-faq.ps http://www.interhack.net/people/cmcurtin/snake-oil-faq.pdf and HTML at http://www.interhack.net/people/cmcurtin/snake-oil-faq.html Disclaimer All contributors' employers will no doubt disown any statements herein. We're not speaking for anyone but ourselves. This is a compilation of common habits of snake oil vendors. It cannot be the sole method of rating a security product, since there can be exceptions to most of these rules. From time to time, a reputable vendor will produce something that is actually quite good, but will promote it with braindead marketing techniques. But if you're looking at something that exhibits several warning signs, you're probably dealing with snake oil. Every effort has been made to produce an accurate and useful document, but the information herein is completely without warranty. This is a work-in-progress; feedback is greatly appreciated. If you find any errors or otherwise wish to contribute, please contact the document keeper, Matt Curtin [EMAIL PROTECTED] Document History With the rise in the number of crypto products came a rise in the number of ineffective or outright bogus products. After some discussion about this on the cypherpunks list, Robert Rothenburg [EMAIL PROTECTED] wrote the first iteration of the Snake Oil FAQ. Matt Curtin took the early text and munged it into its current state with the help of the listed contributors (and probably some others whose names have inadvertently missed. Sorry in advance, if this is the case.) Contributors The following folks have contributed to this FAQ. Jeremey Barrett [EMAIL PROTECTED] Steven M. Bellovin [EMAIL PROTECTED] Matt Blaze [EMAIL PROTECTED] Bo Dvmstedt [EMAIL PROTECTED] Gary Ellison [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Larry Kilgallen [EMAIL PROTECTED] Dutra Lacerda [EMAIL PROTECTED] Felix Lee [EMAIL PROTECTED] Colin Plumb [EMAIL PROTECTED] Jim Ray [EMAIL PROTECTED] Terry Ritter [EMAIL PROTECTED] Robert Rothenburg [EMAIL PROTECTED] Adam Shostack [EMAIL PROTECTED] Rick Smith [EMAIL PROTECTED] Randall Williams [EMAIL PROTECTED] Introduction Good cryptography is an excellent and necessary tool for almost anyone. Many good cryptographic products are available commercially, as shareware, or free. However, there are also extremely bad cryptographic products which not only fail to provide security, but also contribute to the many misconceptions and misunderstandings surrounding cryptography and security. Why ``snake oil''? The term is used in many fields to denote something sold without consideration of its quality or its ability to fulfill its vendor's claims. This term originally applied to elixirs sold in traveling medicine shows. The salesmen would claim their elixir would cure just about any ailment that a potential
Cryptography-Digest Digest #59
Cryptography-Digest Digest #59, Volume #13 Tue, 31 Oct 00 17:13:00 EST Contents: Re: RSA Multiprime (Bob Silverman) Re: BENNY AND THE MTB? (SCOTT19U.ZIP_GUY) Re: ciphertext smaller than blocksize ([EMAIL PROTECTED]) Re: how i decode this? ([EMAIL PROTECTED]) Re: How do I detect invalid passwords? ([EMAIL PROTECTED]) Give it up? (Tom St Denis) Re: Is RSA provably secure under some conditions? (Shai Halevi) Re: Graphics and Encription (wtshaw) Re: BENNY AND THE MTB? ([EMAIL PROTECTED]) Re: Is RSA provably secure under some conditions? (Roger Schlafly) Re: Searching for a good PRNG (David Schwartz) Re: XOR based key exchange protocol - flawed? (David Schwartz) From: Bob Silverman [EMAIL PROTECTED] Subject: Re: RSA Multiprime Date: Tue, 31 Oct 2000 20:00:51 GMT In article [EMAIL PROTECTED], Francois Grieu [EMAIL PROTECTED] wrote: Finding a 192-bit prime with ECM will be a little easier than factoring a 576-bit number with GNFS. Maybe, but this must be close. According to http://www.loria.fr/~zimmerma/records/ecmnet.html the largest prime factor found with ECM for a moreless general number is 177 bits, for an effort that probably was below last years sucess for 512 bit using GNFS. This tells the thresold (between ECM and GNFS for product of 3 random primes of n bits) is over n = 177 bits, but how do we get to 192 bits ? Getting from 177 to 192 bits is about a factor of 3 in effort. A naiive use of the complexity functions for ECM vs. GNFS, assuming that o(1) = 0 yields an effort of about 6 x 10^12 * M(512) to find a 192 bit prime via ECM vs an effort of 2 x 10^19 to factor a general 512 bit number with GNFS. M(N) is the number of operations (adds, mults, divs, etc.) to add two points on an elliptic curve modulo an N bit number. This is "about" 10^5 for N = 512; note that multiplications take more than 1 cycle whereas almost all of the GNFS operations take only 1 cycle. -- Bob Silverman "You can lead a horse's ass to knowledge, but you can't make him think" Sent via Deja.com http://www.deja.com/ Before you buy. -- From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) Crossposted-To: talk.politics.crypto Subject: Re: BENNY AND THE MTB? Date: 31 Oct 2000 20:02:45 GMT [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote in [EMAIL PROTECTED]: What follows is a story that may or may not be true Supose there is a group that is sending messages and they have a code book of 256 symbols most of which are words. The MTB ( a fictitous group) has been monitoring them and wants to know what the leader Benny lewis ( also fictistous) is sending to them. The group started by sending messages by hand but the MTB got a copy of the code book. After a period of time Benny and his boys decide to get modern so they stated using QHQ in the non public key mode. The mode where the public is using compression and encryption. But the boys back at the MTB laugh since even when they have been out drinking they brag they can decrypt any QHQ program with there methods. The boys know that there billion dollar quantam computer can find the solution of almost all meassages since usually there is only one possible solution to the decryption compression process and there tool swiftly locks in on it. But Benny is no fool so he still keeps the code book for first layer and then decides to use Matt's bicom program to do the compression and encryption. The resultant file is then zipped and sent to the internet. THe boys still laugh since they have heard that Riandoll is the encryption method that Matt used. And they already have a patch to handle the expected inclusion of the cipher to QHQ. So they spend a week to modify it to use Matt's bijective compression. They are still laughing when they get the first message to decyrpt. Since it is only a byte long. Some of the boys don't even want to try to turn the quantum computer on. One byte they say. How many possible messages could that decrypt to. But for grins they test it out. It spits out a 20 byte answer that they run though the code book. The message does not quite make sense so they do it again. They get a 16 byte message this time. They think something is wrong with the machine. Then a tech with a high school degree reminds them that it spits out at random a possilbe valid anwser. So maybe there is more than one possible answer. Something that has not happend with all the QHQ messages they worked with before. So they decide to really take a long time they run the thing all nite. Spitting out thousands of possilbe messages that could have been encrypted into that one byte. By this time they are worried they realize there billion dollar quantum computer is worthless and that there are at least 2**100 different possible messages that could have been sent. They are at a loss. THey do the only thing they can they try to
Cryptography-Digest Digest #59
Cryptography-Digest Digest #59, Volume #12 Mon, 19 Jun 00 04:13:01 EDT
Contents:
Re: Comments please: A protocol for Digital voting (zzapzing)
Re: Is Gretchen down? (Patrick Farrell)
Mathematical formula ("Yuriy Stul")
Re: Extending LFSR.. (Simon Johnson)
Re: Extending LFSR.. (Simon Johnson)
Re: Mathematical formula (Mack)
Re: XOR versur MOD (Mack)
Question about lja1 (Benjamin Goldberg)
Re: XOR versur MOD (Simon Johnson)
Re: Extending LFSR.. (Simon Johnson)
Re: Mathematical formula ("Douglas A. Gwyn")
Re: Mathematical formula (Simon Johnson)
Re: small subgroups in Blum Blum Shub (David A. Wagner)
Re: Encryption routine anyone? (Bob Deblier)
Re: Logical attack on RSA ("Michael Brown")
Re: software protection schemes (wtshaw)
Re: LSFR, a character twist (wtshaw)
Subject: Re: Comments please: A protocol for Digital voting
From: zzapzing [EMAIL PROTECTED]
Date: Sun, 18 Jun 2000 20:37:39 -0700
Let's call the random number generated by the validator V
and the random string generated by the individual voter I.
I have noticed a few more "aspects" of your protocol which
might be considered weaknesses. First of all the
validator can disenfranchize anyone he pleases by refusing
to recognize his value of V as valid, or by sending him
some random numbers instead of a validation of I. The
disenfranchized voter will not be able to prove that he was
disenfranchized. Also the validator could disenfranchize a
voter after the vote is cast by refusing to publish the
voters vote in the list of valid votes. The voter would of
course be aware that this had occured but would not ba able
to prove it to anyone else without sacrificing his anonymity.
and noone else would ever suspect that it occured if he did
not object. These acould be problems which could not possibly
be overcome, its true, but the potential weaknesses of any
protocol should be made apparent (in other words, nothing
personal).
I have also noticed that this protocol is unnecessarily
complex in at least one aspect. That is, the multiple
validations that are done by a long string of remailers, in
order to eventually get I validated. Let me explain a simpler
way to do this.
First of all, each voter puts his individual string, I into
an electronic envelope. Let e(I) denote this. This is the
same as your protocol. Next, the voter sends, through
anonymous broadcast, the pair V,e(I) to the validator. the
validator checks V against his list and then validates e(I)
inside its electronic envelope. Call the result of this
v(e(I)). the validator publishes a list of all the values of
V along with their corresponding values of v(e(I)). The
voters find their V values in this list and read off their
corresponding v(e(I)) value, from which they calculate their
individual value of v(I) (by removing the elctronic envelope).
The voters send in their votes along with their v(I). I
believe this would result in less traffic and computation but
have the same security features as the procedure you proposed.
that said, the protocol could possibly be used for a very
large number of voters, Not all voting protocols can do more
than, say 100 people with present technology.
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
--
From: Patrick Farrell [EMAIL PROTECTED]
Crossposted-To:
alt.security.pgp,comp.security.firewalls,alt.privacy.anon-server,alt.privacy
Subject: Re: Is Gretchen down?
Date: Mon, 19 Jun 2000 00:00:57 -0500
Reply-To: [EMAIL PROTECTED]
It would in theory show up in the trace routes if you did that however.
Patrick
"Trevor L. Jackson, III" wrote:
I still think you have the difficulty ordering backward. "...slap another set of
wires on
..." is a non-trivial operation when you are dealing with trans-oceanic wires. Yet
in the
digital world setting up another virtual circuit is no big deal.
Patrick Farrell wrote:
Perhaps I grossly misunderstand the way a telegraph worked, but in my opinion
your comparing hooking up 2 phones on an analog phone system to 2 on a digital
system. In the first case, you just slap another set of wires on, in the
second, you can't. (Can't as in just hooking it up won't work)
Patrick
"Trevor L. Jackson, III" wrote:
Patrick Farrell wrote:
A telegraph signal does not fall into the same category as a high speed network
device.
Correct.
Duplicating telegrams required a massive amount of human effort. Rerouting or
T'ing a
high speed network can be done without a man in the loop, so it's drastically
easier.
Hell if you add a little impedance to a 100baseT cable it will fail,
yet I saw someone stick 2 computers back to back with arcnet cards in them and
put a coat hanger in between and network
Cryptography-Digest Digest #59
Cryptography-Digest Digest #59, Volume #11Sun, 6 Feb 00 15:13:01 EST
Contents:
Re: NIST, AES at RSA conference (Terry Ritter)
Re: RE ("Roger Schlafly")
Re: NIST, AES at RSA conference (Terry Ritter)
Re: NIST, AES at RSA conference (Terry Ritter)
Re: permission to do crypto research (wtshaw)
Re: ("C. Prichard")
Re: permission to do crypto research (David Wagner)
Re: RE ("C. Prichard")
Re: Scaleable Key Permutation Feature to be Added to CipherText (wtshaw)
Combining LFSR's (Ben Curley)
Re: permission to do crypto research (Glenn Larsson)
Re: ("C. Prichard")
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: NIST, AES at RSA conference
Date: Sun, 06 Feb 2000 18:13:20 GMT
On 6 Feb 2000 12:20:07 -, in
[EMAIL PROTECTED], in sci.crypt Paul Crowley
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Terry Ritter) writes:
In practice, I think we all know that a cipher which cannot be
attacked in the most favorable ways is in some sense "stronger" than
it would otherwise be.
[snip]
"Everybody thinks so," is not reasoning.
And here lies the crux of the argument. We haven't proven the
strength of our ciphers, and you haven't proven the strength of your
multiple encryption schemes. You're relying on just the reasoning you
accuse us of.
I dispute that. You have taken my words out of context and
misrepresented my position; while the words are similar, their meaning
is not.
"We all know" that if the most favorable attack cannot be applied,
only less favorable attacks remain. This form of "we all know" is
simple logic and is based on facts and logical consequences. It means
that I expect the reader to bring some minimal context to the
statement.
In contrast, "everybody thinks so," by itself, has no basis in fact or
logic.
If we had practical and provably secure ciphers, we would of course be
crazy not to use them. Since we don't, we have to rely on the
guesswork you deride.
Nonsense.
We can agree that there are no -- and probably *can* be no -- provable
ciphers. But that does not mean that we must accept what we have. It
does not mean that there is no point in attempting to protect against
possible problems, or reduce their effects, even though the resulting
system is no more provably strong than the original.
Such reasoning can be seen as a form of mathematical fallacy which is
often presented in early algebra, the "equality" of two infinities:
True, a cipher has infinite possibilities for failure, and true, a
multi-cipher also has infinite possibilities for failure, but it is
false that those two infinities are equal.
We can improve our situation by requiring opponents to use non-optimal
attacks or simultaneously attack multiple ciphers, and by reducing the
amount of plaintext under any one cipher.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
--
From: "Roger Schlafly" [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto,misc.int-property,misc.legal.computing
Subject: Re: RE
Date: Sun, 6 Feb 2000 10:30:09 -0800
C. Prichard [EMAIL PROTECTED] wrote in message
news:%cin4.357$[EMAIL PROTECTED]...
So assuming you want to RE Windows for the purpose of your encryption
research to find out how the program does something. If the encryption
method actually has nothing to do with copyright protection of 'Windows'
itself, then the law would not be applicable.
RE = reverse engineer
I am not sure about this. MS might argue that its copyright interest in
Windows
is not just to keep the bits on the disk from being copied. It also has
integrity
rights that keep purchasers from manipulating the code in unauthorized way.
Eg, it stops Compaq and HP from altering the startup screen. So MS might
claim that poking into Windows internals threatens its copyright protection.
The context of DVD/CSS encryption is however quite different. It seems that
the law is specifically pertaining to the distribution medium of copyright
materials. By examining the embedded algorithm in the DVD player, you are
able to explain possible contexts that allow you to examine code. I'm
guessing that you may legally even go so far as to explain your cause in
terms of wanting to "see pictures and hear sound" using your own
implementation of hardware and software. But when you become intent on
distribution of your product that circumvents the copyright protection of
the DVD/CSS distribution format, your previous work becomes tainted in the
eyes of the law.
Yes, but the Hollywood folks seems less concerned with copying the DVD
disk, and more concerned with licensing the DVD players. Ie, they know
they cannot control copying the disk, but think
Cryptography-Digest Digest #59
Cryptography-Digest Digest #59, Volume #9 Tue, 9 Feb 99 09:13:03 EST Contents: Re: hardRandNumbGen (R. Knauer) Re: RNG Product Feature Poll (Patrick Juola) Re: help wanted please (Mok-Kong Shen) Re: What is left to invent? (R. Knauer) Re: hardRandNumbGen (R. Knauer) Re: Rsa cryptology as a personal math project ([EMAIL PROTECTED]) Re: 2048-bit block cipher (Paul Crowley) Re: Privacy, Traps and Frozen Hell (Paul Crowley) Re: hardRandNumbGen (Patrick Juola) Re: 2048-bit block cipher ([EMAIL PROTECTED]) Re: What is left to invent? (R. Knauer) Re: What is left to invent? (R. Knauer) Re: Questions about pseudoprimes, testing primes (mathematical) (Ernst G. Giessmann) From: [EMAIL PROTECTED] (R. Knauer) Subject: Re: hardRandNumbGen Date: Tue, 09 Feb 1999 13:16:14 GMT Reply-To: [EMAIL PROTECTED] On 8 Feb 1999 08:49:11 -0500, [EMAIL PROTECTED] (Patrick Juola) wrote: The thing that really bothers me is that "good chance" part in your statement above. If your tests are probabilistic with only a "good chance" of being correct, then how can they be relied on? The "good chance" is quantifiable (as is the "fairly sure"). What is your acceptable degree of uncertainty? What is your minimal "good chance." I am not objecting to statistical measure per se. I could not do that and still believe that Quantum Mechanics is correct. My objections center on the fact that one cannot characterize the randomness of a TRNG by measuring the statistical properties of the numbers it generates. If that were the case, how do you explain what happens when a PRNG passes such tests, and yet that PRNG is a poor generator for crypto purposes. The only way to get a "minimal good chance" of characterizing the TRNG itself is to do a complete audit on it. That is what experimental scientists have to do to have a "minimal good chance" of having their experimental results accepted in the scientific community. If as a scientist I proposed that the soundness of my experimental equipment were determined by the output of that equipment, I would be laughed out of science. Yet that is exactly what is being proposed here - that the soundness of a TRNG be determined from its output. Remember that, according to modern physics, it's only probabilistic with a good chance that water will get hotter instead of colder when placed over a lit gas burner. I certainly have no quarrel with statistical mechanics. I once calculated the probability that all the molecules of air in a room would end up in the corner. A bit on the small side, so small that it would never have happened in the age of the Universe. BTW, I can rig that experiment you describe above to make you think the phenomenon is happening. I put water in the pot, create a separation, put in another layer of water and freeze that top layer. Then I put the thermometer at the bottom, and raise the temperature just to the point where the ice is about to fall into the bottom. Then I bring you in to observe how the temperature will decrease when I put the pot on the stove. You will only discover what is actually happening if you do a complete audit of how I prepared the system. The same is true of a TRNG. Bob Knauer "The world is filled with violence. Because criminals carry guns, we decent law-abiding citizens should also have guns. Otherwise they will win and the decent people will loose." --James Earl Jones -- From: [EMAIL PROTECTED] (Patrick Juola) Subject: Re: RNG Product Feature Poll Date: 8 Feb 1999 10:35:13 -0500 In article 79ms1g$[EMAIL PROTECTED], Herman Rubin [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], Michael Sierchio [EMAIL PROTECTED] wrote: "R. Knauer" wrote: Knauer -- I think that you're either being disingenuous or stupid. Most of your posts lead me to believe that you're intelligent, so I think you're intentionally misconstruing the point. Reasonable statistical properties are more than enough for cryptography, You will have to prove that assertion - I cannot take it on your word alone. In particular, I would have to see how indeterminancy comes from "reasonable statistical properties". Herman will correct me, but statisticians regard a sequence of outcomes as random if each outcome is independent of the previous ones. This is sufficient for crypto, and explains why PNRGs are inadequate -- if you include choice of initial conditions in "previous outcomes." Random is used in many ways. Many times this is assumed, but it is not necessarily the case. Sampling without replacement violated this assumption, and there are other models. Queuing models, birth and death processes, diffusion processes, and many others violate independence. So what you're staying is that independence prove
