[RC5] Re: Solutions for a faster DES-II-3
jdoire at cslo.consultronics.on.ca
Fri Jul 31 18:55:52 EDT 1998
> > T-1min, the clients stop
> > cracking RC5, and start to ask for the DES encrypted message.
> And what happens? Everyone starts asking for the message at the same
> moment. Result? The servers are completely overloaded(we would have
> what, 30000+ computers trying to get the message simultaneously?) and
> we are looking at a potential crash that would delay us even longer.
> I'm no expert on this, but as far as I know, the way it is now is at
> least the clients aren't all trying to retrieve the blocks at once and
> the servers have a chance of surviving.
I thought of that problem, and took it in account in my proposal:
Having a lot of client trying to get blocks when the contest starts
is already something that is happening, because a lot of people have
done exactly what I have done, which is to stop their client manually
and force a flush to start DES as soon as possible. With the next
contest, many more people will be aware of how critical the start is,
and will force a switch over. So wether the switch is done manually
or automatically it will not change much the issue you raise.
Second, I have proposed to get the blocks well in advanced, and to
get *only* the encrypted message when the contest start. That way,
instead of transmitting N blocks of data, there would be only one
packet of data. So there would be 1/N less traffic, and furthermore,
the packet would be smaller because there would be only the
There is other things that can be done to minimize the traffic like
increasing the number of keyservers, making sure that clients don't
all connect at the same few servers, avoiding flushing the buffer
in the first hour or two (unless the key is found!), turn off the
stats server, etc.
There is one part that I agree with you, is that there might be an
advantage to randomize a bit the time of start, to spread a bit the
number of people who connect at the same time. Having a couple of
full rehearsal before the contest will help to determine how much
spreading is needed. I think something like 30 min should be enough,
which is about sending 1000 encrypted message per minute, a realistic
number I think.
In my proposal, I suggested that the clients would get the DES
blocks at T-12h, which will cause a lot of traffic at that time as
you explained in your message, instead, it would be better to get the
blocks at the same time that the client is informed that the contest
is about to start, which is random, spreading the load.
So the modified script become: At T-24h(variable), the client connect
and is told that the contest starts in 24 hours, retrieves the
initial DES blocks and new RC5 blocks, and continue to work on RC5.
At T+0 to 30min (random 30 min spread), the clients stop cracking
RC5, and start to ask for the DES encrypted message. At T+1h to 2h
(random 1 hour spread), the client it allowed to flush blocks if
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest
More information about the rc5