Re: [RFC][Discussion] Add PASSWORD_BCRYPT_WRAP

On Fri, Oct 30, 2026, at 09:36, Tim Düsterhus wrote: > - The section on “bcrypt-sha256” is very vague in how your construction > is better. Given that both bcrypt-sha256 and your bcrypt-wrap (with > SHA-512) use a HMAC construction using the (BCrypt) salt as a key as the > pre-hash, folks will rightfully wonder how the bcrypt-wrap construction > is better than that of bcrypt-sha256 (other than using a different hash > function) and should not be required to “reverse engineer” the > differences. Recently two new password hashes were proposed, both with the goal of solving bcrypt's 72-byte limit and failure to handle null-bytes: - PASSWORD_BCRYPT_WRAP https://wiki.php.net/rfc/password_bcrypt_wrap - PASSWORD_BCRYPT_SHA256 https://wiki.php.net/rfc/bcrypt_sha256 (proposed by me) Both prehash the password before passing them to bcrypt. • BCRYPT_SHA256 uses the same algorithm as Python's passlib. That provides interoperability with that library. It also means we cannot deviate from that algorithm without giving up that interoperability. • BCRYPT_SHA256 is simpler and adds less code to PHP. • BCRYPT_WRAP supports two prehashing algorithms. • Both use the salt as the key, but in a technically different way. BCRYPT_WRAP decodes the base64-encoded salt, BCRYPT_SHA256 normalizes the text version of the salt. • The text representation of the hash differs: BCRYPT_WRAP follows the PHC string format and is slightly longer than BCRYPT_SHA256. I think both RFC with all three proposed prehashing methods are sufficiently secure. For security I see no reason to prefer one over the other. Adding one new algorithm would be sufficient. Cryptographic agility within the hashing algorithm is not necesssary; users can move to another hashing algorithm such as Argon2. Both hash formats have a version field, making it possible to make backwards compatible changes. It is unfortunate that we now have two RFCs that are so similar. Voting on them in isolation could result in an undesirable outcome. Regards, Sjoerd Langkemper