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.
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.