1995-08-27 - Re: SSL trouble

Header Data

From: Will French <wfrench@interport.net>
To: cypherpunks@toad.com
Message Hash: b045c45628854f84aaef191a1979140634df21cde3e5bd178d3c4b930be3455a
Message ID: <199508270132.VAA05017@interport.net>
Reply To: N/A
UTC Datetime: 1995-08-27 02:16:35 UTC
Raw Date: Sat, 26 Aug 95 19:16:35 PDT

Raw message

From: Will French <wfrench@interport.net>
Date: Sat, 26 Aug 95 19:16:35 PDT
To: cypherpunks@toad.com
Subject: Re: SSL trouble
Message-ID: <199508270132.VAA05017@interport.net>
MIME-Version: 1.0
Content-Type: text/plain




>> Use integrity checks to ensure that the slaves are acting
>> properly. One method of doing this is to keep secret part of
>> the known plaintext (say 16 bits). A slave is required to
>> report _all_ matches in the range to the master. Slaves who
>> report a statistically low number of matches may be
>> considered suspicious. It is a simple matter to allocate part
>> of that keyspace to another processor for a double-check.

>   Please don't do anything like this.  This will prevent
> people like me who prefer the "random" method from
> participating.

> Not true, it would be open for anybody to sweep a random space
> and report the results.

  I don't get it.  If the challenge is partly secret, how will I
know if I crack the code?

> The only difference would be that the sweeper who discovered
> the real key would not be the first to know of a break

  ?  Sorry, the terminology seems to be over my head here.

> and that it would not be possible to attack the crack through
> dishonestly claiming to have swept space that hadn't been.

  That is one reason I like the random method.

> You can't ACK something which has not been allocated to you.

>>  But I could announce it on the list.

  A clarification: my "it" above refers to a successful cracking
of the code.


Will French  <wfrench@interport.net>





Thread