phc-discussions - Re: [PHC] On Delegation (Was: "Why I Don't Recommend Scrypt")

lists.openwall.net		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 linux-cve-announce 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" <jeremy@...link.co>
To: discussions@...sword-hashing.net, "Thomas Pornin" <pornin@...et.org>
Subject: Re: [PHC] On Delegation (Was: "Why I Don't Recommend Scrypt")

On Fri, 14 Mar 2014 17:19:24 -0700, Thomas Pornin <pornin@...et.org> 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.