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 Aug 2015 16:12:28 +0200
From: Thomas Pornin <>
Subject: Re: [PHC] Argon2 improvement thread

On Fri, Aug 14, 2015 at 03:22:56PM +0200, Krisztián Pintér wrote:
> i don't think that people without understanding what a salt is can
> develop secure code

Indeed they cannot. But they will try. This is a harsh but true fact:
people who develop code for security purpose are a lot more numerous
than the people who are actually competent at developing code for
security purpose. Which is why it is the responsibility of people who
know to design API so as to minimize risks of mishaps. It is all about
_improving_ the situation (because fixing it altogether is unrealistic).

> unless you want to include generating random salts too.

Oh yes I do want that. It is part of the deal. A simple-to-use API that
minimizes risks of misuse would offer two functions: one for generating
the hash _and_ the salt (and encoding both in a string output amenable
to inclusion into string-based systems like an /etc/shadow file) and
another function for verifying a password (takes as inputs the password
and the string, and outputs a boolean).

Such an API can be implemented more or less generically around a core
single-call API that expects the salt as parameter and outputs raw
binary. However, I think it is important that such an API is provided
along with the "reference" implementation, because being tagged
"reference" will lower the probability that other people reinvent it

	--Thomas Pornin

Powered by blists - more mailing lists