[rc5] Checking for 64 bit RC5 on the fly?

Bob Krzaczek rskpci at cis.rit.edu
Tue Jun 24 14:03:37 EDT 1997


On Mon, 23 Jun 1997, Fedor Kouranov wrote:
> OK, I admit I was hasty. If your reasoning is correct, we won't need to
> alter the clients at all: we'll only have to check the 64-bit problem with
> the 'false alarm' keys padded with a null byte... It will make a 1/256 of
> the 64-bit keyspace, not too bad.

Well, a change in the protocol would still be warranted.  In order to take
advantage of the fact that the key table for RC5-32/12/7 and RC5-32/12/8
looks the same when the most significant byte of the 8 byte contest is
0x00, we'd have to check the plaintext/ciphertext for both contests while
the same key table is set up.  Unless the protocol has provisions for
multiple plaintext and expected ciphertext fields for a given range of
keys, this would be an extension.

But, seriously, with a theoretical slowdown of only 12%, it certainly
seems worth considering if it removes 1/256 of the space to search for
RC5-32/12/8.


> Actually, Bob seems to have discovered a moderate weakness in the RC5. 

<grin> Nahh... I wouldn't call it a weakness.  At worst, you could say
that RC5 has some weak keys.  It's easy enough to circumvent by adding the
rule that the most significant byte of RC5 is never zero (doesn't DES have
a similar rule that no key bytes can be zero?). 

Besides, it wasn't me who discovered it; all I've done is prove Klaus
Espenlaub's conjecture from the other day.  ;-) 


// bob

-- 
// Bob Krzaczek                              <http://www.cis.rit.edu/~rskpci/>
// Center for Imaging Science, RIT                        <rskpci at cis.rit.edu>

----
To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the body.



More information about the rc5 mailing list