[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 9 Jun 2008 19:44:15 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: long passwords, parallel processing, x86 extensions beyond SSE2 (was: How to chose computer for John?)
Sebastian - you've raised so many distinct topics at once that it's
difficult to reply to your message, yet keep my response non-confusing.
But I'll try.
On Sun, Jun 08, 2008 at 08:23:07PM +0200, sebastian.rother@...erlin.de wrote:
> The problem I see so far is not checking Passwords up to 8 charackters.
> In fact attackers do check other passwords (10+) already. Not with john or
> maybe with some modified john but just checking up to 8 charackters is,
> for me personaly, no real "goal" if I do a real password check on a
> importent system.
As you should be well aware from past discussions on this list, it's
only "incremental" mode that has the 8 characters limitation by default,
Other modes do not have the limitation, and I had explained how to
adjust params.h to raise the limit for "incremental" mode as well:
http://www.openwall.com/lists/john-users/2007/07/04/6
I understand and agree that JtR should eventually be enhanced to not
require a recompile for this.
> At such systems I check passwords up to 10 charackters
> and here's the problem I see if I would use your method.
>
> I would not be able to splitt my sessions like you descriped because
> I may just would check for 9 and 10 charackters because anything else, up
> to 8 charackters is propably not even allowed at such a system or gets
> checked during regulary weekly checks anyway.
You're almost definitely wrong about this. In my experience, such
strict password policies are extremely uncommon, and quite often some
passwords slip by the policy anyway (there's often more than one way to
set or change a password). So by not checking for shorter passwords,
you effectively leave the weakest ones to be discovered by others.
With JtR rebuilt to support lengths 9 and 10 with "incremental" mode,
you could have your four CPU cores do lengths 0-7, 8, 9, and 10,
respectively, and none of these sessions would terminate. If you really
don't want to be testing lengths up to 8, inclusive, you can run two
wordlist-based sessions with two huge rulesets - after you're done with
the usual stuff ("single crack", default wordlist ruleset) - or go for
lengths 11 and 12.
> > There are third-party parallel processing patches for JtR, and many
> > of those are available here:
> >
> > ftp://ftp.openwall.com/pub/projects/john/contrib/parallel/
>
> The problem I see is that most patches may do lack interportability checks.
Yes, the patches might not be as portable as JtR itself is.
> > Also, I am indeed supposed to implement this enhancement to JtR in an
> > "official" fashion, but I haven't gotten around to doing it for 11 years
> > now (it was first planned and I had draft code working in 1997).
>
> You mentioned this already more then once. :-D
> The problem I see here is that you do not want to include 3rd party code to
> enhance john. At least you do not merge the changes to the official JtR.
> But I also does not see a paper where you descripe how it "could get done"
> so that maybe developers with some spare time implement your idea.
You're right, there's no such paper. However, I've been explaining
things via private e-mail before starting this mailing list, and then I
also provided some brief explanations in here - they're in the archives.
Some of the parallel processing patches that I have in the FTP archive
above have been "affected" by my explanations.
However, experience so far tells me that the most straightforward way to
have an implementation suitable for inclusion in the official JtR is to
make it myself - and this is fine.
> Waiting another century propably isn't an option for you as well but I
> understand also that you do this at your free time so it's no major thing
> for you maybe. I hope my critic was political but if you don't do it, and
> if you do not accept any other solution getting merged to your official
> code then I seriously have no clue how this functionality ever gets added.
You're right. It might or might not get added, depending on whether I
work on it or not.
> I'd provide you as much Vodka as you can drink if we meet if you implement
> such a functionality. If that doesn't make you horny for coding I don't
> know what else would. Maybe beer? ;-]
It's neither. Sorry. Thanks for the offer, though. ;-)
> http://en.wikipedia.org/wiki/SSE4
> http://en.wikipedia.org/wiki/Advanced_Vector_Extensions
> http://en.wikipedia.org/wiki/SSE5
Thanks. SSE4 is rather minor. While some of the instructions might be
of use in specific places in JtR, there's no significant overall speedup
to expect for any hash type.
AMD's SSE5 and Intel's AVX are very promising (and they appear to be
distinct things, with only some similarities). 3-operand instructions
should help reduce the number of instructions for DES S-boxes by around
20%, and 256-bit vectors with AVX will double the number of hashes
computed in parallel (however, it is not certain whether specific CPUs
will process these wider vectors as fast as they process 128-bit ones -
I suspect that at least some will not). Also, I have not reviewed the
vendors' documentation yet, so I am not sure if all of the required
instructions are actually present.
Anyway, it will be 1.5 to 3 years until CPUs with these extensions are
available on the market.
> I mixed the things up with the 8 SSE register compared to 16 SSE registers
> in 64Bit Mode (AMD64 back then). Intel, back then, provided 16 SSE
> registers also in 32Bit mode if I am right.
No, as far as I know, you're wrong. Neither AMD nor Intel CPUs allow
for the use of 16 GP or SSE registers in 32-bit mode. Also, even if
this were supported by the CPUs, it would also require support from OS
kernels (this is easy, but such support does not exist currently -
because there's nothing to support in the first place). This recent
discussion thread indirectly confirms that there's no way to access 16
registers in 32-bit mode:
http://softwarecommunity.intel.com/isn/Community/en-US/forums/thread/30252137.aspx
(well, at least "no official way", and no other way is known presently).
Thanks,
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.
