Parallelizing

[GoogleCodeExporter]

Is it possible to work in many threads, so speeding up the bruteforce process?

Original issue reported on code.google.com by xpeh.o...@googlemail.com on 2 Jan 2012 at 5:46

[GoogleCodeExporter]

If the router must calculate DH exchange on every request, the speed won't be 
too high, since calculating modular exponentation with 1.5 kbit modulus is too 
heavy work for poor router's CPU that it can calculate tens or hundreds of them 
in a second.

Original comment by xpeh.o...@googlemail.com on 2 Jan 2012 at 6:28

[GoogleCodeExporter]

We've attempted parallel attacks, but we run into two problems:

1) Multiple simultaneous WPS registrars conflict with each other in the AP's 
internal WPS state machine and neither attack gets anywhere.
2) For devices where #1 is not an issue, you still don't get significant speed 
improvements due to the low resources available on the AP.

We are looking at using the improved DH attack that Stefan proposed in his 
paper, which we currently don't implement. This should lower the seconds/pin 
attempt by about .5 to 1 second per attempt.

Original comment by cheff...@tacnetsol.com on 2 Jan 2012 at 1:33

• Changed state: WontFix

[GoogleCodeExporter]

I haven't found how to set issue type so can you set it to enhancement for me?

Do users notify AP speeddown when bruteforce is in action (e.g. the router is  
lagging)?

I wonder how sending low public ephemeral value should significally speed up 
modular exponentation since calculation time mostly depends on modulus length 
and power length. So have you got 50% speedup on your tests?

Is it possible to test several pins after one DH exchange?

Original comment by xpeh.o...@googlemail.com on 3 Jan 2012 at 1:55

[GoogleCodeExporter]

This issue has been closed, as parallelizing is not really a viable method of 
speeding up this attack.

The lockout is done automatically by some APs. Legitimate users should not 
notice any lag, there is actually very little traffic sent between the AP and 
Reaver.

I have not done any tests with Stefan's suggested speed ups, but his code tests 
pins much faster than mine. Here is his explanation: "Speed optimization for DH 
KE: If Alice uses secret '0' A=2^0=1 then Bob (AP) calculates shared Key A^b = 
1^b = 1 -> no sq&multiply needed." Basically he's lowering the amount of math 
the AP has to do since most of them have very limited resources, no MMU, etc.

You can only test one pin after each DH exchange.

Original comment by cheff...@tacnetsol.com on 3 Jan 2012 at 2:37

[GoogleCodeExporter]

Proper issue type should be good even if it's closed.

If there is no lockdown, the bottleneck is AP's CPU and the user can somehow 
notify that CPU load is constantly 100%. Traffic doesnt matter in this case.

Yeah, just forgot about 1. Square/multiply/montgomery reduction will still be 
calculated, but speedup for square & multiply will be (1536/size(int))^2, since 
to multiply 2 big integers you only need multiplying 1 int with 1 int instead 
of amount of ints in modulus with itself. How much faster is his tool against 
your, 50%?

>You can only test one pin after each DH exchange.
This sux :)

Original comment by xpeh.o...@googlemail.com on 3 Jan 2012 at 1:41