lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 07 Aug 2013 04:59:06 +0000
From: Alex Elsayed <>
Subject: Re: scrypt like hash, but with AES and HMAC-SHA-2

CodesInChaos wrote:

> An hash I designed a couple of months ago:
> * Time/parallelism trade-offs are bad once parallelism exceeds defender's
> maximum parallelism

I'm not entirely confident in the truth of this. It's one thing to assume 
the attacker has more parallelism available, but they also can simply 
parallelize their inputs. If M is the machine parallelism, and H is the hash 
parallelism then the defender has one correct input and is thus constrained 
by min(M, H).

If the attacker is running a dictionary search their answer to "this 
password hash is only parallelizable up to X" is going to be "Well then, if 
I have N > X available I'll just try X/N options at once." leaving them 
constrained by min(M, N*H) where N is the number of candidate passwords. 

With that, M is going to be the smaller branch in nearly all cases. Even 
min(M, N) is going to usually end up as M.

Although that does bring up an interesting thought: What about driving up 
the cost via multithreading *badly*? Use nonlocal data by a data-dependent 
schedule, forcing either frequent IPI/cache coherency traffic (high-
parallelism user) or frequent task switches (low-parallelism user)?

> * Well defined character encoding: UTF-8

That actually needs more info in order to be 'well-defined' - what 
normalization form are you using? NFC? NFD?



Powered by blists - more mailing lists