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...
> 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.
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.
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.
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.
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.
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.
I guess bcrypt is harder by default than PBKDF2
Makes sense, thanks.
> I guess bcrypt is harder by default than PBKDF2
Does that imply that software using PBKDF2 is equally safe if it turns up the difficulty?
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?