![]() |
|
|
|
#1
|
|||
|
|||
|
I am facing a 64-bit secure key, it seems too hard by just simply searching the whole key space
![]() A general estimation - if a machine has the power to compare the lower 32-bit part per second, the higher 32-bit part cycle would cost near 140 years ![]() If there are 140 or more such powerful boxes, the task may be done in a year, with proper task schedule, etc ... I am wondering if there is anybody willing to help. Last edited by shyokou; 05-14-2004 at 13:19. |
|
#2
|
|||
|
|||
|
Processing 32 bits in a second? Suppose you have 2 x 2GHz CPU (i.e. a 4GHz CPU equivalent)... that means your algorithm checks one possible key within one CPU tick. I wonder what algorithm could it be?
|
|
#3
|
|||
|
|||
|
Ideal estimation only
You are more than a hundred percent correct in the real world. At that night, I just finished the crash-recovery part of the key searcher, and tested it on an SGI box using 64-bit counter. Though the speed was in fact far from 32-bit per second, I just dreamed how it was possible if something somewhere somehow. The key algorithm is the popular SHA series, which costs much more than MD series, let alone XOR ...
Quote:
|
|
#4
|
|||
|
|||
|
if you make an elegent distributed solotion i can run it 24 hours per week (all the time i get in the lab sad too say) on around 30 uni boxs...
must be elegent, hiden, and not needing admin privlidges... you were asking for computing power help right? my mistake if i miss under stood |
|
#5
|
|||
|
|||
|
Thank you very much for your kind concern. As you may see, key crack/search has become one of the most narrow bottle-necks in making an elegant keygen. Of course, there are people prefer patches rather than keygen; regretfully to say that I am not one of them
![]() Quote:
Thanks again
|
![]() |
| Thread Tools | |
| Display Modes | |
|
|