[rc5] Suggestion for protocol

Honza Pazdziora adelton at informatics.muni.cz
Wed Jun 25 17:05:43 EDT 1997

> > There's a simpler way.  When a client receives a block, it's checking
> > 2^28 different keys.  Instead of doing a checksum on all of that,
> > have it do a checksum every 2^18 keys (for example).  [...]
> One problem with specifying a subset of keys in advance is that the
> attacker could simply check those keys without any others. In this

But there would be no specifying keys in advance. I started this
thread so let me explain again.

Client gets the block, actualy the start and the mask. It divides this
block into 1024 pieces. It will check all keys in the first piece and
make cumulative checksum, for the piece. The result: checksum for the
first piece. Then it will work on the second piece and again make
checksum of its work. And so on. Finally it will have 1024 gchecksums,
one for each piece. The checksum can be 1 byte, or half a byte or just
2 bits long. It send back to server the "not found" message and these
(all) checksums.

The server picks up a number between 0 and 1023, one piece. It makes
the same computation as the client and gets the checksum. If the
checksum is the same as that from the client, the server will believe
that the client has done computation on all of the pieces and accepts
the whole block.

Only 0.1% will be done again.

> case it would be four keys in one million. Anyone want an apparent key
> rate 250,000 times higher than their current one?

Probably did not get the point.

> Personally, I don't think this is a huge concern for RC5 or the v2
> clients. Some attack-resistance will be necessary for v3 though, IMO.

Does it mean that the protocol in the v2 is so strong?

 Honza Pazdziora | adelton at fi.muni.cz | http://www.fi.muni.cz/~adelton/
                   I can take or leave it if I please
		     Thanks for having done your DES.
To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the body.

More information about the rc5 mailing list