Is bcrypt better than GnuPG's iterated+salted hashing method?

Question

GnuPG has slow hash built-in in form of iterated+salted S2K.

Does it have disadvantages in comparison with bcrypt or scrypt? Is GnuPG's slow hash method easily automated in GPUs?

Answer 1

OpenPGP's "Iterated and Salted S2K" is just a single hash instance over a very long input, which consists in the repeated concatenation of the salt and the password. This is extremely GPU-friendly, especially when using a hash function which is built over 32-bit elementary operations (this category includes MD5, SHA-1, SHA-256 and RIPEMD-160; GPU are not as good at dealing with 64-bit operations, e.g. SHA-512). Consequently, an attacker will get a good boost out of GPU when trying to attack a password which has been processed with that key derivation function.

Note that this puts S2K in the same category than PBKDF2: although their internal structures differ quite a lot, they have similar usage patterns on the hardware. Comparatively, bcrypt and scrypt need much more fast access RAM, which puts GPU at a disadvantage. Bcrypt still fits in a few kilobytes of RAM, hence is still susceptible to optimizations through FPGA; scrypt looks even better, but it is shiny because it is new, which is not a good thing in cryptosystems (like good wine, good crypto must wait a few years for optimal quality; see this answer for a more thorough discussion).

Let me stress out that, in practical terms, OpenPGP's S2K (or, for that matter, PBKDF2) very rarely turns out to be the weakest part of a given system. For all its shortcomings, S2K is much better than a simple non iterated hash-with-salt, and a fortiori an unsalted hash invocation, as is unfortunately still commonly encountered in deployed applications.

Answer 2

Most hash functions ( it appears this includes S2k) are not memory intensive. As such you can run a bunch of computations of their iterated variants on a GPU very cheaply.

Scrypt, however, is designed to be memory intensive, so you can't really run it effectively in parallel without huge memory requirements.