Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 18 Jun 2012 02:51:15 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Reduced binary size

On 2012-06-17 22:54, magnum wrote:
> On 2012-06-17 01:22, magnum wrote:
>> Also, unlike the formats that use intrinsics.c, this format will benefit
>> from a reduced binary_size (just the one 32-bit int that is checked in
>> cmp_all()), and a "linkedin" version of that would probably perform way
>> better than our current one, with six million hashes. This would be
>> trivial. Maybe I'll try it out later unless someone else do.
>
> No, wait... What is stopping us from using reduced binary size in the
> old formats too? Nothing! I have been confused for years. Maybe I should
> try this out in raw-md5 and raw-sha1[_li] and see what happens when
> loading zillions of hashes.

I just committed reduced binary size for raw-md4/md5/sha1 and nt2. Saves 
3 or 4 bytes per loaded hash (makes some difference for 135 million 
hashes, lol) and should help keeping good stuff in cache. It's not 
merged to bleeding yet - the get_source() gets a little trickier and I 
should get some sleep.

It passes Test Suite - actually I would have committed a hideous bug in 
SHA-1 if it wasn't for TS.

magnum

Powered by blists - more mailing lists

Your e-mail address:

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