[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <00b601ccdd31$c4652240$4d2f66c0$@net>
Date: Fri, 27 Jan 2012 14:25:09 -0600
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: OpenCL vs Test Suite
>one question; on a general side, what is the perfect PLAINTEXT_LENGTH
>value ? 32 is it good enough ?
That would be fully up to the implementer of the format. There may be
reasons why only 8 bytes are used. The real world implementation may
truncate things at 8. There may be reasons where a crypt format which could
handle longer passwords, but where the format developer only accepts PW's up
to a certain length. Take for instance crypt MD5. I do not know if there
are length limitations in the crypt implementation. However, there was a 15
byte PW limit added, so that all work can be done in a single frame of MD5
buffer. That was a choice by the john format developer (prolly solar).
That is all and fine.
When we 'know' these limitations, we can use that information within the
pass_gen.pl script file, so that the hashes generated will ONLY use 15 byte
or shorter words, and only use those, when generating output hashes. The
code will 'skip' the longer words. They are still going to be in the input
dictionary file. However, the input hashed file, will not contain those
longer words.
So, if there is XYX format, where we already have it in the TS, handling up
to 32 byte passwords, and we later have an openCL build which does XYX
format, but sets a 12 byte password format, for whatever reason, then we
could easily make a new hash, that should be run on openCL builds. It would
be similar to the original hash input file (which of course would STILL be
there), but this one would be the proper file to run on openCL. It would,
or 'should' end up outputting 1500 (or whatever the right count it), in the
end.
As a side note, Until Magnum made some changes to TS to put openCL in there,
it had never before been tested with any of those (that) specialized john
builds. The only thing I have built/tested when doing the TS was john-core
or john-jumbo (newest jumbo, j5). The TS is simply something that is
developed and updated in parallel with JtR. It is not something 'official'
with john. It is simply something I found useful, when building the dynamic
format, since it was SO complex, and have expanded it to cover more and more
of john.
Take the TS for what it is, and when shortcomings are found, wave a flag.
Things can / will be updated, added or fixed, so that it works better. But I
only know of issues on builds of john that I can do or test. The tool
REALLY should be used by developers, as a step well beyond johns internal
self test. It really shows fully, that the format does what it says it
does, and that when PW's are found and put into the pot file, that they
really ARE the correct usable passwords.
>p.s.
>i've been playing a bit with the testsuite and it rocks; sooner
>i'll try to take some time to fix md5-opencl and NT opencl.
Thanks. I agree with you ;)
Jim.
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.
