[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 
     transactions.
     
     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 
     sneaker-net activity.
     
     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 
number)
     
     [snip]


--
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest



More information about the rc5 mailing list