
Bcrypt is now obsolete - cperciva
http://www.daemonology.net/blog/2009-05-09-scrypt-key-derivation.html
======
tptacek
If you could come up with a less bait-y title, I'd agree with you. :)

We'd use the term "adaptive hashing" or (less accurately) "key strengthening",
but it wouldn't be actionable. Bcrypt is actually still current, since very
few stable implementations exist for your algorithm, and you are surely not
recommending people implement their own crypto.

It's good work though, and I look forward to recommending it, when it becomes
reasonable to do so.

~~~
zackattack
I think we should do something about the bait-y titles on HN in general.
Titles should be descriptive and succinct.

Maybe a better title here would have been "bcrypt's use of MD5 makes it
insecure compared to scrypt". (I don't know how to best word the title; I
would have not submitted the article, since I'm not an expert on security.)

~~~
davidmathers
_I think we should do something about the bait-y titles on HN in general.
Titles should be descriptive and succinct._

Sometimes the same story is posted multiple times. One post will have a bait-y
title and the other will have a boringly accurate and truthful title. Of those
two, one of them always disappears with 3 or 4 votes and the other climbs the
front page charts. Exhibit A:

    
    
      A Comparison of Approaches to Large-Scale Data Analysis: MapReduce vs. DBMS
      vs.
      Parallel DBMSs faster than MapReduce
    

Then there are the science articles with accurate titles and hypetastic
titles. Exhibit B:

    
    
      Long-Distance Teleportation Between Two Atoms Achieved
      vs.
      Scientist Teleport Matter More Than Three Feet
    

So, it's not like the descriptive titles aren't already there waiting to be
promoted, it's just that hyperbole always wins in the marketplace of up-arrow
clicks.

------
Tichy
I don't know this guy. Probably he is really famous (?), but I'd rather wait
until his scrypt sees widespread adoption before I follow his lead.

~~~
cperciva
_I don't know this guy._

You do now. :-)

~~~
Confusion
Has anyone besides yourself yet vetted this 'key derivation function' (and
perhaps you wouldn't mind shortly explaining the difference between a KDF and
a cryptographic hash function)?

~~~
cperciva
_Has anyone besides yourself yet vetted this 'key derivation function'_

Not yet.

 _perhaps you wouldn't mind shortly explaining the difference between a KDF
and a cryptographic hash function_

Cryptographic hash functions produce fixed-length collision-resistant output,
ideally as fast as possible. KDFs can normally produce arbitrary lengths of
output, and don't need to be fast -- in fact, being fast is a disadvantage,
since secure KDFs are expensive to compute (because they need to resist brute-
force attacks).

------
asmosoinio
A side note: The name "scrypt" is no so good in terms of googling. A search
for example for "scrypt python" brings up over 7 million hits for Python scr
_i_ pt. Maybe once more pages about scrypt exists it will stand up, but anyway
the name could be more unique.

~~~
whatusername
Try this.. <http://www.google.com/search?q=%22scrypt%22+python>

Search for "scrypt" python

~~~
asmosoinio
I know, but it brings 2710 results, and I am pretty sure the link to my and
your comment (number 5 and ~15 in Google) are the only one related to this
derivation function.

------
amix
It's stated that scrypt is 4000 times harder to break than Bcrypt (I don't
know how this is calculated, so it's probably an estimate). Given that
password cracking can be easily parallelized is this enough of an improvement?

~~~
lisper
Did you read the paper? The whole point of the thing is to make it non-
parallelizable. That's what makes it hard.

~~~
amix
I did not read it, but I can't imagine what would prevent an attacker from
running a parallel attack on multiple circuits/computers that aren't sharing
any resources...

~~~
dfranke
The idea is to make the KDF expensive in space as well as time. While bcrypt
costs a few seconds of CPU time, it uses only a tiny amount of RAM, thus
underutilizing the resources you have available. Thus, you can parallelize an
attack using lots of specialized ASICs but only a commodity amount of storage.
Scrypt would require you to purchase lots of RAM for every ASIC, making a
brute force attack much more costly.

~~~
cperciva
_Thus, you can parallelize an attack using lots of specialized ASICs..._

More to the point, you can parallelize attacks on most KDFs by building an
ASIC with many copies of a password-cracking circuit. With scrypt, the vast
majority of the IC area (and thus cost) is RAM.

------
utnick
_this means that a five-character password using scrypt is stronger than a
ten-character password using openssl._

Not a crypto expert, but don't most people crack passwords by just running
common words or every possible combination of N characters through your
encryption system, therefore as long as your encryption mechanism is _good
enough_ it doesn't matter what you use?

~~~
pmjordan
Not a crypto expert either, but I took this to mean that each attempt in a
brute force attack is orders-of-magnitude more costly, so that trying all
combinations of 5-character scrypt passwords takes as long as trying all
10-character combinations with bcrypt.

~~~
cperciva
That's almost correct. Replace "takes as long as" with "costs as much as" and
you'd be exactly right.

Basically what it comes down to is that with bcrypt (and all the other widely
used KDFs) it's vastly cheaper to attack the KDF with a custom circuit than it
is to buy general-purpose computers and run a software key cracker. With
scrypt the advantage that TLAs with ASICs have is much smaller.

------
brl
Since you have an implementation I don't have to manually extract from a
library deep inside the OpenBSD source tree I think I'm going to take a look
at replacing bcrypt in an application I'm working on.

------
jwr
I would really like to see Bruce Schneier's opinion on this.

~~~
brl
He called it pointless 'security theater' and recommended using a faster
algorithm like MD5 to reduce delays at security checkpoints since terrorists
will just print their own boarding passes anyways.

~~~
Confusion
He would call it that _when applying this solution to that specific problem_.
In general, I don't think he would say that when the proposal is that people
should use scrypt to hash the passwords they store.

