[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120704164435.YEVFU.415548.imail@eastrmwml304>
Date: Wed, 4 Jul 2012 16:44:35 -0400
From: <jfoug@....net>
To: john-dev@...ts.openwall.com
Subject: RE: formats interface enhancements
I thought of a couple of things we have kicked about at one time or another, when it comes to self test data.
1. Add a flag that says to use this ST value as a benchmark or not.
2. Add some sort of fields to the ST, so that it will be used or skipped on a build. Things to check for are: PLAIN_TEXT_LEN <= the length of the PW, if in utf8 mode or not (or other encoding), etc, etc. Then we can build test data, and allow run-time john to determine what TS's to use
#1 allows us to greatly expand test cases (len 0, 1, max-1, max, etc). And it will also allow keeping the exact same 1 or 2 that are used in benchmarks, so that we are testing the same bench data from version to version.
#2 allows building strings with passwords long enough to test boundaries, even if there are multiple PT lengths, depending upon how compiled. Same goes for utf8 or other 'modifications' we have to TS items. Hell, we have formats now, that muck with TS data in init call, depending upon runtime. It would be nice to build an array of TS data, and then let the process deal with proper selection.
Just an idea I had, when drinking beer and shooting off fireworks the other day, and I know Alex was wanting comments about this type of re-work.
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.
