An acquaintence of mine works at a firm with little cryptography experience. They are thinking of including cryptography in a future product, and Elementrix's Power One Time Pad is a serious contestant. I'm looking for independent critiques of the system, something better than 'it's not really a one-time pad.' Is the cryptosystem which is actually implemented worth a damn? Does their claim to have solved the key distribution problem hold water? I seem to remember something about them wanting to generate keys for you, and ship them to the customer. Is this correct? Peter Trei trei@process.com Peter Trei Senior Software Engineer Purveyor Development Team Process Software Corporation http://www.process.com trei@process.com
Peter Trei <trei@process.com> wrote:
An acquaintence of mine works at a firm with little cryptography experience. They are thinking of including cryptography in a future product, and Elementrix's Power One Time Pad is a serious contestant.
I'm looking for independent critiques of the system, something better than 'it's not really a one-time pad.' Is the cryptosystem which is actually implemented worth a damn? Does their claim to have solved the key distribution problem hold water? I seem to remember something about them wanting to generate keys for you, and ship them to the customer. Is this correct?
Not quite. What the program actually does is the first time you send a message, it generates an initial key and sends the key - in plaintext - to the recipient. Then the first message is encrypted with this key. So the system initially has absolutely no security at all. The second message sent is encrypted with a hash of the first message as a key. The third message is encrypted using a hash of the second message, and so forth. So each time you send a new message, you in effect send a new key, encrypted with the old key. Their theory is that if the eavesdropper misses a message, then he loses the key, and can't decrypt the messages anymore. Of course, if the intended recipient loses a message then he loses the key for subsequent messages too. Thus we have a nice little denial-of-service attack. They prevent this via a "emeregency resynchronization" procedure (which they seem quite proud of, and their web pages congratulate themselves repeatedy on the purported cleverness of this). Of course, this "resnchronization" is based upon a pre-arranged key, which the eavesdropper should already have, if he's been decrypting their mail. Even better, the attacker can synchronize with one or both parties, performing a man-in-the-middle attack and/or spoofing them. So basically the system will stand up to a passive sniffing attack only if the eavesdropper is clumsy and loses messages, and doesn't stand up to a denial-of-service or man-in-the-middle attack at all. And I haven't even considered implementation bugs yet.
-----BEGIN PGP SIGNED MESSAGE----- On Fri, 18 Oct 1996, Peter Trei wrote:
I'm looking for independent critiques of the system, something better than 'it's not really a one-time pad.' Is the cryptosystem which is actually implemented worth a damn? Does their claim to have solved the key distribution problem hold water? I seem to remember something about them wanting to generate keys for you, and ship them to the customer. Is this correct?
POTP is a stream cipher where the key is derived from a "state" and bits from the ciphertext chosen using the current state. Two machines have to synchronize their states before encryption can take place. The key is derived from a one-way function performed on the state. This really doesn't solve the key distribution problem because initial synchronization has to take place on a secure channel. The current state also has to be saved on each machine. I think the "escrow" system you are referring to is some other encryption program. Elementrix does acknowledge that they have a stream cipher and don't refer to it as a one-time pad. The only reason OTP is in the name is that the key derived from the state is as long as the ciphertext being encrypted. They claim that the state is larger than the key and it is computationally infeasible to derive the state given the key. I would guess that the size of the next state is determined by the size of the plaintext to be encrypted. As for security of the system, I really don't know. Their algorithm is proprietary so I would avoid it for that reason alone. They have not yet gotten any comments regarding security from any cryptographers. The entire security of this system is based upon the algorithm used to generate the state from a previous state and the one-way function used to generate the session key. Unless they are using a hash algorithm like SHA-1 to generate the keys and states, I would seriously question the security of it. Mark - -- finger -l for PGP key PGP encrypted mail prefered. -----BEGIN PGP SIGNATURE----- Version: 2.6.3 Charset: noconv iQEVAwUBMmfs0CzIPc7jvyFpAQE1QAf9HA/jpe2YZZbKrMjozlNVSqY8pbT4spUf vdLOkk6DjaKCFPdLdy23SpmlJSqjNVw5rzGV+GwLTESCwxmP3l7foEQ022Zji3of ly3grbq+3kIOL13cqBFZwYz2nrSmJJggNo+FdxjWlSJagoPZjAhO94+h0EFwTKXs fahlaQ27om02TWhUHVZxBQ1pKAoB+PFxuzkxAu6zX0fOj9ZG/bZGZ4HbV4UxUl9h O0VNuyAjCeGVwOZ+GvTs5G5h4EBRGrgHusRNAlLhSnsfFjaM3pYu1ZI5123VKQLC By30qqSjfjKNizLBTZnNIVvmI12TIKvWvEPmihn8atowvVJ4TcbKYw== =hgmm -----END PGP SIGNATURE-----
participants (3)
-
Mark M. -
nobody＠replay.com -
Peter Trei