1996-10-18 - Re: POTP critques?

Header Data

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)

Raw message

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.





Thread