[RC5] Solutions for a faster DES-II-3

gindrup at okway.okstate.edu gindrup at okway.okstate.edu
Fri Jul 31 11:22:27 EDT 1998


     I like the idea of prefetching the blocks.  However, individual 
     fetches of the ciphertext are going to have the same problem that 
     fetching blocks has.
     
     Instead, have the proxy network multicast the ciphertext to all IP 
     addresses that requested prefetch blocks.
     
     Clients that do not receive the ciphertext block should perform 
     *forward* encryptions of the known plaintext with the blocks they 
     have and return those to a special proxy/server that will compare 
     the returned blocks with the known ciphertext *and* send the 
     ciphertext to the reporting client.
     
     This could even be started *before* the contest by, say, half of an 
     hour.  Sort the ciphertexts and don't return anything until the 
     ciphertext *should* have been received.  It takes 4 GB to store one 
     2^28-sized block; doing much of this is unreasonable.
     
     Also, since there is no reason to allow off-line clients on DES-II 
     contests any more, hardwire the DES buffer sizes to 1:1.
     
     Hmm...  The time-to-start allows quick conversion of machines that 
     are connecting semi-regularly.  Pre-fetching allows machines to 
     crack a block before/as the contest starts and have blocks already 
     when the contest starts  Broadcasting the ciphertext allows the 
     server to control its load *and* only sends the message to clients 
     that are probably still on.  (It's been less than 0.5 hour.)
            -- Eric Gindrup ! gindrup at Okway.okstate.edu


______________________________ Reply Separator _________________________________
Subject: [RC5] Solutions for a faster DES-II-3 
Author:  <rc5 at lists.distributed.net> at SMTP
Date:    7/30/98 11:00 AM


     [snip]
There two main obstacles for starting faster: 1) client start 
cracking only after connecting to the server and get the signal that 
the contest has started. 2) it takes hours to retrieve the first 
blocks to crack, because the key server is overloaded.
     
1) The first problem can be easily resolved by adding a timer into 
the client. When a client connect to a server, on top of getting 
blocks, they could get the time when the contest starts. If it is 
within 24 hours, let's say, the client would start a timer, and when 
the time come, would stop cracking RC5, and start to retrieve blocks 
for the DES contest.
     
2) The second problem is caused by the heavy traffic when the contest 
start, and to speed up the start, the traffic have to be reduced to 
the minimum. This can be achieved by separating the encrypted message 
from the blocks, and by sending the blocks well in advance and by 
sending the encrypted message only once, when the contest starts.
     [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