Hacker News Reader

Comment by tptacek | Hacker News Reader

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.

View on HN

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

scrypt deliberately uses lots of memory in addition to CPU, which makes it much harder to parallelize using a GPU

Recommendation for 4096R is caused by the fact that it is both reasonably secure and widely supported at same time.

I think 4096 bit RSA is a little silly, but in a normal GPG setting it doesn't matter; do whatever makes you feel best.

Why is it silly? 2048 bits RSA isn't even 128 bits level, and lots of software makes it easier to use 4096 bits keys than 3072 bits ones.

The thing that puts RSA-2048 in reach of attackers is going to eliminate RSA altogether.

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.

Why prefer BoringSSL over LibreSSL?

LibreSSL removed a significant portion of the optimized ASM from OpenSSL. This means that for key operations it is significantly slower.

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.

But people won't use slow code. Look at RSA-1024 on DNSSec.

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.

It's cute that you think people review crypto C code.

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.

I don't have a strong preference between the two, but have more insight into who's doing crypto work on BoringSSL than I do on LibreSSL.

Reply on news.ycombinator.com