Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 28 Sep 2011 09:53:12 +0200
From: magnum <rawsmooth@...dband.net>
To: john-dev@...ts.openwall.com
Subject: Re: Some ideas about enhanced self-test

On 2011-09-27 16:12, jfoug wrote:
>> From: David Jones [mailto:jonesd@...umbus.rr.com]
>> On Sep 27, 2011, at 2:29 AM, magnum wrote:
>>> I take this on-list from here in case someone wants to chime in. This
>>> started as a private discussion about eg. crc-32 and dummy getting
>>> significantly inflated benchmark figures [from testing null-string]
>>
>> On first blush, I'd suggest having a field bench_weight whose value
>> reflects the relative frequency that's to be tested during benchmarking.
>> A zero value is used for edge cases that very rare but need to be
>> included in the self test for completeness.  An 8 character password
>> would be given a higher weight than the 20 character test password if
>> that's relevant to the benchmark.
...
> Now one way to proceed is to somehow build the list of words to use, prior
> to actually 'entering' the loop the feeds the format benchmarking it.  If
> done this way we 'could' do frequency percentages, by building a pseudo
> wordlist during benchmarking, and adding words in proper proportion, then
> spinning through that list.  At benchmark time (the inner loop), we would
> not have to compute percentages.  They have been done 1 time, prior to
> startup.

I think that's too much code for little gain. Jim, what if you include 
the nullstring in crc-32 but also include a max-length string? Would 
that push the benchmarks back closer to real-life figures, or would it 
push it back too far?

For that matter, bench.c could (during test phase) construct a 
max-length string consisting of random ascii or just a repeated 
character, and set that as key at every other index up to 
max_keys_per_crypt, using valid strings inbetween (which of course are 
expected to pass). This should catch many buffer overruns.

magnum

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ