3 ms·

> Some implementations of bcrypt truncate the input to 72 bytes, which reduces the entropy of the passwords.... By applying [SHA512], we can quickly convert rea

> Some implementations of bcrypt truncate the input to 72 bytes, which reduces the entropy of the passwords.... By applying [SHA512], we can quickly convert really long passwords into a fixed length 512 bit value, solving [that problem]. This part confused me. How can truncating to 72 bytes be a more severe reduction in entropy than generating a 64-byte hash?

microcolonel 10y ago
I think they're talking about entropy per bit. If they hash to 64 bytes, they integrate all of the entropy of the password, if they truncate to 72 bytes, they throw away all entropy past 72 bytes. This could be a huge problem if you're one of those people who uses a common prefix with a suffix as their password pattern for passwords they need to remember.
- Dylan16807 10y ago
  Especially if your password has a lot of words, you have a very low entropy per byte. It's not the worst thing in the world at 72 bytes, but if you were choosing between a 16 byte hash of a sentence and an 18 byte truncation, the hash is going to have vastly more entropy. And 512 bits is more than plenty.
  - spronkey 10y ago
    > And 512 bits is more than plenty. Famous last words.
    - Dylan16807 10y ago
      "A typical supernova releases something like 1051 ergs. (About a hundred times as much energy would be released in the form of neutrinos, but let them go for now.) If all of this energy could be channeled into a single orgy of computation, a 219-bit counter could be cycled through all of its states." You're not getting through 512 bits of entropy unless your cryptographic methods are severely broken, so broken that having more bits would not meaningfully help.
grenoire 10y ago
Password lengths are variable. With passwords longer than 72 ASCII characters, you will lose entropy after that. Let A be a 72 character long string, and B be A + X. Regardless of what X is, when bcrypted the result for A and B will be the same.
- crpatino 10y ago
  A random X does not reduce the entropy of bcrypt(B), just fails to add any additional entropy beyond bcrypt(A)'s. Assuming C, where len(C) < 72, I don't know if it is possible at all to chose some value of Y such that: D:= C+Y Entropy(bcrypt(D))< Entropy(bcrypt(C))
  - Dylan16807 10y ago
    "Lose" meaning it is thrown away. Not "lose" meaning it subtracts.
CiPHPerCoder 10y ago
If you had two users with a very long password, but the first 100 characters were identical, they'd collide. - Pre-hashing makes this less likely. - Encoding the pre-hashed value to prevent NUL bytes is important. But it's a bandaid solution, to be quite honest. We're better served by migrating to Argon2i, which doesn't have these quirks.

microcolonel 10y ago

I think they're talking about entropy per bit. If they hash to 64 bytes, they integrate all of the entropy of the password, if they truncate to 72 bytes, they throw away all entropy past 72 bytes. This could be a huge problem if you're one of those people who uses a common prefix with a suffix as their password pattern for passwords they need to remember.

Dylan16807 10y ago
Especially if your password has a lot of words, you have a very low entropy per byte. It's not the worst thing in the world at 72 bytes, but if you were choosing between a 16 byte hash of a sentence and an 18 byte truncation, the hash is going to have vastly more entropy. And 512 bits is more than plenty.
- spronkey 10y ago
  > And 512 bits is more than plenty. Famous last words.
  - Dylan16807 10y ago
    "A typical supernova releases something like 1051 ergs. (About a hundred times as much energy would be released in the form of neutrinos, but let them go for now.) If all of this energy could be channeled into a single orgy of computation, a 219-bit counter could be cycled through all of its states." You're not getting through 512 bits of entropy unless your cryptographic methods are severely broken, so broken that having more bits would not meaningfully help.

grenoire 10y ago

Password lengths are variable. With passwords longer than 72 ASCII characters, you will lose entropy after that. Let A be a 72 character long string, and B be A + X. Regardless of what X is, when bcrypted the result for A and B will be the same.

crpatino 10y ago
A random X does not reduce the entropy of bcrypt(B), just fails to add any additional entropy beyond bcrypt(A)'s. Assuming C, where len(C) < 72, I don't know if it is possible at all to chose some value of Y such that: D:= C+Y Entropy(bcrypt(D))< Entropy(bcrypt(C))
- Dylan16807 10y ago
  "Lose" meaning it is thrown away. Not "lose" meaning it subtracts.

CiPHPerCoder 10y ago

If you had two users with a very long password, but the first 100 characters were identical, they'd collide. - Pre-hashing makes this less likely. - Encoding the pre-hashed value to prevent NUL bytes is important. But it's a bandaid solution, to be quite honest. We're better served by migrating to Argon2i, which doesn't have these quirks.