[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4e3d9d1b8420b95dab2ea415dafd44e8@smtp.hushmail.com>
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.
