3 ms·

I think they mean scalable in the sense that you can run it in large deployments. > [...] computationally expensive (bcrypt, PBKDF2, etc.) and more recently al

by est31 5y ago

I think they mean scalable in the sense that you can run it in large deployments. > [...] computationally expensive (bcrypt, PBKDF2, etc.) and more recently also memory-hard (scrypt, Argon2, etc.) password hashing schemes have been introduced. Unfortunately, at high target throughput and/or low target latency their memory usage is unreasonably low, up to the point where they're not obviously better than the much older bcrypt (considering attackers with pre-existing hardware). This is a primary drawback that yescrypt addresses. > > Most notable for large-scale deployments is yescrypt's optional initialization and reuse of a large lookup table, typically occupying at least tens of gigabytes of RAM and essentially forming a site-specific ROM. This limits attackers' use of pre-existing hardware such as botnet nodes. When the hash function needs 40 GiB of RAM, most consumer hardware bails out, which is what botnets usually are made up of. So that site-specific ROM is mainly a defense against running the hash checking on cheap laptops/desktops etc, forcing attackers to use server hardware, which might be less readily available to them. Note that this advantage is far from the only improvements of yescrypt. Obviously it's not even configured to need 40 GiB of RAM in the settings where it's used as default password hardening algorithm for various distros.

adrian_b 5y ago
Yes, that is the meaning. Yescrypt seems to be the best choice for creating password hashes for the case of servers that may need to verify a large number of passwords simultaneously. The reason is that computing the yescrypt hash requires a lot of work even when the hash is not configured to use much memory. In the case of servers that must verify simultaneously many passwords, it may not be possible to configure the hash function to use a large memory, as that would limit the number of passwords that can be verified simultaneously. On the other hand, for password-based key derivation applications, e.g. for file or file system encryption, where there is no reason to avoid configuring the password hash function to use a few gigabytes of RAM, other password hash functions are more appropriate than yescrypt, e.g. Argon2. Yescrypt has some significant improvements over scrypt, but it still inherits from scrypt the use of the PBKDF2 key derivation function. The PBKDF2 has some defects, but when it is used inside scrypt or yescrypt it is likely that this never has any practical importance. It just is ugly, because it is suboptimal compared to a key derivation function designed correctly. PBKDF2 was chosen intentionally, because it is specified by various standards, so the systems using it are easier to be certified for security purposes. While most NIST security standards are excellent, there are also cases when the standard solutions do not correspond in fact to the best practices. Besides PBKDF2 and other suboptimal key derivation functions, another historical example is the NIST standard for the modes of operation of block ciphers, where all the modes of operation described in its 1980 edition were already obsolete at that date.

by est31 5y ago

adrian_b 5y ago

Yes, that is the meaning. Yescrypt seems to be the best choice for creating password hashes for the case of servers that may need to verify a large number of passwords simultaneously. The reason is that computing the yescrypt hash requires a lot of work even when the hash is not configured to use much memory. In the case of servers that must verify simultaneously many passwords, it may not be possible to configure the hash function to use a large memory, as that would limit the number of passwords that can be verified simultaneously. On the other hand, for password-based key derivation applications, e.g. for file or file system encryption, where there is no reason to avoid configuring the password hash function to use a few gigabytes of RAM, other password hash functions are more appropriate than yescrypt, e.g. Argon2. Yescrypt has some significant improvements over scrypt, but it still inherits from scrypt the use of the PBKDF2 key derivation function. The PBKDF2 has some defects, but when it is used inside scrypt or yescrypt it is likely that this never has any practical importance. It just is ugly, because it is suboptimal compared to a key derivation function designed correctly. PBKDF2 was chosen intentionally, because it is specified by various standards, so the systems using it are easier to be certified for security purposes. While most NIST security standards are excellent, there are also cases when the standard solutions do not correspond in fact to the best practices. Besides PBKDF2 and other suboptimal key derivation functions, another historical example is the NIST standard for the modes of operation of block ciphers, where all the modes of operation described in its 1980 edition were already obsolete at that date.