[RC5] Time out and DES-II-2 challenge
gindrup at okway.okstate.edu
gindrup at okway.okstate.edu
Mon Jun 29 16:58:14 EDT 1998
It has been suggested that block sizes be set larger so that the
amount of traffic to/from the keyservers is reduced. To transmit a
2^30 block requires one keyserver transaction (although it might end
up with "change" from a previous request and thus end up with a
smaller block than expected -- this is something else entirely).
Transmitting those keys in 2^28-sized blocks requires up to four
Each block contains a certain number of keys. "Small" blocks
contain 2^28 keys. Larger blocks contain more keys and thus take
longer to crack. A 2^29-sized block contains twice as many keys as
a 2^28-sized block. It takes twice as long to crack, but requires
half as much communication with the keyservers (which is much
quicker unless the keyservers are spammed by *many* small-block
fetches and flushes).
For a while, some of the clients would lose a block if they were
shut down in the middle of one. This may or may not still be the
case. (I haven't checked.) Thus, if you were using smaller blocks,
you lost less work. Similar comments hold if your machine regularly
crashes or you have highly irregular power.
There have been scattered rumors at various times that certain
builds of various clients worked faster on larger blocks than on
smaller blocks. I recall these being routinely debunked, but this
does ont preclude the possibility that *some* optimization is
possible on 2^30-sized blocks that cannot be on 2^29-sized ones.
If you are using a non-mt client then there is only one thread of
execution in the client that is responsible both for
fetching/flushing and for cracking. (Although this could be
overcome through some rather tedious multiprogramming, it is likely
to introduce very difficult to diagnose bugs.) These clients spend
a small percentage of their time doing network things and not doing
cracking things. The mt clients are able to do both at once. Thus,
a non-mt client has better average keyrate on larger blocks, but
only because the percentage of time spent on network things is more
overshadowed by the time spent on cracking. This has been reported
as ~0.1% on many platforms and is thus probably irrelevant.
The same number of keys stored in larger blocks requires less disk
space in buff-* files than if it is broken into multiple smaller
blocks. This might matter for disk caching. It is also possible
that the slightly different timings for various block sizes might
vary memory cache utilization enough to cause detectable variations
in cracking rate although I don't recall any reports to the effect.
Essentially, the only difference is in how long you want your
machine to be cracking. My offline farm tended to have "larger"
blocks so that there would be lots of time between episodes of
This points directly to a critical issue in timed contests.
Latency. For DES-II-2, it is critical that the average latency of a
block be made very low. Since the first reissue is expected at
around the sixth day, keeping any block for six days forces
duplication of effort. Do not select block sizes so large that your
machine will take longer than six days to crack the block. Do not
fetch so many blocks of a size that it will take more than six days
to do them. It is ideal to completely fetch/flush at least once a
day and this requires setting buff-in and block sizes to permit
exhausting the buff-in once per day.
Slow machines should use smaller blocks. Faster machines _can_ use
larger blocks but don't need to. The keyserver network will
probably be full the entire DES-II-2 effort, so keeping block sizes
large will keep network congestion down. Try to minimize your
buff-in size by maximizing your block size (<=2^31) so that you hit
the internet about once per day.
Machines that are always online should set their buffers as small
as possible and their block size as large as feasible to keep
flushing at least once per day.
Hope this helps.
-- Eric Gindrup ! gindrup at Okway.okstate.edu
______________________________ Reply Separator _________________________________
Subject: RE: [RC5] Time out and DES-II-2 challenge
Author: <rc5 at lists.distributed.net> at SMTP
Date: 6/29/98 9:45 AM
If the key could easily be found using the 2^28 keysize then why even
use the 2^30?? Could someone explain the significance of the size of
the exponent (other than ....the bigger the exponent, the bigger the
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest
More information about the rc5