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?
$\begingroup$
$\endgroup$
Add a comment
|
2 Answers
$\begingroup$
$\endgroup$
3
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.
answered Jul 16, 2012 at 23:42
-
1$\begingroup$ Just some trivia but note that GPU's that support 64-bit arithmetic (most recent ones) are still monstruously fast at it - in the very worst case it's a 4x slowdown over 32-bit arithmetic and it's usually closer to 2x. A hash using 128-bit arithmetic would be considerably more painful for GPU's to work with as the general carry operations that have to occur don't map so well to SIMD vector instructions (making it more difficult to vectorize the compression function). $\endgroup$– ThomasJul 17, 2012 at 7:20
-
$\begingroup$ Unfortunately I feel we will continue to see unsalted hash and even raw password storage in the wild for as long as software engineering remains an unlicensed profession without criminal penalties for getting this wrong. $\endgroup$– RomanStOct 10, 2012 at 23:15
-
1$\begingroup$ @Thomas Are there any hashes that even use 128-bit arithmetic? $\endgroup$– forest ♦Apr 22, 2018 at 8:37
$\begingroup$
$\endgroup$
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.
