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

71–80 of 193 posts

Re: Don't use bcrypt

#71

Post by marshray »

cperciva wrote: post #24
tptacek wrote: post #20

PBKDF2 is worse than bcrypt. scrypt is better than bcrypt. bcrypt has the advantage of being both very good, and also broadly available on web platforms. scrypt does not yet have that advantage; when it does, I will start saying "just use scrypt". But the simple fact is: all three of these functions are fine . ANY of them is a huge step forward from what people do without them. "Just use bcrypt" is 1000x more effecti…

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?

Re: Don't use bcrypt

#72

Post by tptacek »

nextparadigms wrote: post #64
tptacek wrote: post #20

PBKDF2 is worse than bcrypt. scrypt is better than bcrypt. bcrypt has the advantage of being both very good, and also broadly available on web platforms. scrypt does not yet have that advantage; when it does, I will start saying "just use scrypt". But the simple fact is: all three of these functions are fine . ANY of them is a huge step forward from what people do without them. "Just use bcrypt" is 1000x more effecti…

Isn't that a self-fulfilling prophecy? If you buying into the "just use bcrypt" idea, how will scrypt ever change the fact that it's not widely available on the web?

I addressed this directly downthread. I don't care whether TweetYourCatFood.com uses bcrypt. Specifically, I care that:

* It's got a reliable Gem for Ruby

* It's got a reliable easy_install package for Python

* It's got a good reliable CPAN entry for Perl

* It's got a Java jar file from a reputable source

* It's got a .NET assembly from a reputable source

And what I'm saying is not that scrypt will be "safe to use" when that happens. scrypt is safe to use now; safer, marginally, than bcrypt. What I'm saying is that when that set of things happens, I will personally stop recommending bcrypt and start recommending scrypt. And I only point that out because I always feel a little bad about not recommending scrypt, which is strictly speaking better than bcrypt.

Re: Don't use bcrypt

#74

Post by jiggy2011 »

pleasebehonest wrote: post #55
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…

That attitude is abrasively condescending. Why not just say, "people who spent a lot of their time studying cryptography strongly recommend this approach. They feel the approach that you are considering is simply insecure."? Framing things in terms of intelligence isn't going to win anyone over, if that's your goal. And it probably isn't accurate, either.

it's not necessarily about intelligence per se.

I think "smarter" in this context means more well read about the particular subject of crypto, although people good at that are likely to very intelligence all round too.

A different approach is not necessarily "less secure" it's just that it may have had less people banging on it trying to figure out ways to break it.

Re: Don't use bcrypt

#75

Post by dhimes »

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?

There are a couple of links on this page:

http://www.tarsnap.com/scrypt.html

Re: Don't use bcrypt

#76

Post by tptacek »

marshray wrote: post #66
tptacek wrote: post #22

Earlier quoted context omitted.

Is there a reason other than branding that you think it's fair to push for PBKDF2 to be the "default" instead of bcrypt?

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).

Re: Don't use bcrypt

#77

Post by smacktoward »

tpsreport wrote: post #56
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…

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.

But just the existence of multiple cargo cults causes damage, because it leads people to assume that "the experts are divided." Which will lead some people to go with the wrong batch of experts, and others to just throw up their hands in confusion and store their passwords in plain text because it's too hard for them to figure out which group of experts is right.

This is a case where unanimity in the message is important. If all the experts say "use A," people will take that to mean there's no debate about the merits of A over B and C, and use A. If some say "use A" while others say "use B" or "use C", some fraction of listeners will give up and use nothing at all.

Re: Don't use bcrypt

#78

Post by marshray »

dhimes wrote: post #59
tptacek wrote: post #27

Earlier quoted context omitted.

"Memory hard" is a serious benefit that scrypt actually has. "RSA tested and widely used" is subjective, not particularly meaningful, and in some senses erroneous, and so makes a poor case for PBKDF2. If people want to seriously push for scrypt as a replacement for bcrypt as the "default" function, I'll design and print flags and pennants for the movement. But when people say "use PBKDF2 instead of bcrypt", I think t…

Question: what does "memory hard" mean? Uses lots of RAM to preclude simultaneous connections running attempts in parallel?

By consuming lots of RAM (more than will fit on a single Si die), it means effectively that the defender is able to leverage the economies of scale that go into optimizing the memory bus of his commodity server. This makes it so an attacker who can produce his own chips (or to a lesser extent, use FPGAs or GPUs) has much less of an advantage over the defender.

While CPU speeds, transistor densities, and cache sizes have gone through the roof, the 60-80 ns memory latency of off-chip DRAM has been nearly constant over the last few decades of computing.

"Memory-hard" builds the work factor on that.

Re: Don't use bcrypt

#79

Post by smacktoward »

dhimes wrote: post #67
pleasebehonest wrote: post #55

Earlier quoted context omitted.

That attitude is abrasively condescending. Why not just say, "people who spent a lot of their time studying cryptography strongly recommend this approach. They feel the approach that you are considering is simply insecure."? Framing things in terms of intelligence isn't going to win anyone over, if that's your goal. And it probably isn't accurate, either.

He's probably using "smart" in the sense of "accumulated knowledge in a particular space" instead of in the sense of raw mental horsepower. http://news.ycombinator.com/item?id=3583985

Yes, that's right. It doesn't mean that you are hopelessly non-cognitive if you can't understand the complexities of cryptography. (As I said, I certainly can't.) It just means that unless you are one of the very few people who are 1) exceptionally mathematically talented and 2) able to have spent your entire life studying the subject, it's unlikely that you could make an informed choice.

Re: Don't use bcrypt

#80

Post by tptacek »

pbsd wrote: post #62
tptacek wrote: post #22

Earlier quoted context omitted.

Is there a reason other than branding that you think it's fair to push for PBKDF2 to be the "default" instead of bcrypt?

To be honest, I don't see why anyone would use bcrypt over PBKDF2, if the security of the primitives is of any serious concern. I am new here on HN, so I'm not aware of your arguments on why bcrypt is better than PBKDF2. As for the "branding" question, would you recommend XTEA or MARS or Threefish over AES for someone in need of a block cipher? Of course not. Standards are not always perfect (and many a flaw has been…

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 radiological bits in it. You're not supposed to be messing with those bits. The whole point of the package is not to have random developers changing them.

Also, I want you to note something:

You pick AES not because it's a standard but because it's the product of a contest in which many of the world's best cryptographers competed to design the replacement to DES. That's not what PKCS standards are. A PKCS standard is simply something that survived a standards group discussion.

Post reply on HN