[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BANLkTimsHN6PG8+qwpGbzwgQqNCdvoCEZw@mail.gmail.com>
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.
