> Password handling (Was: scrypt or PBKDF2): In order of preference, use scrypt, bcrypt, and then if nothing else is available PBKDF2.
What's the reason to prefer scrypt over bcrypt? And, what's the reason to prefer both over PBKDF2? (Asking because I see quite a few bits of software that use PBKDF2.)
> Asymmetric signatures (Was: Use RSASSA-PSS with SHA256 then MGF1+SHA256 yabble babble): Use Nacl, Ed25519, or RFC6979.
Could you make a recommendation for or against using GPG, since that's by far the most common approach for asymmetric signatures? (Obviously such a recommendation would need to point at specific key/algorithm choices to use or avoid.)
> Client-server application security (Was: ship RSA keys and do custom RSA protocol) Use TLS.
scrypt is asymptotically much more expensive to crack.
And, what's the reason to prefer both over PBKDF2?
scrypt is asymptotically much more expensive to crack.
bcrypt is asymptotically marginally more expensive to crack than PBKDF2, but not enough to matter; I'm guessing tptacek's point here is that bcrypt has more library support available (despite PBKDF2 being the de jure standard). I wouldn't say there's a strong argument in either direction.
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...
> > 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.
> 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.
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.
scrypt has nice properties that bcrypt doesn't, and gets those properties by design; it turns out that in practice right now bcrypt has some nice properties too, though they seem accidental. We're using scrypt at Starfighter, even though we have to go through a (very minor) bit of trouble to get it. They're all fine though.
If using GPG means you can delegate away all your crypto design, use GPG. What you should not do is roll your own by co-opting all of GPG's design decisions, some of which are not great.
You should use BoringSLL, LibreSSL, Go crypto/tls, or OpenSSL, in roughly that order.
> scrypt has nice properties that bcrypt doesn't, and gets those properties by design; it turns out that in practice right now bcrypt has some nice properties too, though they seem accidental.
Can you elaborate on what you mean by "nice properties"?
> If using GPG means you can delegate away all your crypto design, use GPG.
Using which key types, ciphers, etc? The most common recommendation seems to be for 4096R keys and SHA2 hashes; the latter is consistent with the recommendations posted here, but the former seems to disagree with the comment to not use RSA for asymmetric crypto.
Fair point, but if I were to use RSA (sure, better avoiding it at all), I'd still go into a 4096 bits key, hoping to outsurvive the algorithm long enough for a safe migration.
Anyway, I don't get your (as in most security experts) aversion to long keys and multiple algorithms. As an engineer, I see cryptography taking a very small amount of the resources, but holding a huge share of the risk of any security application. My guts are always pointing into moving more resources into crypto.
Optimized ASM means code that only very few people are able to review, and only with considerable time and effort.
If security is the primary concern, I would argue that optimized ASM becomes a liability.
I had to read parts of OpenSSL to figure out how some of the utilities worked. Let me say that it's wonderful that people are trying to write a more readable version and leave it at that.
If speed was a motivating factor, DNSSEC would be using fast curves instead of archaic RSA. The reality of DNSSEC is that it's built around the performance concerns of 1997.
One of the reasons nobody has mentioned yet is that bcrypt ignores everything after the 56th character in the password. Not many people have passwords that long, but it's still relevant.
As I understand it, this depends on the what the attacker has. If they have a FPGA or GPU, you need many rounds of PBKDF2. If you use scrypt, which was designed by cperciva to negate some of the advantages of FPGA and GPU, you don't need so many rounds to keep it hard to crack. Use https://hashcat.net/oclhashcat/ to benchmark.
What's the reason to prefer scrypt over bcrypt? And, what's the reason to prefer both over PBKDF2? (Asking because I see quite a few bits of software that use PBKDF2.)
> Asymmetric signatures (Was: Use RSASSA-PSS with SHA256 then MGF1+SHA256 yabble babble): Use Nacl, Ed25519, or RFC6979.
Could you make a recommendation for or against using GPG, since that's by far the most common approach for asymmetric signatures? (Obviously such a recommendation would need to point at specific key/algorithm choices to use or avoid.)
> Client-server application security (Was: ship RSA keys and do custom RSA protocol) Use TLS.
Using which of the many TLS implementations?