[rc5] Checking for 64 bit RC5 on the fly?
ejeffrey at eliot213.wuh.wustl.edu
Mon Jun 23 23:27:53 EDT 1997
>On Mon, 23 Jun 1997, Fedor Kouranov wrote:
>> On 06/23/97 Klaus Espenlaub <kespenla at hydra.informatik.uni-ulm.de> said:
>> >Would it be worth the time doing another decryption and check for the
>> >other pattern as well? The drawback is obvious: some loss of speed, but
>> >[ ... ]
>> For each 56-bit key 0xFFFFFFFFFFFFFF check a 64-bit 0x00FFFFFFFFFFFFFF?
>> This will *double* the work. Hey, we want to crack it in this millenium!
>Not necessarily :) Just assume for the moment the expanded key table
>would be the same in the above case. Then, the decision to check both
>problem spaces depends on how much of your time is spent generating the
>expanded key table and how much is encrypting the block of known
>plaintext. If we were to naively assume a 50/50 split (hey, I said this
>was naive), we would incur a slowdown of 50%. No joy.
>But if we count only the computational operations present in the 12 round
>algorithm (disregarding things like array lookups), we find only 80
>operations in the encryption phase compared to 546 operations in the key
>mixing phase. Adding a second set of encryptions would only incur a
>slowdown of only about 12%. Joy! ;-)
>So, what about those identical expanded key tables...?
Take this a step further: you don't need to do a second encryption. Think
about it for a minute: *all 13* contests have the same initial string:
"The secret message is:". So, the only penalty we have is the added
comparison between our obtained cyphertext and the RSA cyphertext for the 64
bit key. Double joy.
erjeffre at artsci.wustl.edu
Let us go. Let us leave this festering hell hole. Let us think the
unthinkable, let us do the undoable. Let us prepare to grapple with the
ineffable itself, and see if we may not eff it after all.
To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the body.
More information about the rc5