Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 01 Jul 2012 13:51:16 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: raw-sha1-ng reduced binary size (was: asan report)

On 2012-07-01 13:20, Tavis Ormandy wrote:
> magnum <john.magnum@...hmail.com> wrote:
>> BTW you still advertise a BINARY_SIZE of 20 octets although you would do
>> perfectly fine with 4. The difference is very far from neglectable if you
>> load a couple of million hashes. I *really* think this should be your #1
>> goal and it's a walk in the park. Take a look at a late rawSHA1_fmt_plug.c
>> and look for BINARY_SIZE vs DIGEST_SIZE.
>>
>> magnum
> 
> I understand, I'm just not sure it's worth the performance penalty (because
> I can't treat it like a dqword in cmp_all). I can think of a faster format
> if I store it redundantly, like:
> 
> SHA1  =00112233 44556677 aabbccdd eeff3344 eeaa1122
> BINARY=EEAA1122 EEAA1122 EEAA1122 EEAA1122
> 
> Then I only have to shuffle it once, instead of once per cmp_all. That's a
> saving of 4 bytes per hash, and I can still use it like a dqword, is that
> ok?

Sure, I did not realize you would end up with a slower cmp_all. There
should be some way around that.

> I made both changes, so you can choose. I sent you a pull req for the 16byte
> one, but the 4byte one is here if you prefer:
> 
> https://github.com/taviso/magnum-jumbo/commit/88ea3e884b7a0bfd5f2452d864c5cc6244fc3f34

Cool, I'll do some experiments with all three versions.

magnum

Powered by blists - more mailing lists

Your e-mail address:

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