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: Fri, 14 Mar 2014 21:56:29 -0700
From: "Jeremy Spilman" <>
To:, "Thomas Pornin" <>
Subject: Re: [PHC] On Delegation (Was: "Why I Don't Recommend Scrypt")

On Fri, 14 Mar 2014 17:19:24 -0700, Thomas Pornin <> wrote:

> The salt 's' is assumed to be known to everybody. D is modeled as a
> passive attacker: D will faithfully run the requested computation (if D
> is an active attacker, then it can disrupt the service by simply not
> responding, or returning random junk).

> If you can describe how such a thing could be built on top of, say,
> bcrypt, then please show me.

I'm with you all the way to the point where you say salt 's' is assumed to  
be public.

Alternatively, salt is 64 bytes from a CS-PRNG, and stored directly  
alongside the resultant hash value in the validator database.

Handing over just an intermediate hash value to the external service, but  
not the CS-PRNG generated salt, the passive attacker observing all  
communication between the site and the external service would still need  
access to the validator database of the site to steal any plains.

Powered by blists - more mailing lists