[RC5] Strange Mathematics ?!

rc5 at xfiles.nildram.co.uk rc5 at xfiles.nildram.co.uk
Mon Jan 25 18:46:39 EST 1999

> Hi,

> I just realized I miscalculated my DES buffer size, and loaded twice the
> amount of neccessary blocks because there seems to be a bug in the
> calculation of the DES keyrate:

There isn't a bug, the reported keyrate is correct (see below)
> >From my logfile:
> ...
> [Jan 19 20:53:33 UTC] Completed one DES block 00253681:B0000000 (4*2^28
> keys)
>                       0.01:02:16.25 - [574,769.79 keys/sec]
> ...
> [Jan 19 21:55:52 UTC] Completed one DES block 0025367D:40000000 (4*2^28
> keys)
>                       0.01:02:19.28 - [574,304.04 keys/sec]
> ...
> 4*2^28 keys / 1:02 hours
> =1073741824 keys / 3720 s
> =288640 keys/s
> This is only the half rate from above!

Thanks to a nice little 'feature' of DES, it is *very* easy to crack
two keys at once.  Each time the client cracks a key it also cracks the
'complimentary' key at the same time.  Every time your client does a
2^28 block it cracks 2^29 keys.

> (my computer is a single P120, the client (432 win32 gui) runs only one
> thread, the time measured for completion of a 2^30 keys block is correct and
> all blocks were processed without a restart)

Sounds roughly correct..
> I get keyrates around 570 kkeys/s DES when benchmarking with both CLI and
> GUI since version 417.
> This looks very strange to me!
> So I did some further calculations:
> - RC5 keyrate (in the client/logfile) is OK
> - The keyrate shown in my RC5 statistics as Overall Rate cannot be
> recalculated as
> ("Total blocks checked" * 2^28) / ("Working time" * 24 *60^2)
> I get a smaller value.
> Could someone explain this, please?

Hrm, not sure, maybe Nugget knows... Is it a big difference?
> Another Topic: Recycling of RC5 blocks
> =============================
> How long approximately can I keep a RC5 block before it gets recycled? I've
> got some friends without internet access and I want to exchange buffer files
> on disks. But I want to do this only once per week or better once in two
> weeks or a month. It will get annoying otherwise. Will these blocks have
> been recycled when I get them back for flushing, so the work was probably
> useless?

At one point you would have been nearing the limit with a month, but now
you should be safe with well over a month, because the keymaster has more
HD space to keep lots of open 2^56 subspaces.
> Doing these exchanges I found a nice way to update not yet empty buffers
> using checkpointfiles ("ckpoint"):
> (I'm using the WIN32 client 432)
> 1. stop the client
> 2. rename buff-in.rc5 to ckpoint
> 3. copy the new buffer buff-in.rc5 into the client directory
> 4. restart the client
> The remaining blocks will be "recovered" and pushed at the end of
> buff-in.rc5, so they will be processed before any of the new blocks.
> This might be optimized using a batchfile and the CLI client and some
> command line parameters for the checkpointfile, I think.
> Furthermore I use this once a week to process all the blocks in my incoming
> buffer, so they won't get too old. I'm using lurking (lurkonly) and dial-up
> access - this keeps the buffer usually filled and lets it never get really
> empty. Because the buffers are stacks the first pushed blocks would wait
> very long before being processed. After "recovering" the old buffer all old
> blocks will be processed before a fetch occures.
> This might be an idea for people who asked about using queues for the buffer
> files on this list.
> In my opinion queues will be more difficult to handle in files because when
> appending/deleting at the beginning of a file you must completely rewrite it
> instead of appending at the end/truncating when using a stack-file.

I understand the difficulty in it, and it would take a lot of effort, with
a questionable amount of return, but I think that it is definately a
required feature for v3 :)

> WOW! We got DES-III ! Congrats distributed.net!

Yay!  I just got back from a ski-trip and discovered that:

	a) My computer managed to stay up and actually take part on

	b) We did it in under 24 hours!
> Andreas

David Taylor
E-Mail:	dtaylor at nildram.co.uk.spam
ICQ:	268004
[Remove .spam from e-mail to reply]

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