Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

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

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

share|improve this question
add comment

2 Answers 2

up vote 8 down vote accepted

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.

share|improve this answer
    
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). –  Thomas Jul 17 '12 at 7:20
    
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. –  romkyns Oct 10 '12 at 23:15
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.