1995-08-30 - Re: SSL stuff

Header Data

From: don@cs.byu.edu
To: cypherpunks@toad.com
Message Hash: 3f5045c6e75556a06b3d482f9ae0657dd066f86dd500d23691dbc8c6297ac512
Message ID: <199508300653.AAA02079@wero>
Reply To: N/A
UTC Datetime: 1995-08-30 06:54:30 UTC
Raw Date: Tue, 29 Aug 95 23:54:30 PDT

Raw message

From: don@cs.byu.edu
Date: Tue, 29 Aug 95 23:54:30 PDT
To: cypherpunks@toad.com
Subject: Re: SSL stuff
Message-ID: <199508300653.AAA02079@wero>
MIME-Version: 1.0
Content-Type: text/plain


-----BEGIN PGP SIGNED MESSAGE-----

Piete: please read the PS at the bottom

From: Scott Brickner <sjb@austin.ibm.com>

>>A random (instead
>>of sequential) allocation _by the keyserver_ (out of unallocated 
>>piecemeal segments) would also take some work to implement. 
[snip]
>The problem is that it's irrelevant to the problem.  Random allocation
>at the server is equivalent to simply "shuffling" the segments before
>assignment, which doesn't affect the rate at which the space is searched.

no, but it keeps someone from knowing where the key is at from grabbing
it for themselves. If the segments were shuffled, the only way to ensure
"getting" the keyspace with the key is to grab HUGE chunks. And grabbing
50,000 segments didn't go over well last time, did it...


>I'm not sure I follow you, here.  The search wraps around on the unACKed
>segments because the work was assigned, but not (as far as the server
>knows) completed.  This doesn't slow down the discovery of the key,

If the segment with the real key is the first assigned and the last ACKed
(reporting key found), the search went on 30 hours extra. But that doesn't
cause as much problems as a (false) ACK of no key found. 

>>It would be nice to be able to hit the emergency button and switch to
>>random mode, but currently I don't think there's a need to actually
>>use it.

>I still don't see how the server can use unsolicited NAKs as anything
>other than a nominal reduction in the probability that the key is in
>the NAKed segment.  Perhaps this does give an idea of a server strategy
>to do *just* that, though.

I mean a setup where if the key server is shut down by a D.O.S. attack,
or congestion, or whatever, that the users, if they so desire, can shift
into random mode and end their dependance on the server. I don't see
a need for all of us to be doing random searches right now just because
someone _might_ launch a D.O.S. attack. Another benefit of random mode
being implemented, but secondary, is that all of the people who previously
had to manually get keyspace by WWW and report it back by hand - they
can just put it in random mode and fire-and-forget, just like everyone
with brloop does. 

Don

PS: Piete: What's the current status of the server? I've got by brloop
working apparently, and I calculate I'm able to search 800 segments a day,
and I'm anxious to see if it works. It's stopped giving me only sleep
orders, and now appears to give me a keyspace, but it reports a checksum
error and sleeps for a few minutes. 

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQB1AwUBMEQKzsLa+QKZS485AQEjjgL/X2jQ0J0k+0gc4GUOzNQrKKtRHvqy4dlq
FmxaGDsdnBI+eO8DSu8C6jmRdw+VpcRiFQGDiTMklSmKNEwEqwq0QIvL0Dh4mz7k
vTsYXbUdlGwf9KUJv5PtwNojP+nQl9Pe
=tTkz
-----END PGP SIGNATURE-----





Thread