Date: Sun, 01 Jul 2012 20:06:21 +0200 From: magnum <john.magnum@...hmail.com> To: john-dev@...ts.openwall.com Subject: Re: raw-sha1-ng reduced binary size On 2012-07-01 14:30, magnum wrote: >> Cool, I'll do some experiments with all three versions. > > I think we are actually not using cmp_all() much, due to the hash > tables. I tried exhausting --inc=digits against 6.5 million hashes: > > Original 20-byte version peaks 876 MB and ends in 21 seconds. > The 16-byte version peaks 826 MB and ends in 21 seconds. > The 4-byte version peaks 777 MB and ends in 21 seconds. > > The vanilla raw-sha1 format also peaks 777 MB and also ends in 21 seconds. > > The raw-sha1 in bleeding-jumbo uses a full 20 bytes of binary but > instead does not keep the source hashes (it uses the new get_source() > function for rebuilding them). In only needs 674 MB and it finishes in > 17 seconds, however I think I just found a bug in that one so this might > not be a proper figure. That bug in the bleeding branch is fixed now (it did not affect Jumbo-6). The memory footprint remains at 674 MB but the speed was even better, 15 seconds. So from these tests I suppose what we should really do is write a get_source() for your format in the bleeding branch, instead of reducing binary size. They are obviously mutually exclusive - you can't reconstruct the ciphertext source from a reduced binary. magnum
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.