Password space is quiet small. Therefore slow hash should be applied to password before using it for encryption.

Should slow hash function (like bcrypt) be applied to password before using it with OpenPGP/GnuPG? Do they do it itself?

  • 1
    Gpg does apply strengthening (controlled by the --s2k-* options, defaulting to an 8-byte salt and 65536 rounds of its KDF; I don't know what the KDF is). I would hope that OpenPGP does something similar. – Gilles 'SO- stop being evil' Jun 2 '12 at 22:52

Yes. When encrypting a file using a passphrase, they should use a slow hash function to derive the cryptographic key from the password.

Yes, GPG already does do this. See my answer that explains elsewhere how to use GPG with a slow hash, if you need to encrypt a file with passphrase-based conventional encryption. The short version is that I recommend using the following command-line flags:

gpg -c --force-mdc --s2k-mode 3 --s2k-count 65011712 personal.zip

This asks GPG to use a slow hash function for hashing the password.

| improve this answer | |
  • Hash functions supported by GnuPG can be too efficiently automated at GPU – Andrei Botalov Jun 4 '12 at 11:55
  • 1
    @AndreyBotalov, you already wrote that once before. What you may be missing is that GPG's slow hashing scheme (using iterated hashing) does mitigate the effects of GPU-acceleration of hash functions. The existence of GPU-acceleration for cryptography makes it all the more important to use slow hashing (such as GPG's scheme, or PBKDF2, etc.). You are right that GPUs can accelerate hash computation, but I think you are mis-interpreting the implications of that fact. This fact does not mean that GPG's scheme is flawed. GPG's scheme is fine. – D.W. Jun 4 '12 at 16:38
  • 1
    GnuPG's slow hashing scheme doesn't fully mitigate GPU acceleration. – Andrei Botalov Jul 17 '12 at 8:09
  • 3
    @AndreyBotalov, thanks, that's a good link and very helpful! I think what you are suggesting is that GPG would be even better off to use scrypt or bcrypt. Agreed. That's a good point. (On the other hand, keep in mind the last paragraph of the answer you link to: S2K is much better than a simple non-iterated hash, though I agree bcrypt or scrypt would be even better.) – D.W. Jul 17 '12 at 9:30
  • 1
    What about adding --s2k-digest-algo SHA512 so that the algorithm iterated 65011712 times is more costly? – fgrieu Jul 25 '17 at 17:30

OpenPGP implementations apply hashing of password during S2K process. They allow to tweak algorithm and number of iterations.

By default GnuPG 1.4.12 uses SHA1 for hashing with 65536 rounds. Algorithm can be switched to MD5, RIPEMD160 or SHA2s. Number of iterations can be changed too. Current settings can be viewed by typing gpg --list-packets ~/.gnupg/secring.gpg

However all suported by GnuPG 1.4.12 algorithms can be efficiently implemented on GPU. And thus aren't the best options for password hashing.

It will be better to use bcrypt or scrypt instead --s2k-* GnuPG options. As they aren't supported by GnuPG you can use side implementation of it.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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