4 ms·

> The discrepancy in hash length is totally harmless (adding something like 2^-186 additional likelihood of collision) and was present in the reference implemen

by daeken 15y ago

> The discrepancy in hash length is totally harmless (adding something like 2^-186 additional likelihood of collision) and was present in the reference implementation. Assuming that this was not intentional -- and considering that the paper clearly supports this -- then it is not totally harmless. The additional likelihood of collision is increased by ~4.16% (8 / 192) which could be a Big Deal (TM) given the right circumstances, although it's still infinitesimally small. But what worries me more is that you say "this assinine [sic] blog post". The author of the post found what could be an issue, even if it's not in your code, and you write it off completely. That is simply not an appropriate way to handle issues with cryptographic software.

tptacek 15y ago
It was an asinine blog post, Cody. It strongly implied that the author of py-bcrypt intentionally sabotaged it. And, I disagree with your security analysis. Truncating an otherwise secure 192 bit hash to 185 bits is not dangerous. You are talking about percentages of quantities denominated in atoms-in-the-planet-core.
- daeken 15y ago
  I agree that implying the creator of py-bcrypt was malicious is asinine (although that was apparently not his intention), but dropping 8 bits off the hash could be dangerous. When you're talking about an attack against a perfect hash function, it would mean nothing due to the large size, but in conjunction with theoretical flaws in bcrypt it could be a big deal. All that said! Bcrypt is still secure by all means and better off than damn near anything else out there. Edit: note, such theoretical flaws in bcrypt have not even been proposed. Didn't want to make this seem worse than it is.
  - tptacek 15y ago
    The sad thing is, the finding isn't asinine. It's truly interesting (though practically irrelevant, except that it appears to have rendered the ref implementation of bcrypt incompatible with Mazieres' paper). But instead of spending time talking about the interesting finding, this blogger clubbed their own reputation to death on it. I'd like to presume they were just spectacularly bored, but to steal some of the author's own words, that's "vastly too big a discrepancy to be explainable by a simple inadvertent bug".
- SoftwareMaven 15y ago
  Maybe we read different posts, but I didn't get anything like an implication that the author of py-crypt intentionally sabotaged it. What I got was more of a "I'm not taking anything for granted because that would be a good attack vector." I'll leave the rest of the analysis as to the effect of the problem to your much-more-knowledgable hands.
  - tptacek 15y ago
    http://news.ycombinator.com/item?id=2655222 http://news.ycombinator.com/item?id=2655222
    - deleted 15y ago
      [deleted]
- marshray 15y ago
  It was an asinine blog post, Cody. It strongly implied that the author of py-bcrypt intentionally sabotaged it. The guy found a design bug/implementation discrepancy in a bit of software with high security requirements. He didn't know how to evaluate the security impact or what to do about it. But he knew enough to know he should take it seriously. This is commonly referred to as "being paranoid" and is a natural reaction given the situation. Commendable even. How many people before him spotted this and didn't speak up because they (rightfully) figured they'd be ridiculed by the OpenBSD hyenas? And, I disagree with your security analysis. Truncating an otherwise secure 192 bit hash to 185 bits is not dangerous. I agree, especially given the relative sizes involved. But until recently there was debate about the safety of truncating hash values in general. Noting that NIST didn't specify any form of truncated SHA-1, people would say there was no guarantee that the "entropy was evenly distributed". You are talking about percentages of quantities denominated in atoms-in-the-planet-core. This is a common fallacy. There is no relationship between the cardinality of the possible hash values and the number of atoms in some planetary body. In many (perhaps most) contexts, the critical security factor is the square root of that number. Shall we then look for another smaller planetary body with which to consider that number?
  - tptacek 15y ago
    From where do you get the idea that the "OpenBSD hyenas" would ridicule you for finding a security vulnerability in OpenBSD? The only thing I've ever been ridiculed for by Theo is not finding bugs in OpenBSD. You can get advice about truncating SHA512 from Furguson and Schneier; that book is 5 years old. Since we appear to agree about the important bit, I'm disinclined to argue about how many atoms are in the core or whatnot. I fully own up to not actually having counted them. :|
    - marshray 15y ago
      From where do you get the idea that the "OpenBSD hyenas" would ridicule you for finding a security vulnerability in OpenBSD? Seriously? One doesn't have to hang around those lists long to see how they treat those they disagree with. You can get advice about truncating SHA512 from Furguson and Schneier; that book is 5 years old. Sure, but that wasn't written in the late 1990s when bcrypt was presented and we certainly can't expect the blogger to have read up on the modern advice. Bcrypt doesn't even use SHA-512, it uses the block cipher Blowfish in a suboptimal custom mode to construct its own 192-bit narrow-pipe hash function. When Microsoft rolled their own password hash functions with DES just a few years earlier (LanMan, NTLM) it was thoroughly pwned by Schneier, Mudge, Wagner, L0pht, etc. But you know this!
- ars 15y ago
  > It strongly implied that the author of py-bcrypt intentionally sabotaged it. No it didn't. And I quote: "Except that the problem is not in the python wrapper."
- Lagged2Death 15y ago
  It strongly implied that the author of py-bcrypt intentionally sabotaged it. It explicitly says very much the opposite, pointing out that the problem isn't the wrapper. I can't understand how you could read the blog post and come away with such an impression.

by daeken 15y ago

tptacek 15y ago

It was an asinine blog post, Cody. It strongly implied that the author of py-bcrypt intentionally sabotaged it. And, I disagree with your security analysis. Truncating an otherwise secure 192 bit hash to 185 bits is not dangerous. You are talking about percentages of quantities denominated in atoms-in-the-planet-core.

daeken 15y ago
I agree that implying the creator of py-bcrypt was malicious is asinine (although that was apparently not his intention), but dropping 8 bits off the hash could be dangerous. When you're talking about an attack against a perfect hash function, it would mean nothing due to the large size, but in conjunction with theoretical flaws in bcrypt it could be a big deal. All that said! Bcrypt is still secure by all means and better off than damn near anything else out there. Edit: note, such theoretical flaws in bcrypt have not even been proposed. Didn't want to make this seem worse than it is.
- tptacek 15y ago
  The sad thing is, the finding isn't asinine. It's truly interesting (though practically irrelevant, except that it appears to have rendered the ref implementation of bcrypt incompatible with Mazieres' paper). But instead of spending time talking about the interesting finding, this blogger clubbed their own reputation to death on it. I'd like to presume they were just spectacularly bored, but to steal some of the author's own words, that's "vastly too big a discrepancy to be explainable by a simple inadvertent bug".
SoftwareMaven 15y ago
Maybe we read different posts, but I didn't get anything like an implication that the author of py-crypt intentionally sabotaged it. What I got was more of a "I'm not taking anything for granted because that would be a good attack vector." I'll leave the rest of the analysis as to the effect of the problem to your much-more-knowledgable hands.
- tptacek 15y ago
  http://news.ycombinator.com/item?id=2655222 http://news.ycombinator.com/item?id=2655222
  - deleted 15y ago
    [deleted]
marshray 15y ago
It was an asinine blog post, Cody. It strongly implied that the author of py-bcrypt intentionally sabotaged it. The guy found a design bug/implementation discrepancy in a bit of software with high security requirements. He didn't know how to evaluate the security impact or what to do about it. But he knew enough to know he should take it seriously. This is commonly referred to as "being paranoid" and is a natural reaction given the situation. Commendable even. How many people before him spotted this and didn't speak up because they (rightfully) figured they'd be ridiculed by the OpenBSD hyenas? And, I disagree with your security analysis. Truncating an otherwise secure 192 bit hash to 185 bits is not dangerous. I agree, especially given the relative sizes involved. But until recently there was debate about the safety of truncating hash values in general. Noting that NIST didn't specify any form of truncated SHA-1, people would say there was no guarantee that the "entropy was evenly distributed". You are talking about percentages of quantities denominated in atoms-in-the-planet-core. This is a common fallacy. There is no relationship between the cardinality of the possible hash values and the number of atoms in some planetary body. In many (perhaps most) contexts, the critical security factor is the square root of that number. Shall we then look for another smaller planetary body with which to consider that number?
- tptacek 15y ago
  From where do you get the idea that the "OpenBSD hyenas" would ridicule you for finding a security vulnerability in OpenBSD? The only thing I've ever been ridiculed for by Theo is not finding bugs in OpenBSD. You can get advice about truncating SHA512 from Furguson and Schneier; that book is 5 years old. Since we appear to agree about the important bit, I'm disinclined to argue about how many atoms are in the core or whatnot. I fully own up to not actually having counted them. :|
  - marshray 15y ago
    From where do you get the idea that the "OpenBSD hyenas" would ridicule you for finding a security vulnerability in OpenBSD? Seriously? One doesn't have to hang around those lists long to see how they treat those they disagree with. You can get advice about truncating SHA512 from Furguson and Schneier; that book is 5 years old. Sure, but that wasn't written in the late 1990s when bcrypt was presented and we certainly can't expect the blogger to have read up on the modern advice. Bcrypt doesn't even use SHA-512, it uses the block cipher Blowfish in a suboptimal custom mode to construct its own 192-bit narrow-pipe hash function. When Microsoft rolled their own password hash functions with DES just a few years earlier (LanMan, NTLM) it was thoroughly pwned by Schneier, Mudge, Wagner, L0pht, etc. But you know this!
ars 15y ago
> It strongly implied that the author of py-bcrypt intentionally sabotaged it. No it didn't. And I quote: "Except that the problem is not in the python wrapper."
Lagged2Death 15y ago
It strongly implied that the author of py-bcrypt intentionally sabotaged it. It explicitly says very much the opposite, pointing out that the problem isn't the wrapper. I can't understand how you could read the blog post and come away with such an impression.