Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 1 Jul 2012 13:20:56 +0200
From: Tavis Ormandy <taviso@...xchg8b.com>
To: john-dev@...ts.openwall.com
Subject: Re: Re: Re: asan report

magnum <john.magnum@...hmail.com> wrote:

> On 2012-06-30 13:09, Tavis Ormandy wrote:
> > > > In fact, I was going to suggest adding a flag that guarantees it
> > > > will be 16-byte aligned so I can use MOVDQA.
> >>
> > > I've had such thoughts too. But I'm not sure how we'd handle wordlist
> > > buffer mode (which is a huge speedup). We'll need to think it over.
> >>
> > 
> > OK, sounds good to me.
> 
> 
> 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?

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

Tavis.

-- 
-------------------------------------
taviso@...xchg8b.com | pgp encrypted mail preferred
-------------------------------------------------------

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.