[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55554.85.178.106.100.1212949387.squirrel@www.jpberlin.de>
Date: Sun, 8 Jun 2008 20:23:07 +0200 (CEST)
From: sebastian.rother@...erlin.de
To: john-users@...ts.openwall.com
Subject: Re: How to chose computer for John?
> On Sun, Jun 08, 2008 at 06:40:09PM +0200, sebastian.rother@...erlin.de
> wrote:
>> Quad core? And what do the other 3 cores do in the meanwhile or did JtR
>> gained a good SMP-capable implementation I ma missed?
>
> You know what I mean. I had mentioned it explicitly in the message
> you're replying to. Run one instance per core. Same directory and
> shared john.pot is OK - this is in the FAQ.
I noticed this but you do know I am sometimes a bitch. ;-]
> This is by far not the only method, and not the most efficient one most
> of the time (although in some special cases it's fine). Other methods
> to split the work have been mentioned on this mailing list before. The
> one that I use most of the time is to split by length of candidate
> passwords. One core does lengths 0-5, and the remaining three do 6, 7,
> and 8 respectively. For large numbers of salted hashes this works
> fine as a replacement to having the "incremental" mode try lengths 0-8
> in one session. For very few salts (or no salts) and for fast hashes,
> the "0-5" and "6" sessions actually terminate after a while, so they may
> be replaced with something - the options here are a huge wordlist with a
> large number of word mangling rules (beyond the default set of rules),
> "--external=Keyboard", etc. This is what I do. And of course, one
> needs to run "single crack" and at least a small wordlist with rules
> first, which also occupies 1-2 cores initially. In some cases, for
> convenience, I started 5-6 sessions in this way initially, knowing that
> the "extra" 1-2 sessions will terminate in a few hours leaving exactly 4
> processes running on the quad-core.
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. 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.
This is my point of view and not something I would argue about.
> I think this topic has been beaten do death already.
>
> Yes, this is possible. 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.
I remember that you once got a ssh at a Box here to test JtR 1.7+ on a
AMD64 running OpenBSD. Most developers of 3rd Party patches may don't do
such things because it consumes time and does not provide any advantage
for the original developer (in case f.e. somebody is just using linux).
I have to admit that I did not checked all "Patches" but last time I did
some did not compiled correctly. I did not needed the provided
functionality (it was just to see if it does work out of the box) but this
points out the difference wich may exists into the development circle if I
compare your "original" code to the code of the additional patches.
I wont blame these developers because nobody can have any OS nor any HW
(like CPU or even architecture) nor endless time.
For me right now I would offer a SSH account to anybody who might would
wanna improve his contributed code to see if the code compiles on other
OSs/Compilers as well.
> My own preference is to use the manual approach described above so far.
For the case you mentioned it makes absolutly sense. I totaly angree here.
> 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.
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.
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? ;-]
>> Also I'd like to know if SSE3/4/5 may improve something compared to
>> SSE2.
>
> SSE3 - as far as I know, no, not for the currently supported hashes at
> least. I have no idea what SSE4/5 are.
SSE5 is a extension of AMD.
INTEL calls anything after SSE4 AVE.
At least I understand it like it's SSE5 with modifications.
So AMD and INTEL do "SSE5" but have different extensions.
SSE4 was introduces with the Core-Architecture.
Please take a look at wikipedia beacuse I currently can not find the docs
at the vendor websites.
http://en.wikipedia.org/wiki/SSE4
http://en.wikipedia.org/wiki/Advanced_Vector_Extensions
http://en.wikipedia.org/wiki/SSE5
> Maybe 8 vs. 16 registers?
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.
> I think the technical limitation of Windows was 32 CPUs, and now it is
> up to 64 CPUs (cores). So we're talking about licensing here. I am
> just unsure if the cheaper Windows licenses allow for the use of more
> than 2 CPUs or cores.
I am unsure about this but I am no Windows professional either.
The Windows-fraction may needs to read about further details at some MS
website. I wont comment on this because I seriously do not know if it's
wrong or right.
Kind regards,
Sebastian
--
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.
