2
$\begingroup$

GnuPG on-disk storage of secret key material is encrypted with AES-128, with an encryption key generated via an iterated and salted SHA-1 hash of the given passphrase.

Is this usage of the SHA-1 hash function secure, and, if so, will it remain secure, even in the distant future?

|improve this question
$\endgroup$
  • $\begingroup$ It doesn't just use raw SHA-1, but its own KDF called S2K. $\endgroup$ – forest May 19 '19 at 23:23
  • $\begingroup$ Although S2K's idea of iteration is to repeat the input data (salt+pw) not the whole hash or HMAC function as other PBKDFs usually do. AES-128 and S2K#03+SHA1 are the current GnuPG default, but weren't in the past, and can and could be overridden. $\endgroup$ – dave_thompson_085 May 20 '19 at 6:05
2
$\begingroup$

It is likely secure, yes, when it comes to SHA-1.

The S2K function, as you mention, simply repeatedly inputs the 8-byte salt and encoded passphrase into the ongoing hash function until a certain number of bytes has been processed (the work factor for this function). Then it produces a key that is smaller than the hash output size.

Now this output is an AES key, and we can assume that this key cannot be retrieved, nor is it stored. As you control the salt and secret key, it is impossible to use the collision weakness of SHA-1: even a collision in the output of S2K would be useless. Similarly, a pre-image attack on S2K is useless as well, as the output of the S2K hash is simply not available.

The only possible issue could be that SHA-1 is shown to have such short cycles that multiple inputs could produce the same S2K output. In that case it might be easier to find a matching input, as multiple input values would match. But there is the salt, the relatively short password, the high cycle size of SHA-1 etc. that makes this highly unlikely; this is really grasping at straws.

That all said, S2K is far from perfect. SHA-1 is easy to put in hardware (if it is not already there in current CPU's), S2K doesn't use memory to make e.g. hashing password on a GPU or other specialized hardware tough.

The biggest weak point is and remains the password. I'd rather spend my time making sure that the user is pushed really hard to use a strong password. Because if the password is much smaller than 50 bits then all the cryptography in the world is not going to matter.

Dictionary / brute force attacks on the password will always be more efficient, basically. Spend your time avoiding those.

|improve this answer
$\endgroup$
  • $\begingroup$ But if the users uses a ~256 bit true random number as a password (100 dice rolls, shuffled 52 card deck, etc.), is the S2K of any use at all? Shouldn't a simple SHA1(nonce||passphrase) be enough? $\endgroup$ – user3368561 May 20 '19 at 19:27
  • 1
    $\begingroup$ Oh, in that case you don't even need the nonce (although it takes a lot of practice to actually shuffle a card deck properly, but yeah). However, you'd need some way of keeping the password secure, as it is unlikely that you're going to remember it. Personally I like using a password DB with a very hard to guess main password, because there is a snowflake's chance in hell that I'm going to remember them all. Such a long pw often requires a very good typist or a password preview, which allows shoulder surfing etc. Can be rather impractical. $\endgroup$ – Maarten Bodewes♦ May 20 '19 at 19:35
  • $\begingroup$ Well, you can always use a pin protected smart card for everyday use and the impossible-to-remember password only for backup purposes... which is my case. $\endgroup$ – user3368561 May 20 '19 at 20:22

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.