| 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
| ||
|
Message-Id: <F69B2F50-392A-405B-82D7-F10F60560B3F@codingrobots.com> Date: Sun, 29 Mar 2015 16:12:25 +0200 From: Dmitry Chestnykh <dmitry@...ingrobots.com> To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net> Subject: Salt Dear password hashers, We need to formalize the definition of salt. In some papers it’s described as a “sequence of random bytes”, but that’s not enough. As I understand, for those password hashing functions I’m aware of, the only requirement for salt is to be unique and unpredictable, and a sequence of random bytes fits this perfectly. But it’s common for users to put non-random values into salt, or use a concatenation of random values and personalization string (e.g. website address). Some may want to keep bits of salt secret. Without formalizing the definition of salt, people will be arguing if such use is safe or not forever. Also, if one password hashing function doesn’t require a uniformly random salt, but then another function is introduced, which has weaknesses if the salt value is non-random, users won’t be able to safely upgrade. So we should create a formal definition of salt and describe all the requirements for it. -- Dmitry Chestnykh Coding Robots http://www.codingrobots.com
Powered by blists - more mailing lists