I take back my statement, with the fixed code, altivec is about 2.5 x
as fast. I will be committing the fix shortly, thanks for looking.
Intel will default to the non accelerated code until we can find
replacements for vec_step and vec_rl. It seems the ppc is better for
rc5 type cracking because it has hardware rotate that the intel does
P.S. Do you know of a good password dictionary?
On Mar 2, 2006, at 2:46 PM, Erik Winkler wrote:
In the past, the altivec code was much faster when comparing a G3 to a G4 of similar speeds.
On Mar 2, 2006, at 4:23 PM, Geoffrey Kruse wrote:
On Mar 2, 2006, at 2:07 PM, Erik Winkler wrote:
Found the WPA problem. I replaced all occurrences of vL128Rotate with vec_rl in the file WaveNetWPACrackAltivec.m. Not sure why you were using vL128Rotate.
I will take a look... I was using vL128Rotate because there is vec_rl is not defined for i386;
My initial benchmarking also shows that the non altivec version is faster, but I'll get back to you on that.
WPA Crack works fine now.
Erik On Mar 2, 2006, at 10:20 AM, Geoffrey Kruse wrote:
On Mar 2, 2006, at 5:46 AM, Erik Winkler wrote:
The build is flawless now. That did the trick. WPA cracking still broken. May want to look at any changes made to the WPA code to make it i386 compatible. I will compare an older version of the WPA code to the new code when I get a chance.
The code is i386 compatible, its just not executed on i386 because of a check for alttvec before the code is called. What I need to debug: A dump with a WPA net that can be cracked using r90 or earlier but fails with the new code. The only dump I have at the moment does not crack using r90 or earlier. This vectorized code is pretty far outside my understanding, I directly translated it function call for function call. If you get a chance take a look at Crypto/WaveNetWPACrackAltivec.m. The other alternative would be to #ifdef out all of the code for i386 and change it back to the way it was. This would however leave us without an mmx / sse version of this crack.