[Hardware] The market of ASICs (One GigaKey / Second?)

david fleischer cilantro_il at yahoo.com
Tue Aug 10 01:35:28 EDT 2004


Thanks for the explanation. 

--- Elektron <elektron_rc5 at yahoo.ca> wrote:

> I'm sorry if this is a little spammy.
>  From r72-ref.cpp:
>    s32 rc5_72_unit_func_ansi_ref (RC5_72UnitWork
> *rc5_72unitwork, u32 
> *iterations, void * /*memblk*/);

is there a human-readable description of the header?
exactly how many bytes in each variable, etc...

Also for the return variables, are they ASCII strings?
how many bytes for the number of tested keys...

It's interesting what you say about finding two
positives in the same block. I hope that in the case
of a positive, the team re-tests the whole block.

If RC5 works as advertized, then the text is random.
Looking at the first 8 bytes that are encrypted, and
making the slight simplification that there are only
26 available characters, the probability of finding a
positive (after decryption) is  (1/26)^8. 
After multiplying by the number of keys gives about 2%
per block. The probability of finding two positives is
about 10^(-14), but when multiplied by the number of
blocks gives about 10% probability of finding two
positives in the same block for the whole keyspace.
Not bad, wasting all that electricity for a 10% chance
of missing the key?

> The interface calls rc5_72_unit_func_ansi_ref (or
> any other encryption 
> function thing) with the work unit, the number of
> iterations, and a 
> memory block, which doesn't seem to be used in most
> algorithms. The 
> functions tries the next *iterations keys, and
> if it doesn't find anything, RESULT_FOUND if it
> finds a match (and 
> returns how many keys were a negative result before
> the match). I don't 
> know what happens if there are multiple matches in,
> say, a 4-pipe (or 
> for that matter, a KKS7450)

More information about the Hardware mailing list