[RC5] Chance of "the" key being in faulty buffer

Marc Sissom marcus at dfwmm.net
Wed Mar 18 19:16:34 EST 1998

Tony Dillon wrote:
> Martin (format) wrote:
> > Keyspace is split into 56-bit blocks, each block is cleared and made sure that
> > all keys
> > have been checked before the next 56-bit block is started.
> Apologies for being ignorant, but could you please explain what you mean when you
> say
> keyspace is split into "56-bit blocks".

Actually what he wrote is not entirely true. The keyspace is split into
blocks, but we do not sit on one until it is cleared. By 'cleared' it
sounds as if he means "completely checked".

The 64 bit keyspace is broken up into 256 or 2 to the eigth power
major blocks. That leaves 56 bits of space for each major block.
Each is then further subdivided into smaller blocks(28 bits) that
are issued to the clients for processing. We started on major block
64. Whether that's hex or decimal I don't recall or care as it is
irrelevant. We _issued_ all of the smaller blocks in that major block
to the clients and then moved on to the next one, major block 66. The
clients did random work in block 65.

Of all of the sub-blocks issued from major-block 64, some have not
been returned. It is possible that some machines are still working on
old big input buffers and that they will eventually be returned.
Anyway, some time in the future, the servers will be instructed to
re-issue the sub-blocks from M-block 64 so that all of it can even-
tually be checked and logged as such. Then the database containing
the information on which sub-blocks of MB-64 have and have not been
checked can be tossed. These major block databases are rather big,
and it would be unnecessarily expensive to keep them all.

There are at least two bits of data per sub-block that have to be
kept. The info must include at least the minimal state data. That is,
the sub-block is either raw(un-assigned), or it has it been, and it
has been returned as checked or not. This is actually only three
states in bit form: 00 = raw, 01 = issued, 10 = checked and one
state to spare 11 = false positive? Multiply those two bits by 2^28
sub-blocks and divide by eight to get the number of bytes in each
major-block database. At least two, and possibly four, of which must
be online and active at any one time.

In addition to this there is transient data that includes the email
address of the ckecker, the IP, CPU type, OS type, etc. All that
stuff that you see in the stats. I have no idea how long they keep
this data, but I'm sure that they must distill it down periodically.
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