[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20071112033319.GA14532@openwall.com>
Date: Mon, 12 Nov 2007 06:33:19 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: bitslice implementation of ORACLE hash cracking
On Sun, Nov 11, 2007 at 07:38:02PM +0000, Larry Bonner wrote:
> the algorithm (after looking at Simon Marechal's patch) is roughly..
BTW, Simon, I don't recall - is there a reason why this stuff is not in
the jumbo patch? Would you submit a patch suitable for merging into the
jumbo patch?
> where input buffer is $USER || $PASS in unicode format.
...
> the number of block encryptions increases as the plaintext ($USER +
> $PASS) get longer..so based on your comments, it appears bitslice
> would provide little or no advantage over normal code?
Not exactly. I am aware of two possible approaches:
1. Group {username, candidate password} combinations by the required
number of DES block encryptions and try those separately - maybe even in
separate invocations of JtR. For example, an instance of JtR could be
invoked on usernames of length 4 only, and it would try passwords of
lengths 1 to 4 only. Another instance would try passwords of lengths
5 to 8 for the same usernames. (These numbers are based on your
description above, which I did not verify against the code.)
2. Introduce an extra layer into JtR, which would buffer larger numbers
of candidate passwords or maybe of DES block encryption "requests", then
proceed with the actual bitslice DES encryptions whenever there's an
optimal number of outstanding requests.
Both of these approaches are primarily associated with extra complexity.
The first approach has no performance impact compared to bitslice
implementations of DES-based hashes currently in JtR. The second
approach will have a performance impact, but should nevertheless provide
a performance improvement over a non-bitslice implementation (except on
some CPUs where bitslice implementations are not efficient at all).
> > As to SHA-1 (as well as MD4 and MD5, for that matter), bitslice
> > implementations are possible,
>
> have you got or know of any code that demonstrates it? to play around with.
I will post my bitslice MD5 code in a separate message.
--
Alexander Peslyak <solar at openwall.com>
GPG key ID: 5B341F15 fp: B3FB 63F4 D7A3 BCCC 6F6E FC55 A2FC 027C 5B34 1F15
http://www.openwall.com - bringing security into open computing environments
--
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.
