Re: Internet Privacy Guaranteed ad (POTP Jr.)

[IPG Sales <ipgsales@cyberstation.net>]

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: