7

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?

Andrei Botalov
  • 5,317
  • 10
  • 46
  • 73
  • 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 02 '12 at 22:52

2 Answers2

8

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.

Community
  • 1
D.W.
  • 98,860
  • 33
  • 271
  • 588
  • 1
    Hash functions supported by GnuPG can be too efficiently automated at GPU – Andrei Botalov Jun 04 '12 at 11:55
  • @AndreyBotalov, I know, and that's one kind of threat that GPG's slow hash function is designed to mitigate / defend against. Those threats make it all the more important to use a slow hash function. – D.W. Jun 04 '12 at 16:11
  • GnuPG's functions used for password hashing are MD5, SHA1, SHA2s, RIPEMD-160 with large number of rounds. They **can** be computed efficiently at GPU. – Andrei Botalov Jun 04 '12 at 16:32
  • 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 04 '12 at 16:38
  • 1
    GnuPG's slow hashing scheme [doesn't fully mitigate](http://crypto.stackexchange.com/a/3255/1516) GPU acceleration. – Andrei Botalov Jul 17 '12 at 08: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 09: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
2

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.

Community
  • 1
Andrei Botalov
  • 5,317
  • 10
  • 46
  • 73