I've been reading the mish-mash of replies from "IPG Sales" and have been trying to figure out exactly what it is they think they're doing. Aside from the crap about not revealing details due to patent-pending issues, but claiming it's the same as a process that's been in use since 1966 (clue: prior art == no patent) and an unwillingness to provide any names or references for all this apart from mentioning Ms. Denning and Leyland's web page, I think I've got something pieced together. Perhaps IPG Sales will be happy to tell me if I've got it right or not: Step 1. 100 friends and I pay IPG $$$. Step 2. IPG starts up a hardware-based random number generator, and spits out 5066-bit chunks of random data to be used as OTPs. Since each pair of friends needs unique data (wouldn't want them easedropping on our gossip about them), IPG will generate a large number of said chunks. The magic box remembers every chunk it's ever spewed and never, ever repeats itself. Step 3. IPG's Kwality Kontrol Dept. will run a bunch of statistical tests on the chunks (did I see the standard entropy calculation in the list?) to make sure they look truly random. Chunks failing the tests get tossed. Step 4. IPG takes the surviving chunks and runs them through a "prime number cycle wheel" which is some kind of rotor system, with something like 64 rotors, or perhaps 64 passes through an n-rotor system. It produces primes, or works with primes, or somehow large random primes (can a prime truly be called "random) either come in, go out, or both. Primes are involved here somehow. In any case, whatever comes out is part of 10^1690 (or from a previous message, 10^2330) possible results. Why this matters I do not know. Step 5. The results are somehow variable in length (?) or in some way eliminates the need for a OTP to be at least as large as the message to be encoded. This has been claimed several times. So somehow the original OTP chunk produces new pads of potentially infinite length? Step 6. IPG mails out a lot of floppies to me and my 100 friends containing lots of these resultant things (which still sound like OTPs.) I assume US Mail is completely trusted, data is never corrupted, disks are never lost or stolen, etc. Step 7. These results act as OTPs (aka Nvelopes) that are used to encode the message. My buddies use the matching chunks to decode the messages (aka Nvelopeners.) The software system does all the work, and I don't have to do anything (much like public-key systems today.) Err... okay, maybe I don't have this figured out. Still sounds like OTPs, and someone selling random data at $15 a pop per month. Having multiple floppies mailed to me monthly, with all the inherent difficulties, sounds like a lot more work than public-key management. My bozometer is pegged. Looking forward to having my oversights corrected, Wink -- winkjr@teleport.com "We offer freedom to the masses. It's a tough fight -- I'll grant you that -- but we're brave. We're well financed. We believe that God is on our side." -- Netscape CEO James Barksdale

I, too, am interested in seeing the underlying algorithms. Not because I don't believe that they work, but because I'm interested in seeing what you may have found that no one else has. However from your recent mailing I think I know what you're doing:

Starting with an OTP as seed? The algorithm may be fixed in a sense, but it employs a truse hardware random OTP to select intial settings, adds, and limits, so every one is new and unique - a lot of algorithnms can generate pseudfo trandom numbers, but onece you knw the algorithm, you can generate the random sequence. Our system does not do that - in oReder to solve the system, you must know what OTP was used, that is what was the true hardware generated OTP. Unless you know what that was, knowing the algorithm does nothing for you. If you understand that principle you understand the system.

I think this is the key. Question: if I knew the starting "OTP" that seeded your algorithms, would I be able to re-create the whole stream and decrypt a message? I suspect the answer is "yes". However if I knew the algorithm you were using, could I decrypt the message without the use of the "OTP" key? I don't know the answer to this question. I hope the answer is no. Assuming it is no, then I ask you: when can I see the algorithm you are using. Following is an example of why knowledge of the algorithm is useful but not harmful: Example: Let's assume I can securely exchange a "OTP" (key) with someone. I now run some algorithm using that "OTP", add in the plaintext, and out comes a random stream which is the encrypted message. Is this similar to what POTP does? I believe the answer is "yes". Let me submit that what I described here I can do with DES using ofb mode to generate a random number stream with which I encrypt the message. The fact that I know I used DES does not help me decrypt the message. I still need the "OTP" key in order to figure out which stream of random bits were used to encrypt the message.

Perhaps so, but our system does employ a true hardware generated OTP, and operates similiar to what you describe - however, the important differernce is that we use a smal;l OTP to generate a larger OTP, like stringing the cable across the Golden Gate narrows. Just becuase we convert over from a full OTP to a prime number wheel system configured from the OTP doers not mnean that the result is not an OTP - in theory it

Actually, this statement is false. What you have is a pseudo one-time pad, not a true one-time pad. It's close, though. The problem is that the means that you use to convert the smaller OTP to a larger OTP may be "flawed", and that is the algorithm that I think most people here want to see. I do believe that the 5600-bit OTP key material that you distribute is random. You claim it is hardware generated; I believe that. However that doesn't help me feel any less wary about the algorithm you use to convert that 5600-bit OTP to a larger pseudo-random stream. At best, you have a cipher with a 5600-bit key. If this is so, I congratulate you on it. However I think that I, and others on this list, would like to see how it is accomplished. This is mostly because I believe people here are wary of such systems; key management and random number generation is a tricky business, and its very easy to make a slip and get it wrong. Just look at Netscape and other systems which have fallen to simple attacks. I think that people here would like to prove whether or not your system is vulnerable to such attacks. Just remember that if it is not vulnerable, as you claim, then you have nothing to worry aout and you will gain the acknowledgement of the cypherpunks behind you. On the other hand, wouldn't you rather that you know if your system has a flaw, rather than having some cracker discover it and try to exploit it rather than inform you? That is a choice you will have to make. I believe the cypherpunks offer still stands: to test your algorithm. The choice is yours. -derek

On Mon, 19 Feb 1996, Derek Atkins wrote:

I, too, am interested in seeing the underlying algorithms. Not because I don't believe that they work, but because I'm interested in seeing what you may have found that no one else has. However from your recent mailing I think I know what you're doing:

...

Starting with an OTP as seed? The algorithm may be fixed in a sense, but it employs a truse hardware random OTP to select intial settings, adds, and limits, so every one is new and unique - a lot of algorithnms can generate pseudfo random numbers, but once you know the algorithm, you can generate the random sequence. Our system does not do that - in oReder to solve the system, you must know what OTP was used, that is what was the true hardware generated OTP. Unless you know what that was, knowing the algorithm does nothing for you. If you understand that principle you understand the system.

I think this is the key. Question: if I knew the starting "OTP" that seeded your algorithms, would I be able to re-create the whole stream and decrypt a message?

Answer - No, there are other things involved, time to microseconds, as well as the actual algorithm, recipient - name and relative number, and an additional user OTP. Remember that every OTP is a true OTP, and a new one is used for each transmission. The information to recreate the starting OTP is transmitted but is encrypted with the real starting OTP set, so it is not easy to figure out what the starting OTP is. Isuspect the answer is "yes". However if I

knew the algorithm you were using, could I decrypt the message without the use of the "OTP" key?

I don't know the answer to this question.

I hope the answer is no.

It is definitely NO: You must have the the individual OTP to XOR out the message - It is the key to the encryption, and the obvious decryption. The algorithm is impotent without the OTP. Assuming it is no, then I ask you: when can

I see the algorithm you are using. Following is an example of why knowledge of the algorithm is useful but not harmful:

Example: Let's assume I can securely exchange a "OTP" (key) with someone. I now run some algorithm using that "OTP", add in the plaintext, and out comes a random stream which is the encrypted message. Is this similar to what POTP does? I believe the answer is "yes". Let me submit that what I described here I can do with DES using ofb mode to generate a random number stream with which I encrypt the message. The fact that I know I used DES does not help me decrypt the message. I still need the "OTP" key in order to figure out which stream of random bits were used to encrypt the message.

That is true, except you have a monstrous problem with key distribution and the generation of the OTP keys. In effect, such a system would be can OTP system, except it would not be as clean and as fast, and as simplye as XORing the plain text with the OTP.

...

Perhaps so, but our system does employ a true hardware generated OTP, and operates similiar to what you describe - however, the important differernce is that we use a small OTP to generate a larger OTP, like stringing the cable across the Golden Gate narrows. Just becuase we convert over from a full OTP to a prime number wheel system configured from the OTP doers not mnean that the result is not an OTP - in theory it

Actually, this statement is false. What you have is a pseudo one-time pad, not a true one-time pad. It's close, though.

I cannot argue with that characterization;however, I would point out that a true One Time Pad must qualify as unpredictable, not absolute random. We could generate indeterminate length OTPs but they become unwieldy for huge files because the lengths must correspond - so we have gone to the propogating method! The problem is

that the means that you use to convert the smaller OTP to a larger OTP may be "flawed", and that is the algorithm that I think most people here want to see. I do believe that the 5600-bit OTP key material that you distribute is random. You claim it is hardware generated; I believe that. However that doesn't help me feel any less wary about the algorithm you use to convert that 5600-bit OTP to a larger pseudo-random stream.

At best, you have a cipher with a 5600-bit key.

Yes, but it would be trival and not that big of a space problem to expand to a 10,000 bit key, or even a 20,000 bit key. We simply change a few parameters, in the C programs. If this is so, I

congratulate you on it. However I think that I, and others on this list, would like to see how it is accomplished. This is mostly because I believe people here are wary of such systems; key management and random number generation is a tricky business, and its very easy to make a slip and get it wrong. Just look at Netscape and other systems which have fallen to simple attacks.

We will provide you with a free demonstration if you would like. We will also provide you with the methodology in written form, but becuase of certain methods employed, we will not release the source code - we want tio buy some time. In general, you will find the kernel of the propgations consists of 64 equation sets of the form: Bi=(Bi+Ci MOD Di) Mod 256 Large prime numbers ENCRYPTEXTi=OTP[Bi] XOR PLAINTEXTi Encryption OTP[Bi]=ENCRYPTEXTi Makes the OTP Dynamic Where the intial Bis, Cis and Dis are all randomly selected from a tables of 2048 random prime numbers, the 5600 bit OTP is used to make the selections from the 6144 prime numbers, Dis are always larger than either Cis or Bis. The Cis and Dis are also different prime mods of 256, there might be some repeats but not many from a selection of 64 from a set of 6144. The effect is that you put a plain text character into the system and the envcrypted character is XORed against a random character and the resultant becomes a part of the dynamically changing OTP. There is a little more to it but that is the essence!

I think that people here would like to prove whether or not your system is vulnerable to such attacks. Just remember that if it is not vulnerable, as you claim, then you have nothing to worry aout and you will gain the acknowledgement of the cypherpunks behind you. On the other hand, wouldn't you rather that you know if your system has a flaw, rather than having some cracker discover it and try to exploit it rather than inform you? That is a choice you will have to make.

I believe the cypherpunks offer still stands: to test your algorithm.

We would be most interested in allowing the cyberpunks to examine the program and use it as they like. We will provide source code for the propgation kernel, generating the large pseudo OTP from the real OTP - Actually there are two real time pads involved - a user oriented one and a message oriented one, nut that os only used to secure a user and for some smoothing operations. But that is the gist of it.

The choice is yours.

-derek

Try it, you will like it:

I have just read your conditions for releasing the information tha the group felt was necessary to evaluate your product. A couple of comments. First, the Cypherpunks are not an organized group who can agree to your conditions. This is simply a mailing list not a corporate entity to be contracted with. To attempt to treat them as such and to use their resources for your marketing gain is, in my opinion, less than honest. If the code has not been broken in 5 months, nothing will have been proved. A better model to follow would be that used (eventually) by Netscape. Release the code for comment and make changes based on weaknesses discovered by the group. My last point has to do with one of your restrictions. Why will you not release the information to Canadians? It cannot be ITAR, because it does not apply to Canadians. How can you claim that the Cypherpunks failed to break your system if you exclude its most brilliant members! <G>. Regards from Canada, Tim Philp =================================== For PGP Public Key, Send E-mail to: pgp-public-keys@swissnet.ai.mit.edu In Subject line type: GET PHILP ===================================

On Wed, 21 Feb 1996, IPG Sales wrote:

We are reconsidering the Canadian restrictions - and may change them - it is certainly not the ITAR quexstion, but another matter - we expect ^^^^^^^^^^^^^^^^^^ that Canadians will be included shortly - as to the question of using

Just what is this 'other matter'

Why do you want to make it a one way street? We believe fair is fair - if you want to chop off our neck, then we should be able to tell people that you tried and could not at some point in time -

I fail to see how this is a 'one way street'. You are interested in feedback on your system and want us to examine it and tell you of weaknesses. We are interested in any new system that claims to be secure and we can learn from the developments, and yes, mistakes of others. This sounds like a perfect quid pro quo to me. You seem to want more. You want to be able to use the 'name' of the cypherpunks to assist your marketing for whatever benefits that you see by exploiting our name. I say again, as others have said, we are simply a mailing list of people brought together by a common interest in cryptography. There is nothing to stop you from making your claims without our 'consent' or the 'Cypherpunks seal of approval'. The real problem that you have, is that there are knowledgable people on this list who have expressed doubts about your system. These people are well known to the press and in the security community and are not shy about expressing their opinions (right Perry? <G>). These are the people who you have to convince if you want to have our approval (whatever that is). Look at the history of algorithms that are generally considered secure. The code has been placed on the net for public comment and review. I think that all have benefited from this process. You have made the same mistake as some others who posted long samples of marketing 'noise' to the list using all of the keywords that we have come to regard as 'snake oil'. I have no idea if your product is indeed secure or snake oil. You have not published enough information for any reasonable person to make a determination. The form of your announcement was not appropriate for this forum or your needs. I submit that a better approach would have been to post the code to sci.crypt and send a short note to this list asking for comments. People who ask for help, and co-operate with us usually receive help. People who publish marketing junk, as you did, get abused. Let's concentrate on substance rather than form. Regards, Tim Philp =================================== For PGP Public Key, Send E-mail to: pgp-public-keys@swissnet.ai.mit.edu In Subject line type: GET PHILP ===================================

On Tue, 20 Feb 1996, IPG Sales wrote: Fess up guys. You are either: 1. A team of undergrads or graduate students conducting an "exploit". 2. A Detweiller tentacle. Dr. FC ? 3. The return of Alice D'nonymous ? 4. The reason the coderpunks lists was started. You've got to be ROTFL. See my sig. Arley Carter Tradewinds Technologies, Inc. email: ac@hawk.twinds.com www: http://www.twinds.com "Trust me. This is a secure product. I'm from <insert your favorite corporation or government agency>."

Finally, an honest man at IPG. Y'all are a hoot. I'll hire you as bozos for my kid's next birthday party. ROTFL Arley Carter Tradewinds Technologies, Inc. email: ac@hawk.twinds.com www: http://www.twinds.com "Trust me. This is a secure product. I'm from <insert your favorite corporation or government agency>." On Wed, 21 Feb 1996, IPG Sales wrote:

We fess up - we are pig farmers from TexasL, we never have been to these high fluting things you call schools, so we do not even know what you are talking about, much less anything about Cryptography.

On Wed, 21 Feb 1996, Arley Carter wrote:

...

On Tue, 20 Feb 1996, IPG Sales wrote:

Fess up guys. You are either:

1. A team of undergrads or graduate students conducting an "exploit". 2. A Detweiller tentacle. Dr. FC ? 3. The return of Alice D'nonymous ? 4. The reason the coderpunks lists was started.

You've got to be ROTFL. See my sig.

Arley Carter Tradewinds Technologies, Inc. email: ac@hawk.twinds.com www: http://www.twinds.com

"Trust me. This is a secure product. I'm from <insert your favorite corporation or government agency>."

Appreciately,

Ralph

...

...

Ladies and Gentlemen - For the last three plus weeks, some of the members of the C'Punks list have had the IPG algorithms in their possesion. None, to date have suggested that the system is unbreakable - to the contrary a few have stated that they believe it is unbreakable, but do not want to go on the record yet. I invite those that have copies of the system to acknowledge that fact and to state their opinions, if any. Some of these people have been helpful, and we have adopted some of their suggestions. For example, we are now call the encryption method, the ABC encryption method, because in the opinion of one person, it is so simple, straightforward and appropos as you will see. However, we want to expedite things. Accordingly, as of this date, we are now prepared to release the complete set of algorithms to any member of the C'punks mailing list who can establish that they are: 1. A citizen of the United States 2. Or a Citizen of Canada. We are willing to prove incontrovertibly, to your satisfaction, that the IPG ABC Encryption system is at once as secure, in the real sense, as a true OTP, or a pure 3064 bit prime number pair RSA system, and absolutely the fastest system possible, excepting possibly very short messages because of setup time. That is a lot of Chutzpah, but we are prepared to back it up, as you will see. We are prepared now, to send you a set of materials that can postively establish both of those assertions for yourself, beyond any doubt whatsoever. No ifs, no ands, no buts, no maybes, no anything. Period. Our agenda is very simple. 1. To prove beyond any doubt whatsoever that the system is absolutely unbreakable, and the fastest unbreakable system possible. 2. After that is agreed to, to prove beyond any doubt that the system is extremely simple and by far the easiest to use and operate. 3. That combined with RSA, or without RSA for that matter, the key distribution system is as secure and simple as any method available, including the public-private key method. No human ever gets involved, it is all fully automatic and uncorruptable. 4. That the key generation will be made to conform to your requirements - either by licensing the process to you, or by having an oversight group such as one of the Big Six, to provide continuous monitoring of the process to insure that no copies are kept and no one has access to the process. We can resolve any question you have in this regard. 5. That an interchange system will be implemented that provides the same degree of absolute guarantee of privacy, yet the two parties do not even have each others key. Yes it can be done, guaranteed. A few of you already know how, because they have the written copies of our materials. Temporarily however, we will only address point one. We will address the other four points after point one has been settled It will not take most of you weeks, or even days to establish that the IPG system is absolutely unbreakable, and that no system can possibly be faster. Most of you will be able to do it in a day, or even in a few hours, it is that simple. I suspect the reason that the few who have the materials are not ready to committ themselves is because they cannot believe their eyes and mind - it cannot be possible - something must be wrong. It is not though. What they see and what their minds are telling them is true. It is absolutely unbreakable and no digital system could possibly be faster. In all fairness though, we have only provided them with the materials necessary for them to conduct there own tests within the last 48 hours, so testing may still be under way. It is much faster than RD5, IDEA, DES or anything else available in the software version and with hardware implementation it can be made orders of magnitude faster, 1000s of times faster than those mentioned, or any Feistel type system or or any other system, of which we are aware. It is ideally suited to hardware implementation, with multilevels of parallelism, simple and practicable. We will send you a complete set of materials necessary for you to evaluate and test the system this date subject to the following. 1. You provide us with a telephone number that we can call you tonight to verify that you have an American or Canadian citizen, with a phone in one of those two countries. 2. That you provide us with an American or Canadian snail-mail address - we will send six of you, selected at random, registered copies of the materials provided to you, with some more detail, mainly relating to hardware implementation, though that is discussed in the Internet version. 3. That you agree to abide by ITAR, as well as by applicable copyrights and patents. That with respect to ITAR, that you will not provide a copy of the materials to anyone but you may tell them that IPG is making the materials available. Be forewarned again, we will not respond to any attacks made based upon any opinions, suppositions, hypotheses, guesses, thoughts, or anything else other than the facts. Nor will we respond to any of the same sort of things related to Key Distribution or the like other than to reiterate that we will license the manufacture of keys for the system. If you are an engineer, you will be amazed by how simple hardware implementation is, serial, simple one dimensional parallelism, and two level parrallelism, unbelievably so. We intend to license the manufacture of chips. So there my C'punk list friends. You threw down the gaunlet and challenged us. We accepted your challenge. Now, we are throwing down the gauntlet. To reiterate, we assert: 1. That IPG's ABC Encryption system it is absolutely proveably unbreakable, even to the point of quickly being self evidently so to most of you with any signficant mathematical background. 2. That is the fastest possible method of producing an unbreakable PRNG stream to be XORed with plain text - 3. That it is unbelieveably simple to implement and use, as simple as one of your associates said, as ABC. Some of you have spoken your piece without one iota of facts. We want all of you on the list to see the facts for yourself, It will make believers of you. Especially, we want those that jumped into the swimming pool, the fray, without anything other than dogma or opinions to see what the real facts are and how wrong they were. I close with three quotes: 1. The person who never alters their opinion is like standing water, and breeds reptiles of the mind. William Blake. "The Marriage of Heaven and Hell." 2. It is the uncompromisingness with which dogma is held that the danger lies. Samuel Butler - "The Way of All Flesh," 3. If we value knowledge, we must be free to follow wherever that search may lead us. The free mind is no barking dog, to be tethered on a ten-foot chain. Adlai Stevenson. Paraenthetically, IPG will not be tethered to a one pico meter chain that a few of you insist on trying to do. We urge you to take up this challenge. It is going to have far reaching implications for your clients and for your companies. It is the wave of the future, as you will quickly discover.

IPG Sales writes:

For the last three plus weeks, some of the members of the C'Punks list have had the IPG algorithms in their possesion.

You again? Go away. Our snakes are very well oiled already. .pm

-----BEGIN PGP SIGNED MESSAGE----- In list.cypherpunks, ipgsales@cyberstation.net writes:

Ladies and Gentlemen -

For the last three plus weeks, some of the members of the C'Punks list have had the IPG algorithms in their possesion.

None, to date have suggested that the system is unbreakable - to the contrary a few have stated that they believe it is unbreakable, but do not want to go on the record yet.

I invite those that have copies of the system to acknowledge that fact and to state their opinions, if any.

Since a copy of the IPG system has apparently arrived unsolicited in my mailbox this morning ("apparently" because I haven't unpacked or inspected the MIME message; "unsolicited" because I did not request it), I believe it's disclaimer time. I have entered into no agreements to inspect, test or validate the IPG software suite. In the absence of a valid contract for my services, I shall not inspect, test or offer opinions regarding the security of this product. IPG Sales is specificly enjoined from using my nym in any reference to validation of their product. Further, IPG is cautioned against using "cypherpunks" as a validation reference, as my subscription to this mailing list could then be construed as contributing to the claim of validation. This action is intended to guard against claims of the form "roy@sendai.cybrspc.mn.org has been unable to break our system", among others. Note to IPG: I review all contract offers. Feel free to contact me for terms, but be advised that I'm somewhat expensive. Note to c'punks: apologies for burning listwidth, but this looks like the proper Publication of Record for this notice. - -- Roy M. Silvernail [ ] roy@cybrspc.mn.org "Governments find it notoriously difficult to work with people that they cannot shoot." -- James A. Donald <jamesd@netcom.com> -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMU60chvikii9febJAQFSGgQAsDheQdfO1i4GMFLAwsjdpjkeLjLVHcP8 ZcIvAN4lp6LyqEVSxlzWurubz+Cj3qHaUB/dI6P+QNjj4zylmD3i1m1rfRxEHz4J Nq21+uhmS1dsKhXOXcQ+pGpmygYOPMaRDD8kWsAt4XADDrqnOdRDLP14YyueiHwK pjoZl70XeF8= =8/sf -----END PGP SIGNATURE-----

Adam Shostack wrote:

| Since a copy of the IPG system has apparently arrived unsolicited in my | mailbox this morning...

Me too.

I'd like to add my name to Roy's letter.

Oh, uhh, yea; me too. (I've already sent in a comment concerning the bizarre process of ANDing 8-bit numbers with 0x3500, but that should be taken as nothing other than a casual result of my reading the mail; I've made no commitments or entered into any sort of contractual agreement.)

I strongly caution IPG against using my name in their advertising.

I am sure that a company with as much Internet savvy as IPG realizes the degree to which using inappropriate attributions like that could backfire, given the propensity of some netizens to defend their reputations through every technological and legal means at their disposal. ______c_____________________________________________________________________ Mike M Nally * Tiv^H^H^H IBM * Austin TX * pain is inevitable m5@tivoli.com * m101@io.com * <URL:http://www.io.com/~m101> * suffering is optional

"Richard J. Coleman" writes:

I'm way out of my league here, but using a small OTP to create a larger OTP seems impossible on information theoretic grounds.

No, you are correct. Perry