[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20090709060346.GA26462@openwall.com>
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.
