Date: Wed, 8 Jun 2011 05:05:09 +0200 From: Łukasz Odzioba <lukas.odzioba@...il.com> To: john-dev@...ts.openwall.com Subject: Re: Lukas's Status Report - #4 of 15 >> In the meantime I found cpu implementation called "fast md5-crypt" and > > Can you please post an URL for it (or otherwise share it with us)? > A Google web search for "fast md5-crypt" doesn't appear to find it. My fault, it was ultra fast crypt(3) i sugested md5 because files was in the same directory as md5-based crypt. ufc-crypt is des based so it wont help. http://ftp.sunet.se/pub/security/tools/password/ufc-crypt/ufc-crypt.tar.gz > You mean to the one in JtR? BTW, bartavelle's code in 1.7.7-jumbo-5 > introduces a SIMD implementation. I meant that, which is my base, which I dont like for the same reason as sha256-based crypt version. http://www.opensource.apple.com/source/tcl/tcl-87/tcl_ext/trf/trf/md5-crypt/md5-crypt.c > > Also, since the overall structure of SHA-crypt was based on MD5-crypt's, > you may be able to reuse some approaches for SHA-crypt. I am counting on that. > OK. Obviously, the bottleneck for fast hashes like this is different. Good point, for slow hashes results should be better, but it's still far away from needed 200-300% speedup. >> Surprisingly I didn't stated any difference in coalescing operations >> inside kernel. Assuming that kernel: reads password compute hash write hash to memory I didn't noticed any difference in coalescing r/w operations while computing hash. It is at least sizeof(64*uint) bytes so it cannot been hidden in 18 registers used by whole kernel.
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.