Negative estimated benchmark time for 1024 bit keys with optimization

[sqlpirate]

I create some 1024 public keys for testing. With the optimization a negative time is calculated. This means (top - start) is negative. Why is this and does this impact a successful attack?

$ python3 optimization.py -j 96 ~/roca/keys/generated-1024.pub [+] Importing key [+] Key is vulnerable [+] RSA-1024 key [+] N = 168624943669182758974280215781456011569038629744526376535337045252130727107381534170843439375955244315238908028241243340891689953428487159534726263781126648823691789933070782777310828563238437149205109600525674261831766067602042561054635704257297596345836435239010691607435325759065388907902349357304317653381 [+] c' = 850102604 [+] Time for 1 coppersmith iteration: 0.02 seconds [+] Estimated (worst case) time needed for the attack: -20801.3 seconds and $ python3 optimization.py -j 96 ~/roca/keys/generated-1024-2.pub [+] Importing key [+] Key is vulnerable [+] RSA-1024 key [+] N = 164120015764097722873438454177657444658349361286249714149317571057211681342705706088083034394301304785150344998122085256288378726566732045477079852530000003998378252495184330586999905751865897641752300811879885650760909043777375010103534231282193794056566679087421654114716835957907434904884516675168844585517 [+] c' = 364568529 [+] c' is odd: we only need to iterate over even a' [+] Time for 1 coppersmith iteration: 0.02 seconds [+] Estimated (worst case) time needed for the attack: -36929.93 seconds

[brunoproduit]

It seems the estimation is broken indeed. This should not change the output and the script should work nonetheless. I'll take a look and fix it whenever I find some time. Might as well just upgrade it to python3