Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Possible Duplicate:
Tool for public key cryptography where password is the private key?

I was wondering if you guys could clue me in to potential problems with using a hashed password as the seed for GPG's key generator. As far as why someone would ever want to do this, I can see two advantages:

  1. Using a human-memorable password would eliminate the need to store the key on disk, protecting you from identity theft in the event of data theft.
  2. Since the user's memory contains everything needed to regenerate the key, you don't need to worry about [electronic] data loss. Dementia still applies.

As Stephen pointed out, reason 1 is weak because password protected RSA keys also have that benefit. And RAM would still be vulnerable, but that's much harder to gain access too, right? But assuming people aren't great about backing up (they aren't) and reason 2 is valid, are there potential systemic problems with using a hash as a RNG seed?

share|improve this question

marked as duplicate by Jeff Ferland Oct 20 '12 at 18:53

This question was marked as an exact duplicate of an existing question.

When you say, "...using a hashed password as the seed for GPG's key generator", do you mean that you'd enter that hash as the password that you're asked to enter during the gpg --gen-key interactive dialog? Or do you mean that you'd somehow use that hash as the random seed that GPG needs during the actual key generation? – Luke Sheppard Oct 20 '12 at 6:24
The latter, because the former still depends on data stored on your computer (external to the user's memory). – Calder Oct 20 '12 at 6:41
up vote 0 down vote accepted

Digested passwords only have as much entropy as was in the password passed to the hashing function. GPG uses cryptographic sources of random numbers to generate the private key, and encrypts it with a user's password. This ensures that the encryption algorithms are allowed to use a key with maximum entropy, but also prevents a user's key from being compromised in the event of data theft.

It's the best of both worlds, really.

share|improve this answer
Ok, so I guess the second advantage is that you're protected from data loss. From a lay user's standpoint, if public key cryptography were used instead of an authentication system, it would be extremely frustrating to get locked out of an account despite remembering your "password". – Calder Oct 20 '12 at 5:04
Which is one of the reasons why raw public key cryptography has been a non-starter for general authentication. – Stephen Touset Oct 20 '12 at 5:12
Keep in mind that, in general, the average password observed in the real world has about 40 bits of entropy. Typical private keys for asymmetric cryptography are 2048 bits. Even a 30-character password using a random selection of uppercase, lowercase, digits, and twenty symbols only contains around 190 bits of entropy. The passwords used by even wildly atypical users are simply not a suitable input source for generating public keys. – Stephen Touset Oct 20 '12 at 5:18
But by hashing the password with a function like SHA-3, you can fake that much entropy. So I guess the question is, is there something in that mapping that compromises the integrity of the generated key further? Because we're perfectly fine with only 40 bits of entropy for normal password uses. – Calder Oct 20 '12 at 5:48
@StephenTouset Keep in mind that 2,048 bit prime numbers do not equate to 2,048 bits of entropy. You can knock back at least a factor of 10 on that calculation. – Jeff Ferland Oct 20 '12 at 7:35

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