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: