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: Thu, 13 Feb 2014 21:00:37 +0400
From: Solar Designer <>
Subject: Re: [PHC] multiply-hardening (Re: NoelKDF ready for submission)

On Thu, Feb 13, 2014 at 11:23:29AM -0500, Bill Cox wrote:
> I'm still torn as to whether or not to offer the SIMD option.  Higher
> memory bandwidth is crucial, but I don't like losing compute time
> hardening as a result.

I've just posted an idea on how you can have both.

> I think we're down to the last 30% in how much we make an
> attacker pay for hardware.  That's a good place to be.

Yes, but that's ignoring attackers with pre-existing hardware such as
GPUs combined with low-memory settings needed for mass password hashing.
For those, we need something very similar to bcrypt's access pattern
(yes, it is leaky), which all upcoming PHC submissions discussed so far
lack.  I am experimenting with introducing it for escrypt.  Until that
is done, I am not happy about PHC submissions for general-purpose uses.
Specialized uses like as KDF in TrueCrypt may be OK.

When scaled down to low memory settings like e.g. Litecoin's 128 KB, the
PHC submissions so far may be about as much faster to attack on GPU than
to compute on CPU, as Litecoin is to mine on GPU vs. CPU (10x to 20x).
While we could stipulate a minimum memory size per hash of e.g. 16 MB,
this would exclude some use cases.  We can do better than that.  We
don't have to be worse than the 17-year-old bcrypt at comparable settings
(currently we are much worse).


Powered by blists - more mailing lists