On Wed, 21 Feb 1996, Tim Philp wrote:

The issue that I have not seen you address is one that has been brought up by several posters to this thread. This issue has to do with the fact that if you generate all of the keys (or whatever) what is to stop someone from offering one of your employees a LARGE bribe to cough up the keys?

Not to mention GAK. No bribe needed - just a "suit" showing up with what looks like a court order. -- Ed Carp, N7EKG Ed.Carp@linux.org, ecarp@netcom.com 214/993-3935 voicemail/digital pager 800/558-3408 SkyPager Finger ecarp@netcom.com for PGP 2.5 public key an88744@anon.penet.fi "Past the wounds of childhood, past the fallen dreams and the broken families, through the hurt and the loss and the agony only the night ever hears, is a waiting soul. Patient, permanent, abundant, it opens its infinite heart and asks only one thing of you ... 'Remember who it is you really are.'" -- "Losing Your Mind", Karen Alexander and Rick Boyes The mark of a good conspiracy theory is its untestability. -- Andrew Spring

IPG Sales writes:

Stubborness and stupidity are twins - Sophocles

IPG is both stubborn and stupid. How appropriate. Let me give you another quote. It is acually a long extract of a document written by Phil Zimmermann. Read it. Beware of Snake Oil =================== When examining a cryptographic software package, the question always remains, why should you trust this product? Even if you examined the source code yourself, not everyone has the cryptographic experience to judge the security. Even if you are an experienced cryptographer, subtle weaknesses in the algorithms could still elude you. When I was in college in the early seventies, I devised what I believed was a brilliant encryption scheme. A simple pseudorandom number stream was added to the plaintext stream to create ciphertext. This would seemingly thwart any frequency analysis of the ciphertext, and would be uncrackable even to the most resourceful Government intelligence agencies. I felt so smug about my achievement. So cock-sure. Years later, I discovered this same scheme in several introductory cryptography texts and tutorial papers. How nice. Other cryptographers had thought of the same scheme. Unfortunately, the scheme was presented as a simple homework assignment on how to use elementary cryptanalytic techniques to trivially crack it. So much for my brilliant scheme. From this humbling experience I learned how easy it is to fall into a false sense of security when devising an encryption algorithm. Most people don't realize how fiendishly difficult it is to devise an encryption algorithm that can withstand a prolonged and determined attack by a resourceful opponent. Many mainstream software engineers have developed equally naive encryption schemes (often even the very same encryption scheme), and some of them have been incorporated into commercial encryption software packages and sold for good money to thousands of unsuspecting users. This is like selling automotive seat belts that look good and feel good, but snap open in even the slowest crash test. Depending on them may be worse than not wearing seat belts at all. No one suspects they are bad until a real crash. Depending on weak cryptographic software may cause you to unknowingly place sensitive information at risk. You might not otherwise have done so if you had no cryptographic software at all. Perhaps you may never even discover your data has been compromised. Sometimes commercial packages use the Federal Data Encryption Standard (DES), a fairly good conventional algorithm recommended by the Government for commercial use (but not for classified information, oddly enough-- hmmm). There are several "modes of operation" the DES can use, some of them better than others. The Government specifically recommends not using the weakest simplest mode for messages, the Electronic Codebook (ECB) mode. But they do recommend the stronger and more complex Cipher Feedback (CFB) or Cipher Block Chaining (CBC) modes. Unfortunately, most of the commercial encryption packages I've looked at use ECB mode. When I've talked to the authors of a number of these implementations, they say they've never heard of CBC or CFB modes, and didn't know anything about the weaknesses of ECB mode. The very fact that they haven't even learned enough cryptography to know these elementary concepts is not reassuring. And they sometimes manage their DES keys in inappropriate or insecure ways. Also, these same software packages often include a second faster encryption algorithm that can be used instead of the slower DES. The author of the package often thinks his proprietary faster algorithm is as secure as the DES, but after questioning him I usually discover that it's just a variation of my own brilliant scheme from college days. Or maybe he won't even reveal how his proprietary encryption scheme works, but assures me it's a brilliant scheme and I should trust it. I'm sure he believes that his algorithm is brilliant, but how can I know that without seeing it? In all fairness I must point out that in most cases these terribly weak products do not come from companies that specialize in cryptographic technology. Even the really good software packages, that use the DES in the correct modes of operation, still have problems. Standard DES uses a 56-bit key, which is too small by today's standards, and may now be easily broken by exhaustive key searches on special high-speed machines. The DES has reached the end of its useful life, and so has any software package that relies on it. There is a company called AccessData (87 East 600 South, Orem, Utah 84058, phone 1-800-658-5199) that sells a package for $185 that cracks the built-in encryption schemes used by WordPerfect, Lotus 1-2-3, MS Excel, Symphony, Quattro Pro, Paradox, and MS Word 2.0. It doesn't simply guess passwords-- it does real cryptanalysis. Some people buy it when they forget their password for their own files. Law enforcement agencies buy it too, so they can read files they seize. I talked to Eric Thompson, the author, and he said his program only takes a split second to crack them, but he put in some delay loops to slow it down so it doesn't look so easy to the customer. He also told me that the password encryption feature of PKZIP files can often be easily broken, and that his law enforcement customers already have that service regularly provided to them from another vendor. In some ways, cryptography is like pharmaceuticals. Its integrity may be absolutely crucial. Bad penicillin looks the same as good penicillin. You can tell if your spreadsheet software is wrong, but how do you tell if your cryptography package is weak? The ciphertext produced by a weak encryption algorithm looks as good as ciphertext produced by a strong encryption algorithm. There's a lot of snake oil out there. A lot of quack cures. Unlike the patent medicine hucksters of old, these software implementors usually don't even know their stuff is snake oil. They may be good software engineers, but they usually haven't even read any of the academic literature in cryptography. But they think they can write good cryptographic software. And why not? After all, it seems intuitively easy to do so. And their software seems to work okay. Anyone who thinks they have devised an unbreakable encryption scheme either is an incredibly rare genius or is naive and inexperienced. Unfortunately, I sometimes have to deal with would-be cryptographers who want to make "improvements" to PGP by adding encryption algorithms of their own design. I remember a conversation with Brian Snow, a highly placed senior cryptographer with the NSA. He said he would never trust an encryption algorithm designed by someone who had not "earned their bones" by first spending a lot of time cracking codes. That did make a lot of sense. I observed that practically no one in the commercial world of cryptography qualified under this criterion. "Yes", he said with a self assured smile, "And that makes our job at NSA so much easier." A chilling thought. I didn't qualify either. The Government has peddled snake oil too. After World War II, the US sold German Enigma ciphering machines to third world governments. But they didn't tell them that the Allies cracked the Enigma code during the war, a fact that remained classified for many years. Even today many Unix systems worldwide use the Enigma cipher for file encryption, in part because the Government has created legal obstacles against using better algorithms. They even tried to prevent the initial publication of the RSA algorithm in 1977. And they have squashed essentially all commercial efforts to develop effective secure telephones for the general public. The principal job of the US Government's National Security Agency is to gather intelligence, principally by covertly tapping into people's private communications (see James Bamford's book, "The Puzzle Palace"). The NSA has amassed considerable skill and resources for cracking codes. When people can't get good cryptography to protect themselves, it makes NSA's job much easier. NSA also has the responsibility of approving and recommending encryption algorithms. Some critics charge that this is a conflict of interest, like putting the fox in charge of guarding the hen house. NSA has been pushing a conventional encryption algorithm that they designed, and they won't tell anybody how it works because that's classified. They want others to trust it and use it. But any cryptographer can tell you that a well-designed encryption algorithm does not have to be classified to remain secure. Only the keys should need protection. How does anyone else really know if NSA's classified algorithm is secure? It's not that hard for NSA to design an encryption algorithm that only they can crack, if no one else can review the algorithm. Are they deliberately selling snake oil? There are three main factors that have undermined the quality of commercial cryptographic software in the US. The first is the virtually universal lack of competence of implementors of commercial encryption software (although this is starting to change since the publication of PGP). Every software engineer fancies himself a cryptographer, which has led to the proliferation of really bad crypto software. The second is the NSA deliberately and systematically suppressing all the good commercial encryption technology, by legal intimidation and economic pressure. Part of this pressure is brought to bear by stringent export controls on encryption software which, by the economics of software marketing, has the net effect of suppressing domestic encryption software. The other principle method of suppression comes from the granting all the software patents for all the public key encryption algorithms to a single company, affording a single choke point to suppress the spread of this technology. The net effect of all this is that before PGP was published, there was almost no highly secure general purpose encryption software available in the US. I'm not as certain about the security of PGP as I once was about my brilliant encryption software from college. If I were, that would be a bad sign. But I'm pretty sure that PGP does not contain any glaring weaknesses (although it may contain bugs). The crypto algorithms were developed by people at high levels of civilian cryptographic academia, and have been individually subject to extensive peer review. Source code is available to facilitate peer review of PGP and to help dispel the fears of some users. It's reasonably well researched, and has been years in the making. And I don't work for the NSA. I hope it doesn't require too large a "leap of faith" to trust the security of PGP. -- Phil Zimmerman, in the PGP manual. IPG Sales writes:

1. The OTPs are generated on a standalone diskette only system,

They are not One Time Pads. They are keys for a random number generator. Your continued assertion that they are One Time Pads is fraudulent. They are not one time pads by any definition ever previously used. Furthermore, as has been stated, it is completely unacceptable for keys to be generated by third parties.

2. From there, they go to QC - we perform:

The QC you perform is irrelevant. The system you sell is insecure in a practical sense, likely uses an insecure PRNG, and uses names and makes claims that come very close to being fraudlent. It is harder, not easier, to manage the keys from your system that supposedly "eliminates key management", and you don't even have any shame about the fact that you are ignorant of the field you work in.

Ralph

Perry

IPG Sales <ipgsales@cyberstation.net> said: IS> Mike, the keys are encrypted with an OTP that only the intended IS> recipient can open - a special, subsystem used for that purpose IS> only - employing the same techniquers, but entirely separate and IS> apart from the primary user system - any inteceptor would have to IS> break trhe system, which we claim is impossible. So you send not one, but two sets of one time pads out of band? Well, if _both_ OTP shipments are intercepted and duplicated, what keeps the interceptor from getting the keys? -- #include <disclaimer.h> /* Sten Drescher */ Unsolicited email advertisements will be proofread for a US$100/page fee.

Mike, the keys are encrypted with an OTP that only the intended recipient can open - a special, subsystem used for that purpose only - employing the same techniquers, but entirely separate and apart from the primary user system - any inteceptor would have to break trhe system, which we claim is impossible. On Wed, 21 Feb 1996, Mike McNally wrote:

IPG Sales writes:

...

We do not keep copies, we would not be in business 30 days if we did.

How do you ensure that the keys are not intercepted, duplicated by a man-in-the-middle, and forwarded?

______c_____________________________________________________________________ Mike M Nally * Tiv^H^H^H IBM * Austin TX * I want more, I want more, m5@tivoli.com * m101@io.com * I want more, I want more ... <URL:http://www.io.com/~m101> *_______________________________

IPG Sales writes:

Mike, the keys are encrypted with an OTP that only the intended recipient can open - a special, subsystem used for that purpose only - employing the same techniquers, but entirely separate and apart from the primary

Could you please learn how to spell? You cannot possible send your keys to the recipients encrypted in a one time pad, because a one time pad can be used only once. Every bit of keying material you would send your clients would use up one bit of the material they had. That would mean that you could never send your clients new keying material this way. The phrase one time pad is a fraud, plain and simple. I mean that in the most technical, legal sense. Advertise using that term and the FTC can and will throw you in jail. What you have here is some sort of conventional stream cipher conked up from a PRNG. You've solved no key management problems. What you've done is simply generate lots of hype. When I see the PRNG I suspect that I'll discover that the thing is nothing more than some sort of multi-pass linear congruential generator that cracks open like an egg.

user system - any inteceptor would have to break trhe system, which we claim is impossible.

On Wed, 21 Feb 1996, Mike McNally wrote:

...

IPG Sales writes:

...

We do not keep copies, we would not be in business 30 days if we did.

How do you ensure that the keys are not intercepted, duplicated by a man-in-the-middle, and forwarded?

______c____________________________________________________________________

_

...

Mike M Nally * Tiv^H^H^H IBM * Austin TX * I want more, I want more, m5@tivoli.com * m101@io.com * I want more, I want more ... <URL:http://www.io.com/~m101> *______________________________ _