Date: Thu, 9 Jul 2009 10:03:46 +0400 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: JtR-internal crypto APIs (was: "No password hashes loaded" on Ubuntu 9.04) RB - Thank you for addressing Tiago's question on the SHA-based crypt(3) hashes (which are still unsupported, yet are starting to be used by some Linux distros). Now to your question: On Mon, Jun 22, 2009 at 01:28:36PM -0600, RB wrote: > This raises an interesting question: with the proliferation of SHA-based hashes in the past few years, is it time to consider a standardized JtR-internal SHA implementation? I'd say it differently. There are many crypto primitives, which specific ciphers/hashes to be supported by JtR could build upon. Yes, this does mean that there's room for an abstraction layer within JtR - I've been considering introducing more generic separation between the crypto primitives and the ciphers/hashes in a "next generation" version of JtR. Right now, JtR has something like this for DES, where there are traditional and bitslice implementations of modified-DES, and uses of both of these from four different DES-based "formats" - so the crypto primitives are not directly tied into the "formats". But this is just not generic enough. Unfortunately, there's generally a tradeoff between generic code and fast code. A generic implementation of, say, MD4 can't be as fast as one tied right into NTLM code. So I'd expect to have both generic crypto primitives for use by not-so-optimal implementations of higher-level ciphers/hashes, and special-case code (yes, this means duplicate code with only slight revisions in many cases) tied into implementations of specific highly-optimized ciphers/hashes. > Other than reducing external dependencies, would it be worth it? I know OpenSSL has reasonably well optimized implementations for the platforms they're on (if programmatically generated), but don't know how much a hand-optimized solution could improve over them. OpenSSL's routines will generally only process one item at a time, even if the CPU would otherwise be capable of processing multiple items "at a discount". Also, they implement complete crypto primitives, whereas for some higher-level ciphers/hashes partial implementations would suffice. So indeed a "next generation" JtR would need to continue to provide its own crypto code. Alexander -- To unsubscribe, e-mail john-users-unsubscribe@...ts.openwall.com and reply to the automated confirmation request that will be sent to you.
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.