|
Message-ID: <mpro.m6hhna0761p0g00sk.taviso@cmpxchg8b.com> Date: Sun, 1 Jul 2012 15:33:12 +0200 From: Tavis Ormandy <taviso@...xchg8b.com> To: john-dev@...ts.openwall.com Subject: Re: raw-sha1-ng reduced binary size magnum <john.magnum@...hmail.com> wrote: > On 2012-07-01 13:51, magnum wrote: > > 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 > > You mean ac3bb1951d6f44cad71b9b2d39a095ff140bb2de, right? > > magnum Oops, yep. -- ------------------------------------- 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.