[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <66851b766287581e629c5e5f7a9ab374@smtp.hushmail.com>
Date: Fri, 30 Mar 2012 00:37:50 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Collecting same-length passwords
Just thinking loud here:
Some formats benefit a lot from having same-length candidates in a
batch. RAR is an example (having one-length candidates would let us use
SSE2, or it would boost OpenCL and OMP), as is tripcode iirc.
Could we introduce an optional "mode" of operation where the return of
saved_key() indicates whether we are "ready" for a crypt_all() call or
not? As long as set_key() returns false, we just keep calling it with
more candidates. If this is implemented I could have a buffer for each
length. Whenever a buffer get full, set_key() returns true and this
triggers crypt_all.
Or is there a better way?
Maybe for saltless formats this could be implemented in current API...
What if I announce a dummy crypt_all() and always call the real
crypt_all() from within set_key() when appropriate?
Even simpler, I could just use a max_keys_per_crypt that guarantees that
at least one buffer is full. This would work for RAR/SSE2 but for OpenCL
it would mean a lot of buffering, and that has downsides.
magnum
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.
