1996-02-20 - Re: Internet Privacy Guaranteed ad (POTP Jr.)

Header Data

From: IPG Sales <ipgsales@cyberstation.net>
To: “Daniel R. Oelke” <droelke@rdxsunhost.aud.alcatel.com>
Message Hash: 79b17d51352f2215e71dc5f5f87dd64acb2b72fb7bbe7a1ae281f6028a7dde52
Message ID: <Pine.BSD/.3.91.960219183616.5326D-100000@citrine.cyberstation.net>
Reply To: <9602200007.AA09268@spirit.aud.alcatel.com>
UTC Datetime: 1996-02-20 03:20:43 UTC
Raw Date: Tue, 20 Feb 1996 11:20:43 +0800

Raw message

From: IPG Sales <ipgsales@cyberstation.net>
Date: Tue, 20 Feb 1996 11:20:43 +0800
To: "Daniel R. Oelke" <droelke@rdxsunhost.aud.alcatel.com>
Subject: Re: Internet Privacy Guaranteed ad (POTP Jr.)
In-Reply-To: <9602200007.AA09268@spirit.aud.alcatel.com>
Message-ID: <Pine.BSD/.3.91.960219183616.5326D-100000@citrine.cyberstation.net>
MIME-Version: 1.0
Content-Type: text/plain

On Mon, 19 Feb 1996, Daniel R. Oelke wrote:

> > From owner-cypherpunks@toad.com  Mon Feb 19 17:50:19 1996
> > Date: Mon, 19 Feb 1996 17:17:52 -0600 (CST)
> > From: IPG Sales <ipgsales@cyberstation.net>
> > We are not currently revealing all the details of our system because of 
> > patents in process, and other relat6ed matters. We are offering the 
> > software. You should be able to readily decompile it and determine the 
> > algorithms used andf how they are used to generate random number sequences 
> > for very long files.  For short messages, a true OTP is used directly. 
> Marketing Fluff - read "we don't *want* to revel it".  Patent stuff doesn't
> take long to get the initial disclosures filed.  Cypherpunks are 
> generally engineers and are immune to such crap.  

You must also then know that you do not always get what you want with a 
pent - sometimes you do not get anything, or not enough to cover you. 
Until we know, we are reating much of the material as trade secrets, as 
we are sure you would also do. Once, you discover how simple the system 
is to install, use, update, and add to, you will understand our concern.

> > If you are aware of encrtypting technology, you recognize that hardware 
> > prime number cycle wheels for the basis of some of the most secured 
> > hardware systems employed for encryption. We simply expand that technogy 
> > using software to set an intial setting, an adder, and a limit for 64 
> > such wheels, using large random prime numbers for each of those settings. 
> > The total number of possibilities is over 10 to the 1690th power and can 
> > be much larger. 
> So.  Large "random" prime numbers are generated.  From what?  How?
> Obviously these act as keys to your "OTP".  Figure out how to 
> match this prime and you can generate the same "OTP".
The hardware  OTP is used as a template to 

> > Thus we can eliminate the need to have the length of the OTP to be equal 
> > to the length of the file - if you do not belive that it works, try it 
> > and see - it takes inly a few hours to set such a trial up. We generated 
> > over 790 gigabytes of charcaters, on multiple backups, and tested. Our 
> > standard deviations, chi squares, Delta ICs for bits, characters, sets, 
> > and the entire set were random. The sets are random, and you can take 
> > that to the bank. 
> So the data coming out appears random.  Big whoopie.  Lots of algorithms
> can generate the same thing.

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. 

> The key is how do you seed that random number generator? 
As explained above

> This isn't even close to being a OTP.  A OTP by definition has a random
> set of data that is transmitted to the receipient over a seperate
> secure channel from the actual message to be sent.  The actual message
> and the OTP are XOR'ed together and sent.  The receipient then XORs
> the OTP and the encrypted message to get plaintext.
> That is pretty simple - even a marketing drone should be able to figure
> that one out.
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 
is simple to break RSA systems, but factoring a 2048 bit number, or 4096 
number, or whatever, makes the problem enormous  - our system for large 
messages/files is similiar in difficult except that it is much nearer 
an 8192 bit number than 2048. The possibilities to be examined ar4e so 
large, that iot is not possible to solve then with a computer, even if 
all the particles in the iuniverse, all 10 to the 80 power of then were 
a Cray T3E, or better.  Furthermore, all you would get would be all the 
possiblilities which would be everything!

> Now - explain how (in generic terms) your system acts as a OTP.
I believe that you have some basic grasp of OTPs, but obviously you do 
not understand how the Golden Gate Bride Cable was strung: A 
string, a rope, a small steel cable, all of the cables - we employ a 
similar technique to fdeliver the follow on OTPs. 
> > Someone, will decompile it and discover that it is truly random, at least 
> > from the practical usage basis. But we need that time to file patents, 
> > cvopyrights and the like. 
> Yes - hopefully someone will take the time and money to decompile it.
> .... but if you are so sure of yourself,
> why not give away some demo copies.  Why not source of the security
> functions?  (Shove that patent crap someplace - you wouldn't be 
> selling it if your disclosures weren't already filed)
> > The IPG system solves the key management problem and produces a truly 
> > unbreakabkle system. We make no apologies for not currently revealing all 
> > of the methodologies andf algorithms, but they will be revealed with 
> > time, by us or others, and you will discover that it is indeed a simple, 
> > easy to use, easy to install, truly unbreakable system.
> "unbreakable" - Bullshit - you obviously don't know crap.
Time will prove one of us wrong, and that wiill prove to be you - it is 
unbreakable as a thoprough examination of the literature will reveal.
 > Dan
> ------------------------------------------------------------------
> Dan Oelke                                  Alcatel Network Systems
> droelke@aud.alcatel.com                             Richardson, TX