Hacker News new | past | comments | ask | show | jobs | submit login

What does "bus factors are bad" mean?

And as long as I'm asking questions, what about bcrypt for password hashing?

"Bus factors" refers to how many people need to get hit by busses before there's nobody left who can work on something. In particular, a bus factor of 1 is a very bad thing to have.

Although it's mitigated somewhat by the fact that Bernstein is passionate and has been a reliable maintainer in the past. "Bus factor" is typically an euphemism for "someone is going to pay this employee more than we do".

I'd call that a cacophonism, though, unless you truly prefer that they get hit by a bus.

AFAIK, bcrypt for password hashing is fine (although Percival has his own scheme that he believes to be better - I can't comment either way).

Last time I asked him, one of the authors of bcrypt considered scrypt to be better, too. :-)

That's a pretty good endorsement :-)

I'm a little confused though. S-crypt seems to be a symmetric encryption algorithm and to store passwords you need a one-way hash. I'm obviously missing something. What is it?

scrypt is a key derivation function. As a demonstration of how to use it, I wrote a simple file encryption utility.

I see. Is there some documentation for the key derivation function that I missed? Or are we supposed to reverse-engineer the file encryption code to figure out how to use the the KDF? If the latter, that seems a little odd in light of the fact that you're actively promoting scrypt as a replacement for brcrypt and the concern you've expressed about people using crypto code incorrectly. I do not mean to imply that you are under any sort of obligation to provide documentation. But it seems to me that your stated purposes would be better served if the interface to the KDF were documented.

The scrypt key derivation function, defined: http://www.tarsnap.com/scrypt/scrypt.pdf

Oh come on, give me a little bit of credit here. Where is the scrypt key function defined? What is its signature? Are there any initialization functions that need to be called before calling scrypt?

Yes, I can figure all this out by reverse engineering the code. But is that really what you intend people to do? Even just a couple of sentences of documentation would save a lot of people a lot of head-scratching, e.g.:

"The scrypt key generation function itself is called crypt_scrypt. Its signature is in lib/crypto/crypto_script.h. The reference implementation is in crypo_script-ref.h. There are two optimized implementations, one for CPUs that have SSE support, and another for ones that don't. You don't have to call any initialization functions before calling crypto_scrypt."

Or something like that. If your goal is really for people to use this I think you'd see a pretty large ROI from the effort it would take you to write a paragraph like that and stick it in a README file in the distro.

Just a suggestion.

Oh, you mean "where is the interface to this implementation of the scrypt KDF?"

I thought you were asking where the function itself was defined -- which, as I said, is in the paper.

Let me try to be excruciatingly precise here: you seem to be advocating scrypt for use as a password hash, but your implementation only provides file encryption functionality out of the box. To convert the code you provide to produce and verify password hashes requires some uncommon expertise because there are, as you yourself so often take pains to point out, many ways to get it wrong. My question is: is there some documentation that you have provided to make this task easier that I have overlooked? And if the answer is no, why not? It seems very odd for you to 1) advocate scrypt for use as a password hash, 2) caution people against writing their own crypto code, and then 3) provide neither the code nor the guidance necessary for a software engineer who is not already an expert in cryptography to actually use scrypt as a password hash.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact