[RC5] Time out and DES-II-2 challenge

Steve Bird sbird at UATC.com
Mon Jun 29 10:45:29 EDT 1998

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

	-----Original Message-----
	From:	Joe Zbiciak [SMTP:j-zbiciak1 at ti.com]
	Sent:	Friday, June 26, 1998 11:38 PM
	To:	rc5 at lists.distributed.net
	Subject:	Re: [RC5] Time out and DES-II-2 challenge

	'ALBERTY Pascal' said previously:

	| Imagine now that I do the same with DES-II-2 challenge ?
	| I got several blocks on my very very old and slow computer and
	| (my god !) I got THE key, but my computer take more than
	| 10 days to find it.
	| Is there a solution for slow computer keeping keys to much
time ?

	You could do one of the following:

	-- Buffer the smallest size block, and always take your
	   file with you to work and flush it every day.  (For 10 days,
	   shouldn't be a huge headache).  If you pick a 2^28
	   instead of the default 2^30th, you will receive blocks to
work on in
	   more manageable doses.  Also, you'll want to buffer no more
than you
	   can process in about a day.

	-- Alternately, you could just leave the 486 out of the DES
	   and let it keep working on RC5.  

	The DES-II contest really needs short block latency in order to
	effective, since we will probably start reissuing keyspace
within a few
	(5-6 days) of starting it, if all goes well.  At that point, a
	latency of as small as one day could kill us by causing oodles
	duplicated work.  

	Ironically, according to the simulations I've run, the LIFO
	arrangement we're using actually helps block latency, and reduce
	duplicate work during the "keyspace thrash" period.  The reason
	to be this:  The blocks at the bottom of the stack get put there
	immediately, when the client does its first fetch.
Subsequently, if
	the client is configured/managed in such a way that it rarely
	its buff-in completely (thus causing the blocks at the bottom to
	"stale"), then the likelihood of these blocks ever being
processed is
	fairly low.  What happens, then, is the active portion of
buff-in tends
	to always have "fresh" blocks, and the "stale" blocks at the
	simply never (or extremely rarely) get touched.  Then the
	reissues these blocks later, and someone else processes them.
	Essentially, the LIFO arrangement causes all buff-in activity to
	concentrated on the most recently grabbed (eg. freshest) blocks,
	is really what's important in a time-limited contest.



	  +------- Joseph Zbiciak ------+
	  |- - - j-zbiciak1 at ti.com - - -|  "The ability to quote is a
	  | -Texas Instruments, Dallas- |   substitute for wit."
	  |- - #include <disclaim.h> - -|                  -- W.
Somerset Maugham
	To unsubscribe, send 'unsubscribe rc5' to
majordomo at lists.distributed.net
	rc5-digest subscribers replace rc5 with rc5-digest
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