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

121–130 of 193 posts

Re: Don't use bcrypt

#121

Post by tptacek »

pbsd wrote: post #112
tptacek wrote: post #95

Earlier quoted context omitted.

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…

You're right, I do recall that passage. Apologies if I sounded patronizing. I tried to be careful with the wording, precisely to avoid making a common-sense statement into a controversy. Yes, block ciphers are more well-studied (2012-70s > 2012-80s). My point was that the gap is much smaller now than (say) when AES was standardized (I wonder, was that passage also in the "Practical Cryptography" 2003 book?). As a per…

No problem. I think you probably know this stuff better than I do. In practice, I think PBKDF2 really means "PBKDF2/SHA2", and that in 5 years attacker tools will be most efficient for PBKDF2/SHA2, less efficient for bcrypt, least efficient for scrypt, and won't address PBKDF2/AES-256-CBCMAC at all because nobody will know how to code it.

Re: Don't use bcrypt

#122

Post by cdavidcash »

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…

Cryptographic hash functions, by contrast, are not well understood at all. They are "magic" in many ways, and aren't modeled after anything. Many more "bad things" happen in this space than in the block cipher space.

Is this a common opinion amongst practitioners? The opposite philosophy (e.g., that a random oracle is a "weaker object" than an ideal cipher) underlies some lines of work in the theoretical cryptography literature.

Re: Don't use bcrypt

#123

Post by icebraining »

SoftwareMaven wrote: post #39
yock wrote: post #18

Earlier quoted context omitted.

No, ad hominem is "You're wrong 'cause you're a jerk." DanBC pointed out that their opinion might not be as above reproach as is often assumed because of past lapses in good judgment.

Ad hominem is an attempt to negate the truth of a claim by pointing out a negative characteristic or belief of the person supporting it. [1] That sounds pretty much like what happened above. The truth item is whether RSA's cipher chops can be respected. The negative characteristic is an HR person succumbing to a social engineering attack. Ad hominem isn't just calling names. Let me put it differently: in what way doe…

Ad hominem is an attack on the person whose argument you're trying to disprove. Here, that person is the one who wrote the article, not RSA.

The argument "X is safe because its creator, Y, has a good reputation" can certainly be refuted by attacking the claim that Y has a good reputation. It's not an ad hominem.

The fact that the error by the HR person doesn't actually invalidate RSA's reputation as cryptographers is more a Non sequitur.

Re: Don't use bcrypt

#124

Post by specialist »

FaceKicker wrote: post #110
specialist wrote: post #99

Earlier quoted context omitted.

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 cr…

Regardless of what you think of the kind of people who the government would contract to develop electronic voting machines, I don't think I'd call them "laypeople". Or are you saying that every individual voter needs to understand the inner workings of the system for it to be effective?

Or are you saying that every individual voter needs to understand the inner workings of the system for it to be effective?

Um, yea. That's what "public vote count" means.

As for the technical competence of our nation's election administrators, have you not been paying attention? I've met many many. Great at elections. Terrible at computers. Completely and utterly reliant on the vendors. Who've manifestly demonstrated their complete inability to code their way out of a wet paper bag, much less be entrusted with the foundations of our democracy.

Re: Don't use bcrypt

#125

Post by marshray »

JoachimSchipper wrote: post #114
marshray wrote: post #94

Earlier quoted context omitted.

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 co…

You're right, but don't forget Deep Crack. (FPGA-)hardware-based attacks have only become cheaper since then; I would be surprised if the NSA doesn't have a few arrays. (Also, 80 bits is usually enough to withstand attack, no?)

Yep. There are off-the-shelf FPGA arrays available. Still, bad guys would probably find it much cheaper to rent botnet time for a $0.02/(host*day) or whatever the going rate is.

A solid 80 bits of security out of any of these functions might turn out to be safe forever. But, in practice, most password databases are going to have some fraction of users choosing passwords straight out of the cracker's dictionary, some fraction that will never ever be cracked, and the smallest fraction being crackable according to the defender's choice of work factor.

Re: Don't use bcrypt

#126

Post by funkah »

tptacek wrote: post #35
lhnn wrote: post #6

Earlier quoted context omitted.

As stated in the article, a popular stance on Hacker News and Stack Overflow is "USE BCRYPT". It's chanted to crypto-noobs and webdevs as a simple-to-use library for password storage that is more secure than MD5/SHA/Whatever hashing, and with built-in salts. The whole point of this article is to say that, in fact, there are other options.

Bullshit. There is one very-well-written article at Coda Hale's site that says "just use bcrypt", but in discussions of adaptive hashing on HN, people who know what they're talking about are continuously at pains to vouch for PBKDF2 and scrypt (it helps that one of the people who knows what they're talking about on this subject is (a) vocal on HN and (b) designed scrypt). It irritates me that despite going through th…

Raises hand

It's important to know what you don't know. And I know enough about crypto to know that I don't know anything and should listen to people who do.

Re: Don't use bcrypt

#127

Post by cheald »

zobzu wrote: post #88
regularfry wrote: post #61

Earlier quoted context omitted.

When we were looking at password hashing, and the choice came down to bcrypt or scrypt (about a year ago, so recently enough), I said we should go for bcrypt because scrypt was comparatively new; inasmuch as it makes a difference, it's just had less time to be attacked. Was I wrong?

its a sane decision. just make sure you implement properly. like everything crypto, it will be broken, eventually. but its a safer choice than a new algoritm. it reminds me of the vulnerability issues. when apps have no known vulnerabilities, all is fine. when a new "instant root compromise of any system" comes out, its omgomgomg. Then its fixed, and all is fine again. Except that vulnerability was always there. And…

This is a naive attitude. Mathematically-secure cryptography with an implementation that avoids all side-channel attacks is unbreakable, as in, would take more time than the projected heat death of the universe to brute force.

That's not to say that all implementations are secure, or that there are not undiscovered mathematical flaws in common algorithms, but the idea that all encryption is brute-forcable given enough AWS instances is just plain incorrect.

Re: Don't use bcrypt

#128

Post by drivebyacct2 »

bascule wrote: post #117
JoachimSchipper wrote: post #116

Earlier quoted context omitted.

Why? "Use bcrypt" is boring from a crypto-nerd point of view, but it's a really useful meme.

I thought I explained that in my blog post. scrypt is superior to bcrypt in every regard. At the very least, I'd rather the meme be: Use bcrypt, scrypt, or PBKDF2.

Which is fine, but you've clearly dressed it up as flamebait "don't use bcrypt" outright.

Re: Don't use bcrypt

#129

Post by marshray »

tptacek wrote: post #102
marshray wrote: post #100

Earlier quoted context omitted.

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.

So, I agree, but am happy he took the time to comment and (reasonably) concerned that his comment would be buried somewhere in the bottom third of the thread. I'm appealing to high quality comments, not authority.

HN needs a way for us to take subthreads for this kind of meta-discussion and fork them into another dimension.

Re: Don't use bcrypt

#130

Post by cperciva »

marshray wrote: post #94
marshray wrote: post #71

Earlier quoted context omitted.

> 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 co…

The Scrypt x5000 seems to only apply when your attacker has access to a chip foundry

If your attacker is using GPUs, scrypt probably gives you an even bigger win, due to the compute/memory balance they use.

Post reply on HN