Hacker News Reader

Comment by JoshTriplett | Hacker News Reader

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

Using which of the many TLS implementations?

View on HN

What's the reason to prefer scrypt over bcrypt?

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

(FYI: https://vuxml.freebsd.org/freebsd/pkg-gnupg.html )

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

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

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.

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.

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.

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

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.

scrypt is also "space hard"

I guess bcrypt is harder by default than PBKDF2

> scrypt is also "space hard"

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?

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.

Reply on news.ycombinator.com