| 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
| ||
|
Date: Sun, 29 Mar 2015 17:58:14 +0200 From: Dmitry Khovratovich <khovratovich@...il.com> To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net> Subject: Re: [PHC] Salt It seems that a formal definition is not needed actually, as there is no particular definition for key or plaintext in cryptography. Instead, we claim that a password hashing function is secure against attack A if salt satisfies properties P. For instance, suppose that an adversary looks for a preimage to any of the given set of password hashes, where salts are stored in cleartext. Iff the salts are unique, then any password attempt would work for a single hash only (whereas if the salt repeats for N passwords, a password is essentially tried for N hashes simultaneously). Thus in this setting salt should be nonce. One may imagine other scenarios. For instance, part of the salt can be secret, and an adversary wants to recover it (for some reason). Then salt should be random. Randomness and uniqueness are not equivalent properties, nor either of them implies the other. However, for sufficiently long salts (100 bits and longer) random salt is unique with good probability. Best regards, Dmitry On Sun, Mar 29, 2015 at 4:12 PM, Dmitry Chestnykh <dmitry@...ingrobots.com> wrote: > 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 > -- Best regards, Dmitry Khovratovich
Powered by blists - more mailing lists