> > Could you make a recommendation for or against using GPG, since that's by far the most common approach for asymmetric signatures?

> Avoid if possible. The code was written by a colony of drunk monkeys, in an era before anyone understood the basics of modern cryptography; I'm really not sure which is worse between gnupg and OpenSSL. Of course, GPG is the standard for encrypted email, just like SSL/TLS is the standard for web sites, so you may have no choice...

Do you have any recommendations for high-level alternative for GPG, i.e. something that can secure data easily at rest. Is there something that wraps e.g. NaCL with file IO in a nice commandline utility?

At work we are occasionally using 7zips encryption ability, but somehow I don't really have high confidence in it. But at least the UI is simple enough.

The scrypt encryption utility (http://www.tarsnap.com/scrypt.html) is pretty simple, but it does what you are asking.

That's symmetric encryption using a passphrase though. Since he mentioned GPG I assume he's looking for public-key encryption.

> Avoid if possible. The code was written by a colony of drunk monkeys, in an era before anyone understood the basics of modern cryptography; I'm really not sure which is worse between gnupg and OpenSSL. Of course, GPG is the standard for encrypted email, just like SSL/TLS is the standard for web sites, so you may have no choice...

Are there any viable FOSS implementations of the OpenPGP standard other than GPG? Detached GPG signatures seem to be the most common mechanism to validate software distribution and similar.

Has anyone checked https://github.com/google/end-to-end ? I want to believe google did their due diligence.

Go's crypto/openpgp package (http://golang.org/x/crypto/openpgp) is probably one of the closest "full" implementations, although it's a library and not a CLI binary.

> scrypt is asymptotically much more expensive to crack.

How so? The cost of password cracking generally scales completely linearly, is there an attack on bcrypt that makes the cost sublinear? I would agree that scrypt probably has a better constant factor on typical hardware.

scrypt is deliberately designed to use a large amount of memory when calculating hashes, which makes it much more difficult to parallelize using a GPU (which don't have much RAM available), hence making it much much slower to attack.

scrypt cracking is still embarrassingly parallel even if it's hard to run on a GPU. I understand the term "asymptotically more" to refer to big O notation, where constant factors like that are ignored.

Well it's hard to state what exact n is here, but you'd probably be increasing both the calculation time and memory requirements at 2^n, so you need roughly 1/k of an entire computer to calculate even as Moore's law marches on and factors increase, but PBKDF2 parallelizes more and more.