[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120115150314.GA13135@openwall.com>
Date: Sun, 15 Jan 2012 19:03:14 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Jumbo future
magnum, Jim, all -
On Sun, Jan 15, 2012 at 01:38:14AM +0100, magnum wrote:
> I am running out of good stuff to do with Jumbo. Help me!
Wow. We certainly have JtR tasks in general, but I am not sure which
ones are to be worked on by you. Let's see...
> We need someone to write intrinsics functions for SHA-256/384/512. Is
> this feasible?
Yes.
Also, I'd seriously consider bitslicing for SHA-512 (and thus also for
SHA-384). We can give both approaches a try (straightforward SIMD vs.
bitsliced SIMD). SHA-512 uses several bit rotates, which become no-ops
with a bitsliced implementation (just use different array element
indices, which in an unrolled loop are constants anyway). However,
there will be more memory (actually cache) accesses with a bitsliced
implementation, and manual carry propagation with addition will have its
performance cost too. So it is non-obvious which approach is better.
Also, some SIMD architectures may lack 64-bit adds (only having up to
32-bit integer vector elements).
Then, there may appear CPUs with true 256-bit AVX, but not yet with
AVX2, which will be a reason to go for bitslicing. This is not the case
currently, though. And it may happen that AVX2 will be available first,
in which case we'll be able to do 256-bit in the straightforward way.
> Is it available somewhere as code we could adopt?
I think not.
OpenSSL appears to make some use of MMX/SSE2 instructions for SHA-512
when running in 32-bit mode, but it only runs one instance of SHA-512 at
a time, so it does not use SIMD for real:
http://cvs.openssl.org/dir?d=openssl/crypto/sha/asm
> I'm just a glue guy, I can't write it. I could make formats use it if I
> had something to work with.
Well, this is not available yet, but meanwhile a related task is to
support DragonFly BSD's ridiculous SHA-256 and SHA-512 based hashes,
without SIMD yet:
http://www.openwall.com/lists/oss-security/2012/01/02/5
This may be needed to make them reconsider sooner rather than later.
My oss-security postings CC'ed to Matt didn't do the trick.
Ideally, one of us should actually install DragonFly BSD and generate
some test vectors on the real thing, for both hash types (although I
think they're only using the SHA-256 based one by default).
Another related task is to have SHA-crypt (glibc's) supported in JtR
directly, not only through the "generic crypt(3)" format and through
Lukas' GPU patches. We can do it without SIMD initially. There are
some optimizations to make even without SIMD.
> Also, we really need to finish the rar format. IMHO it's barely good
> enough to even be included in Jumbo.
You mean that it's limited to -hp archives, not supporting -p ones?
Yes, I'd be happy to see this corrected.
> I have spent days trying to grasp
> what needs to be done but I'm just not the guy. I could not read C++ if
> my life depended on it. Jim, is there some way we could persuade you to
> do this? If you do a third of what you did to zip, it will be a blockbuster.
Yes.
There are other "non-hashes" to support as well: WPA, Mac keychains and
FileVault, PGP secret keys (different kinds), other kinds of SSH private
keys, perhaps many other things.
Several of these use PBKDF2 with SHA*, so it should be possible to reuse
code that Jim and Lukas originally wrote/optimized for MSCash2.
Thanks,
Alexander
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.
