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.
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?
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. :|
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!
I'm not an OpenBSD fan, Marsh. I'm close to the opposite. And I'm calling BS on this. I'm sure the OpenBSD people aren't nice to you, but it's probably not because you found flaws in OpenBSD code. I wasn't being flippant; the only thing Theo ever fucked with me over was not finding enough bugs.
As for the last part of your comment, we appear to be searching for reasons to disagree with each other, when in fact we agree that this finding has no impact on the security of bcrypt. Let's not find artificial reasons to disagree.
Yeah I've been off and on the OpenBSD lists a few times over the years and have said both really dumb stuff and insightful stuff. I'm not so much referring to any specific instance, just saying their reputation for being cranky and unwelcoming is well deserved.
I was wrong about bcrypt being a 192-bit narrow-pipe hash. While some parts of it are, reading the paper again the real work happens in the key expansion function having an internal state size of 33344 bits.
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.
No, commendable would have been waiting a reasonable amount of time for the author to respond, and not including suggestions that the bug (that they didn't analyse the impact of) was an intentional backdoor.
... ridiculed by the OpenBSD hyenas?
Cheap, ad hominem, etc.
Noting that NIST didn't specify any form of truncated SHA-1
Not SHA-1, but SHA-224 and SHA-384 are truncated hashes specified by NIST.
In many (perhaps most) contexts, the critical security factor is the square root of that number
Not in this case, unless you have corpora of ~2^80 bcrypt hashes and want to find a collision with one of them.
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.
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".
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.
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.
