Yes, Bernstein has written code for Poly1305; but bus factors are bad. If you decide to use Poly1305, at some point you're going to want to use it on a new CPU or in a different language, and you'll find that DJB's code won't work for you.

You should avoid blowfish because it has a 64-bit block size.

Okay, I can see that. Most of Bernstein's crypto work falls in that category, probably.

Forgive my ignorance, but why is having a short block size especially bad? You don't want to subject 64 bits to a birthday attack, but something like CTR mode should work, right? (I still wouldn't recommend Blowfish - AES is used more widely and works perfectly well - I'd just like to understand your reasoning).

With a 128-bit block, you can send 2^64 messages of up to 2^64 blocks each; that's not going to cause problems. With a 64-bit block, you're limited to 2^32 messages of up to 2^32 blocks before you overflow.

Poly1305 is a fundamentally different class of authenticator than HMAC-SHA256: the addition of an nonce into the function makes it unsuitable for some environments. But given Intel's new instructions, GCM is looking like a more attractive polynomial MAC these days.

Why would you take GCM over OCB (apart from patents)? Or, for that matter, OMAC/EAX?

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.