From: nobody@replay.com (Anonymous)
To: cypherpunks@toad.com
Message Hash: 3c74ca59523e98d6a9b477f26494ccacb74016950f86b1799e4b704e5c8ecdbc
Message ID: <199610182035.WAA01710@basement.replay.com>
Reply To: <199610181356.GAA10935@toad.com>
UTC Datetime: 1996-10-18 20:35:47 UTC
Raw Date: Fri, 18 Oct 1996 13:35:47 -0700 (PDT)
From: nobody@replay.com (Anonymous)
Date: Fri, 18 Oct 1996 13:35:47 -0700 (PDT)
To: cypherpunks@toad.com
Subject: Re: POTP critques?
In-Reply-To: <199610181356.GAA10935@toad.com>
Message-ID: <199610182035.WAA01710@basement.replay.com>
MIME-Version: 1.0
Content-Type: text/plain
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.
Return to October 1996
Return to ““Peter Trei” <trei@process.com>”