Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 16 Sep 2015 05:57:21 +0300
From: Solar Designer <>
Subject: Re: larger bitmaps and hash tables

On Wed, Sep 16, 2015 at 05:28:17AM +0300, Solar Designer wrote:
> With SHR=1:
> real    0m52.976s
> user    3m39.218s
> sys     0m16.227s

Another doubling of bitmap size while keeping the hash table size same:

#define PASSWORD_HASH_SIZE_6            0x20000000
#define PASSWORD_HASH_SHR               2

real    0m50.480s
user    3m19.678s
sys     0m17.056s

And one more:

#define PASSWORD_HASH_SIZE_6            0x40000000
#define PASSWORD_HASH_SHR               3

real    0m50.080s
user    3m9.933s
sys     0m18.377s

And one more:

#define PASSWORD_HASH_SIZE_6            0x80000000
#define PASSWORD_HASH_SHR               4

real    0m50.453s
user    3m7.901s
sys     0m20.535s

Somehow a regression, and system time increase.  Maybe the page table
entries became too large to fit in a cache.  (And we were having mostly
TLB misses anyway.)  Maybe use of "huge pages" for the bitmap and the
hash table would help.

BTW, the actual cracking takes just 21 to 23 seconds (varies across the
8 processes), meaning that the loading is 27 seconds.  We should be able
to optimize the loading somewhat.

To make these experiments easier, I adjusted the *_6() hash functions to
use (PASSWORD_HASH_SIZE_6 - 1) for the mask.  Perhaps we should make
this standard practice.


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.