john-users - JtR-internal crypto APIs (was: "No password hashes loaded" on Ubuntu 9.04)

Openwall wordlists collection for password cracking (20+ languages)
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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.