Spoiler: the default SSH RSA key format uses straight MD5 to derive the AES key used to encrypt your RSA private key, which means it's lightning fast to crack (it's "salted", if you want to use that term, with a random IV).
And a mere four years later they added a format that uses bcrypt... in a PBKDF2 construction? (I haven't found a motivation why, though Ted Unangst's post on it just says "I know about scrypt".)
It has a time space difficulty curve that's more complex, but some people like that. I will stipulate scrypt is "better" if I don't have to argue about it. :)
As an aside about scrypt since I saw it mentioned here:
How does scrypt fair against the recent TLBleed etc? Iirc intels claim was that TLBleed only affected poorly implemented crypto. But is not the memory access pattern of scrypt vulnerable to TLBleed and hard to make constant access?
OT: This is why I still come to HN. At some point the top comment chain is by tptacek (Matasano), cperciva (Tarsnap founder), lvh (Latacora), tedunangst (OpenBSD dev), willvarfar (Mill CPU). And that's a great thread!
My first guess would be that it has "too many parameters/knobs". I guess that could implicitly mean it's hard to use/easy to mess up if you don't know what each parameter means and what different values have.
I guess the same. Not sure why the downvote. The latest crypto functions expect the developer to pick parameters for the memory usage, the time to run and god knows what.
Too low and it's worse than MD5, too high and your login prompt takes a whole minute to check the password.
Indeed, I pointed this out in my May 2009 talk about scrypt (http://www.daemonology.net/papers/scrypt-slides.pdf). There were even OpenSSH developers in the room!