2

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?

Improve this question
2
  • 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
    Commented Oct 20, 2012 at 6:24
  • The latter, because the former still depends on data stored on your computer (external to the user's memory).
    – Calder
    Commented Oct 20, 2012 at 6:41

1 Answer 1

Reset to default
0

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.

Improve this answer
8
  • 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
    Commented Oct 20, 2012 at 5:04
  • Which is one of the reasons why raw public key cryptography has been a non-starter for general authentication.
    – Stephen Touset
    Commented Oct 20, 2012 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
    Commented Oct 20, 2012 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
    Commented Oct 20, 2012 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 ♦
    Commented Oct 20, 2012 at 7:35

Not the answer you're looking for? Browse other questions tagged .