[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
number)

	-----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
"buff-in.des"
	   file with you to work and flush it every day.  (For 10 days,
that
	   shouldn't be a huge headache).  If you pick a 2^28
block-size,
	   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
contest,
	   and let it keep working on RC5.  

	The DES-II contest really needs short block latency in order to
be
	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
block
	latency of as small as one day could kill us by causing oodles
of
	duplicated work.  

	Ironically, according to the simulations I've run, the LIFO
buffer
	arrangement we're using actually helps block latency, and reduce
	duplicate work during the "keyspace thrash" period.  The reason
appears
	to be this:  The blocks at the bottom of the stack get put there
almost
	immediately, when the client does its first fetch.
Subsequently, if
	the client is configured/managed in such a way that it rarely
empties
	its buff-in completely (thus causing the blocks at the bottom to
become
	"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
bottom
	simply never (or extremely rarely) get touched.  Then the
key-server
	reissues these blocks later, and someone else processes them.
	Essentially, the LIFO arrangement causes all buff-in activity to
be
	concentrated on the most recently grabbed (eg. freshest) blocks,
which
	is really what's important in a time-limited contest.


	Regards,

	--Joe

	-- 
	  +------- Joseph Zbiciak ------+
	  |- - - j-zbiciak1 at ti.com - - -|  "The ability to quote is a
serviceable
	  | -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