Hi
On 2026-09-30 16:34, Rowan Tommins [IMSoP] wrote:
The algorithm correctly
handles a password whether it's 8 bytes long or 80 bytes long. When
the password is too long, it just ignores the extraneous input
I find this statement completely baffling. It *silently throws away
input*; I simply do not accept that as "correctly handling" it.
Imagine if it truncated at 7 bytes; would you still call that "correct
handling", as long as it was documented behaviour?
I would. This is in fact almost exactly the behavior of the classic
`CRYPT_STD_DES` algorithm, except the limit is 8 bytes (with the high
bit ignored) with a 64 bit internal state: Even if the additional
characters would not be ignored, the 64 bit state means that there are
equivalent inputs of 8 bytes or fewer for inputs of 9 bytes or more.
It is no longer secure today due to the 56-bit key size, but given the
computing limitations back then, I would consider it reasonable. Of
course users will not be entering raw bytes, but characters. Still 8
randomly selected alphanumeric bytes would be around 48 bits of entropy.
the security of the algorithm is the same.
The algorithm treats 255 different 73-byte inputs as identical. A
different algorithm would distinguish them. Are you really saying those
are equally secure algorithms?
An ASCII diceware password is probably the least information dense
method of choosing a secure password and as per the math I provided in
https://news-web.php.net/php.internals/132694, you can fit 100 bits of
“Diceware entropy” into the 72 byte limit. While not “equally secure”
under a literal reading you are well past the point of diminishing
returns: Trying to guess 100 bits of entropy is impossible, trying to
guess 101 bits is just more impossible. The “stretching” provided by
BCrypt’s cost factor effectively adds another $cost number of bits of
effective security, since increasing the cost by 1 doubles the execution
time.
Constructing one of the 255 colliding 73-byte inputs requires you to
know the 72-byte prefix. In practice knowing the prefix means that you
know the password, so the extra bytes are irrelevant for security.
Furthermore similarly to the classic DES crypt, BCrypt also has an
output size of 184 bits. Once the input exceeds that, there's a
different input that results in the same output. This is a fundamental
information theoretic limit, not an arbitrarily selected one. For a
completely random 40 byte input you are already well beyond the output
size, so some 40 byte inputs necessarily collide, but this doesn't mean
it's feasible to find those.
Forcing the user to select a different password by emitting an error
message if they input a needlessly long one (“more is better”) is not
improving the security, while decreasing user experience.
Best regards
Tim Düsterhus
