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.