1995-08-24 - SSL Challenge: some thoughts on the process.

Header Data

From: “Peter Trei” <trei@process.com>
To: cypherpunks@toad.com
Message Hash: f45a349ef60e4e3e4477a72522982398bee3abba125d4b67f9ccba778ea0b495
Message ID: <9508242221.AA18067@toad.com>
Reply To: N/A
UTC Datetime: 1995-08-24 22:21:49 UTC
Raw Date: Thu, 24 Aug 95 15:21:49 PDT

Raw message

From: "Peter Trei" <trei@process.com>
Date: Thu, 24 Aug 95 15:21:49 PDT
To: cypherpunks@toad.com
Subject: SSL Challenge: some thoughts on the process.
Message-ID: <9508242221.AA18067@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


Well, the game's afoot, and I have a few preliminary thoughts on the 
process.

1. We need some protection against massive allocation of keys - perhaps an 
upper limit of a few hundred segments. 

Piete had better be ready to loop the server - at this rate FFFF will be 
allocated sometime tommorrow.

2. It'd be nice if the NT Winsock client could loop, reporting results and 
getting new keys automatically each 
time it finished a block. As it is, it's not worth my running it overnight. 
For each of the P5/90 NT machines I'm using, I'm manually running brutessl 
with enough key to keep them busy till morning. I'd rather have something that 
reported results to the server as it went along.

This is part of a more general problem. A lot of people are doing this on 
standalone machines at work, and have no way of checking them during the
night. This is doubly true for weekends - theretically if someone hits 
jackpot at 6pm on Friday, we might not find out till 9am Monday. I will 
not be running on any work machines over the weekend.

3. Start time was a little ragged - 1800 GMT was named, but the server 
seemed to come up at 2PM east coast time, which is (I think) 1900 GMT. I 
think that if we selected 8AM west coast time (1600 GMT?) more people 
would come online more quickly.

4. There was a massive crush of people trying to get keys from the server 
at 2. If we ever do this again, we might think about preallocating chunks 
of keyspace to people according to their promised cpu power, and keeping
the *challenge* a secret till the starting gun sounds. Passively serving a 
page with the challenge would load the server much less than the cgi-based
key doler.

5. We needed more pre-publicity on the Net to attract participants - a 
week would have been better than 24 hours. 

just some random thoughts....


Peter Trei
Senior Software Engineer
Purveyor Development Team                                
Process Software Corporation
trei@process.com





Thread