Comment by sillysaurus | Hacker News Reader

Comment by sillysaurus | Hacker News Reader

I know I won't be able to easily convince anyone of this, but I thought I'd mention...

Colin Percival's "scrypt" password hash is:

1) production-ready (and has been for a long time)

2) superior to bcrypt, as it is designed to be expensive in both CPU and memory (hence, scrypt is "memory-hard", whereas bcrypt is not)

I don't have time to go into further detail. I encourage you to check it out. It's quite simply "the future of password hashing". (Bcrypt will be defeated by natural advances in multi-core hardware; scrypt won't ever be.)

Passwords hashed with scrypt with sufficiently-high strength values (there are 3 tweakable input numbers) are fundamentally impervious to being cracked. I use the word "fundamental" in the literal sense, here; even if you had the resources of a large country, you would not be able to design any hardware (whether it be GPU hardware, custom-designed hardware, or otherwise) which could crack these hashes. Ever. (For sufficiently-small definitions of "ever". At the very least "within your lifetime"; probably far longer.)

The usual concern with scrypt is that it has less research behind it. The bcrypt hash function has gone through over twelve years of attempts without being broken in the cryptographic sense. The scrypt hash has only around three years of the same.

I would expect that within 5-10 years, scrypt will be the normal suggestion. It really is much better on the fundamentals, so much so that some experts recommend it even in spite of its relative newness. For the moment, though, there are arguments to be made either way.

You are going to have a hard time finding a professional cryptographer who will look at scrypt and say that it's risky. These are KDFs, not message authentication codes; they aren't risky constructions.

If you have no other choice but to iterate SHA1 many thousands of times, that's still better than what most apps do, and in the grand scheme of things almost "ok".

scrypt is fine. If you have a library that supports it, go ahead and use it.

This is true. In particular, a KDF is in no danger from preimage or collision attacks, which are generally the types that show up.

> If you have no other choice but to iterate SHA1 many thousands of times, that's still better than what most apps do, and in the grand scheme of things almost "ok".

While I won't recommend people simply iterating a hash many times, I also won't slap people down for it anymore. In the grand scheme of things, there are a billion more likely routes of attack than someone breaking your 20000-rounds-of-SHA1 hashes.

Out of curiosity, what do you recommend people use?

If being able to do things with off-the-shelf tools is important, I'd recommend PBKDF2. It can be implemented in a couple dozen lines of code over one of the SHA2 functions, as opposed to Bcrypt which is a completely novel hash function that isn't in most languages' standard libraries.

Much as I like bcrypt/scrypt, I generally just recommend PBKDF2 with a large number of rounds. It's not perfect, but it's more than good enough.

One thing to be careful is that you don't open yourself to a trival DOS. The default scrypt command line program will churn CPU for a full second when encrypting a file. If you use similar settings, it will not take an attacker many connections to reduce even a large cluster to tears.

There are no known good implementation of scrypt in php (http://stackoverflow.com/questions/10149554/are-there-any-ph...) So I don't know how "production ready" that is considering php is the most popular platform for the web as much as I hate the language.

Even opting for bcrypt can be sketchy. Native support only appeared a few years ago, older versions rely on the OS - many of which didn't support blowfish without a patch. Fine if you control the server.

Since most people who face a choice between bcrypt and scrypt will be the ones who are developing new sites or considering a major upgrade to an old site, I don't think they'll care about compatibility with anything older than PHP 5.2. Even if you don't control the server, it's difficult to find a reputable web host nowadays that still runs anything older than PHP 5.2, and your average cPanel host is most likely to support a wide range of crypto functions.

It's not a very good idea to implement cryptography in a high level language such as PHP. Using a high level language opens a whole new world of pain when it comes to side channel attacks. Timing attacks, cache timing attacks and branch predictor attacks are much easier to protect yourself against if you write your crypto algorithms in C or, preferably, Assembly.

C module?

Writing your crypto with C and then calling it from another language such as PHP or Python is fine.

Fyi, scrypt is in the Debian testing and unstable repos [1], and Ubuntu's universe repo [2]. Not sure about the RPM ecosystem, but I'm sure it's available there too. And there are a bunch of bindings and libs in various languages on github as well [3]. And there is always the source [4].

1. http://packages.debian.org/search?keywords=scrypt

2. http://packages.ubuntu.com/search?keywords=scrypt

3. https://github.com/search?q=scrypt&type=Repositories

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

FWIW I included scrypt :)

I personally agree that "Use bcrypt." should become "Use scrypt." soon. My main gripe is that there is far less library support for it, at least for now.

One issue that I have with scrypt and bcrypt for java is that there is no "official" support for the algorithms in java.

When looking at jBCrypt for instance, they're only at version 0.3 with no updates since 2010, makes me really nervous of using it.

How many bugfixes do you think a hash function needs? Just use jBCrypt.

If you try to use the spec'ed 32 rounds the code borks. I fixed it in my own version of jBCrypt.

Supply your version to the jbcrypt website, or host it! If you want to put it up for FOSS.

I think I answered my own question, but I'll ask anyway - why does memory intensiveness matter?

GPUs (and similar hardware) have a very limited amount of memory per core. If computing a hash requires 100MB of memory, then even a 1GB graphics card can only execute 10 cracks in parallel, not hundreds or thousands.

Or the hundreds of millions.

Processors get faster and faster, so we increase the work factor to compensate and keep it a time-hard problem. This has no real restriction on memory though, so the amount of memory only has to grow linear to the amount of time.

Making it memory-hard makes it also memory hard.

> Making it memory-hard makes it also memory hard.

That's a tautology, unless the hyphen means something different.

For a "worst-case" attacker -- one who can fab his own ASICs -- cost is proportional to the area of silicon used. RAM takes up die area, and it's something commodity systems have plenty of.

Basically it's a matter of "what do we have which they would have to pay extra for".

Looking into what Scrypt is? Thanks for the info.

Reply on news.ycombinator.com