No, they are not bugs. As usual in the real world, there are differences between academic work and practical implementation. There is no reason to worry about this because:
a) The truncation of the hash exists in the reference implementation that was written by Provos and Mazieres (the paper authors). You can check this for yourself in OpenBSD's CVS.
b) The incremental likelihood of collision caused by truncating the hash is in the order of 2^-186, which is irrelevant in this context.
Why was this done? You'd have to ask Niels or Davis, but I'd guess that they figured 60 characters was a more convenient length.
I guess this blog post was yours: http://rondam.blogspot.com/2011/06/possible-flaw-in-open-source-bcrypt.html
I have to say that I find it completely assinine and irresponsible. You imply that this difference in behaviour could be a deliberately-inserted vulnerability, without waiting even a week for a reply from me or bothering to check the reference implementation or its authorship before insinuating malicious intent.
Please retract your your post.
For the record, I never meant to imply that py-bcrypt was malicious, only that it is prudent to track down and understand discrepancies like this when one encounters them because they could some day be an indication of something malicious going on.
It's true that I did not wait a week before going public, I waited two days. I think reasonable people could disagree over what the appropriate length of time is in a situation like this.
In any case, for the record, there is now no reason I know of not to use py-bcrypt, and I apologize for any misunderstanding my earlier post may have caused.
What you did seems neither asinine nor irresponsible to this third party observer with no skin in the game either way.
ReplyDeleteThanks. I obviously agree, though I also see how what I wrote could have been misinterpreted. There's a reason I made my career as an engineer and not a diplomat.
ReplyDelete