Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't use bcrypt

unlimitednovelty.com

Post reply on HN
Print view View original

91–100 of 193 posts

Re: Don't use bcrypt

#91

Post by SoftwareMaven »

tptacek wrote: post #82
SoftwareMaven wrote: post #73

As long as we've got some smart people hanging around: where does HKDF[1] fit into this? More specifically, when would you use HKDF over scrypt? 1. http://eprint.iacr.org/2010/264.pdf

This makes PBKDFs very di fferent than the general-purpose KDFs studied here. In particular, while passwords can be modeled as a source of keying material, this source has too little entropy to meaningfully apply our extractor approach except when modeling the hash function as a random oracle. Also the slowing-down approach of PBKDFs is undesirable for non-password settings

But, as mentioned by @cperciva elsewhere in this thread, generating a key and creating a password hash are nearly synonymous. Using HKDF for passwords would be silly, but the more interesting question is: when would you use scrypt for key derivation in a system?

More to the point: what are the tradeoffs you'd consider in choosing one over the other?

(Addressed more to @cperciva...) I'm assuming tarsnap uses scrypt as its actual key derivation function for file encryption and authentication. Why scrypt instead of something else (and I have faith that it's not "not invented here" syndrome)?

Re: Don't use bcrypt

#92

Post by baq »

justin_vanw wrote: post #60

I guess it's hip to have an opinion, but JUST USE BCRYPT. It's secure and available. Don't spend time thinking about it, just use bcrypt, it does everything you want, move on to something more worth your time. Unless you're some blogger who needs to generate some page views, then pick some obscure topic like how to store password hashes and rake muck.

> JUST USE BCRYPT

multiple things come to mind:

- Millions Of Flies Can't Be Wrong

- Citation Needed

- JUST USE SCRYPT

etc.

Re: Don't use bcrypt

#93

Post by tptacek »

SoftwareMaven wrote: post #91
tptacek wrote: post #82

Earlier quoted context omitted.

This makes PBKDFs very di fferent than the general-purpose KDFs studied here. In particular, while passwords can be modeled as a source of keying material, this source has too little entropy to meaningfully apply our extractor approach except when modeling the hash function as a random oracle. Also the slowing-down approach of PBKDFs is undesirable for non-password settings

But, as mentioned by @cperciva elsewhere in this thread, generating a key and creating a password hash are nearly synonymous. Using HKDF for passwords would be silly, but the more interesting question is: when would you use scrypt for key derivation in a system? More to the point: what are the tradeoffs you'd consider in choosing one over the other? (Addressed more to @cperciva...) I'm assuming tarsnap uses scrypt as…

I'm quoting the actual paper.

Re: Don't use bcrypt

#94

Post by marshray »

marshray wrote: post #71
cperciva wrote: post #24

Earlier quoted context omitted.

PBKDF2 is worse than bcrypt. By roughly a factor of 5. scrypt is better than bcrypt. By roughly a factor of 4000. why do I care whether something is a PKCS standard or not? You don't care, and I don't care, but I'm sure you know lots of companies which do care (especially since PBKDF2 is a NIST standard too).

> By roughly a factor of (5|4000). Do you have this written up anywhere? Link?

OK, it's in the Scrypt paper. http://www.tarsnap.com/scrypt/scrypt.pdf

Here's my opinion on this:

* These numbers are more appropriately expressed exponentially. I.e. "factor of 5" = 2 bits of security.

* 2 bits of security is not significant at all.

* The Scrypt x5000 seems to only apply when your attacker has access to a chip foundry and it buys you maybe about 12 bits of security against such an attacker.

* For comparison, 128 bits of security is often considered a minimum for resisting offline bruteforce attacks (e.g. AES has a 128 bit key). Of course passwords usually don't come anywhere near close to 128 bits of effective security, so 12 bits might make the difference for some of them if you're lucky.

* In a sense, table 1 in the Scrypt paper shows that the relative difference between the functions is less significant than even relatively small variations in password strength. When the defender has 100ms of CPU to spend authenticating each password, all three functions compared cost less than $200 to break an 8 letter password and more than $150M to break a 10 character password.

* Very few attackers are going to actually spend $M++ trying to break your password (cue XKCD strip). A relevant exception might be botnets, the operators of which don't pay the power bill for their computations.

Therefore, I conclude that for most purposes these functions are mostly equivalent and quality-of-implementation and password strength issues dominate in practice.

Re: Don't use bcrypt

#95

Post by tptacek »

pbsd wrote: post #90
tptacek wrote: post #80

Earlier quoted context omitted.

It takes an arbitrary PRF that is in practice virtually always SHA2, and practically always a well-known cryptographic hash function. If you're going to bank on a cryptographic primitive and you have a choice between "cipher" and "hash function", you pick "cipher". Also, for lay developers, choosing a crypto construct for its modularity is like choosing a smoke detector because it allows you to use different radiolog…

I see you've adopted Moxie's argument, block ciphers against hashes. Very well. The hard part of designing a good hash function is achieving collision-resistance; one-wayness is easy. In this context, we don't really care about collision-resistance, since HMAC can be a PRF without collision resistance of the underlying hash (there was a recent proof by Mihir Bellare) --- this is why it's still "OK" to use HMAC-MD5, d…

It's not "Moxie's argument". It's also Schneier and Ferguson's argument from Cryptography Engineering:

Event hough hash functions are used in almost every system, we know far less about hash functions than we do about block ciphers. This is one of the failures of the cryptographic community. Compared to block ciphers, very little research has been done on hash functions, and there are not many practical proposals to choose from.†

It is also the reason why we are sponsoring contests to replace SHA2, because the research horizon for the current generation of cryptographic hash functions is... ominous.

You're making a noncontroversial statement (ciphers are better studied than hashes) sound like a controversy. It's not really a controversy. And please note: I didn't bring "conservatism" into this discussion; the blog post we're responding to. If you put it to me directly, I'll say bcrypt is more conservative than PBKDF2/SHA2 (which is what every current PBKDF2 system is going to end up using). But I didn't write a blog post that says "don't use PBKDF2".

† I say this only to make the point that it's not an argument pulled from thin air or from Moxie comments; something that Schneier commits to writing is, I mean to say, very likely to represent conventional wisdom.

Re: Don't use bcrypt

#96

Post by tptacek »

Firehed wrote: post #87
tpsreport wrote: post #56

Earlier quoted context omitted.

The point here is that this particular cargo cult around bcrypt (one subscribed to by some really loud people) has a shaky foundation and does not deserve its reputation. He's offering alternatives that have been better studied. So, by all means, subscribe to a cargo cult for crypto. But pick the cult carefully.

He's correct in that if you've selected bcrypt for key derivation, there's a good chance you could be doing things better (for one, its output is only 184 bits long; insufficient for AES256) where PBKDF2 works in a way where you can customize the output length. However, the point of the bcrypt argument is not that bcrypt is the best algorithm for certain things, but that it's (at a minimum) about four orders of magni…

It's not better than bcrypt for password storage; it's marginally worse. See downthread.

Re: Don't use bcrypt

#97

Post by marshray »

tptacek wrote: post #76
marshray wrote: post #66

Earlier quoted context omitted.

The reason I would prefer it is that PBKDF2 is standardized in an RFC with proper test vectors an a reference implementation in C. Bcrypt and Scrypt do not. We could debate the relative quality of the cryptographers behind them all day, but realistically Bcrypt has had at least one widely-deployed implementation bug that caused a real decrease in strength which can be traced back to a lack of proper test vectors.

That's because PBKDF2 is the result of a standards process, and bcrypt is the result of the Unix process (bcrypt is the extaction of OpenBSD's password hash function from the late '90s).

Just to add to that, some common implementations of Bcrypt used by web apps are an extraction from the cracking tool John the Ripper.

Re: Don't use bcrypt

#98

Post by zobzu »

justin_vanw wrote: post #60

I guess it's hip to have an opinion, but JUST USE BCRYPT. It's secure and available. Don't spend time thinking about it, just use bcrypt, it does everything you want, move on to something more worth your time. Unless you're some blogger who needs to generate some page views, then pick some obscure topic like how to store password hashes and rake muck.

Yeah, don't think about stuff. Never think about stuff, in fact! Let us think for you! Or if possible, random self-proclaimed experts!

That's the way to go.

(and i bet many won't even notice the sarcasm)

Freaking hell, do critise, do research, and that apply to everything, not just crypto. It's not rocket science.

Re: Don't use bcrypt

#99

Post by specialist »

pnathan wrote: post #84
smacktoward wrote: post #49

> I write this post because I've noticed a sort of "JUST USE BCRYPT" cargo cult... This is absolutely the wrong attitude to have about cryptography. No. This is incorrect. This is exactly the right attitude for most developers to have about cryptography, because on a subject as complex as cryptography most developers (including me!) are nowhere near smart enough to understand the ins and outs. Encouraging people to m…

> No. This is incorrect. This is exactly the right attitude for most developers to have about cryptography, because on a subject as complex as cryptography most developers (including me!) are nowhere near smart enough to understand the ins and outs. I hear that a lot, and it always reminds me of Jante Law[1]. Its a disservice to keep telling people that they are too stupid to understand something. Too ignorant, perha…

Cryptography is exactingly and excruciatingly hard to do at industrial strength.

Related: Which is why I'm against any and all forms of electronic voting. I've done a fair share of crypto (as a user of crypto libraries) and I barely understand how it works. There's ZERO hope for the layperson to understand crypto-based voting systems.

One of the central tenets of American style voting is a public vote count. Using crypto puts the "public vote count" into the hands of a the high priesthood (a few adepts), which is a really bad idea.

Re: Don't use bcrypt

#100

Post by marshray »

tptacek wrote: post #63
moxie wrote: post #54

This article doesn't feel very well done to me. He writes: "The first cipher I'd suggest you consider besides bcrypt is PBKDF2." PBKDF2 is not a cipher. It's a KDF, and it's almost always used with an HMAC or a cryptographic hash rather than a cipher. The thesis of this article seems to be "PBKDF2 is well understood, where bcrypt is not." In fact, the opposite is probably true. bcrypt uses a block cipher (blowfish) t…

Ladies & Gentlemen, Moxie Marlinspike, whose comment should be heading up this whole thread.

Now I'm as much a fan of Moxie's as anybody, but I think one part of cryptography that needs to change is this tendency to excessively appeal to authority. Especially when speaking about practical issues.
Post reply on HN