Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 23 Apr 2023 13:20:12 +0200
From: Solar Designer <>
Subject: Re: Birthday paradox

On Sun, Apr 23, 2023 at 12:46:07PM +0200, magnum wrote:
> On 2023-04-23 12:28, magnum wrote:
> >Starting with no bitmap (BLOOM_K=0 disables):
> >
> >Using default input encoding: UTF-8
> >Loaded 256 password hashes with no different salts (NT-opencl [MD4 OpenCL])
> >256 hashes: Hash table in local memory (2468 B); no filter.
> >Offset tbl 380 B, Hash tbl 2088 B, Results 3076 B, Dupe bmp 36 B, TOTAL 
> >on GPU: 5580 B
> >LWS=256 GWS=34816 (136 blocks) x9025
> >Press 'q' or Ctrl-C to abort, 'h' for help, almost any other key for status
> >25g 0:00:00:24 DONE (2023-04-23 12:04) 1.004g/s *30628Mp/s* 30628Mc/s 
> >7190GC/s Dev#2:66°C util:95% aaUh}|..aaUh}|
> >Remaining 231 password hashes with no different salts
> >Session completed.
> >735091890625 crypts, fp from bitmap: 1/4153061529 (0.00%), 177 hash 
> >table lookups
> Same without even using local memory:
> 256 hashes: Hash table in global memory (2532 B); no filter.
> Offset tbl 412 B, Hash tbl 2120 B, Results 3076 B, Dupe bmp 36 B, TOTAL 
> on GPU: 5644 B
> LWS=256 GWS=34816 (136 blocks) x9025
> Press 'q' or Ctrl-C to abort, 'h' for help, almost any other key for status
> 25g 0:00:00:25 DONE (2023-04-23 12:36) 0.9723g/s *29403Mp/s* 29403Mc/s 
> 6902GC/s Dev#2:67°C util:95% aaUh}|..aaUh}|
> Remaining 231 password hashes with no different salts
> Session completed.
> 735091890625 crypts, fp from bitmap: 1/3910063248 (0.00%), 188 hash 
> table lookups
> The reported "fp from bitmap" in the no-bitmap case are 32-bit false 
> positives from the hash table. They should be the same above but somehow 
> isn't.  I regard it as some effect of the mentioned randomness in the 
> PHT (as you can see the sizes differ as well) but in the no-bitmap case 
> it still puzzles me - we're comparing an actual MD4 hash word by word.

Making some guesses on what code this corresponds to and what it does,
as I am not familiar with Sayantan's and have not seen your latest:

As I understood, these PHTs use 64-bit hashes as input to index
calculation.  Now you say they store 32-bit values.  I notice the
discrepancy here - it's not exactly comparison of the same 32-bit part
of MD4 hashes - it probably would be if you switched to using the same
32-bit part also for the index calculation, but then that would be
suboptimal.  It's more optimal to use non-overlapping parts of the hash
for index and for storage/comparison.  OTOH, for tiny hash tables like
this you can reasonably switch to using a (different) 32-bit part of the
MD4 hash, as modulo division bias would be small.  The modulo operation
should be faster on a 32-bit input than on 64-bit.


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.