Suppose someone had generated a 2.048-Bit RSA GPG/PGP key pair and published the public key on the usual key servers. Then he withdraws this key and generates a new one in 4.096-Bit RSA using the same passphrase again.

Theoretically, can the passphrase be cracked by mathematically comparing the two public keys or does that give away any security whatsoever, e.g. by the fact that both of them are out there?

I'm not a mathematician, so I'd be especially interested if 'comparing two keys' would make any theoretical sense at all and if so, what impact this would have on the integrity of the passphrase.

Edit: please note that this question is not about reversing a hash to its passphrase (or in this case reversing two hashes to eventually learn they were made from the same pass) but if there are mathematical methods to compare two hashes to

The only thing I can think is, if an attacker, through dictionary attack, brute force, or whatever, gets the passphrase to decrypt one, she will immediately have the password to decrypt the other.
–
mikeazo♦Jan 10 '12 at 15:52

@mikeazo: At best the attacker gets a two for one, but since the user withdraws the first key it gets the attacker no where. If both keys use a secure hash algorithm then they are both as secure for reversing to the passphrase.
–
Jim McKeethJan 10 '12 at 20:20

3 Answers
3

The passphrase you use creates a symmetric key that is used to encrypt the private key. You're not uploading the private key to the server, at least let's hope you aren't.

But even if you are doing that, the password is salted and iterated in hashing, and that means that the visible encrypted private key is radically different even if the password is the same, because the same password produces two different symmetric keys.

If you look at the OpenPGP spec section 3.7 it covers the String-to-Key (S2K) Specifiers which convers a passphrase to a key. Assuming the Salted S2K or Iterated and Salted S2K method is used (which is recommended) then reusing your passphrase shouldn't be an issue. The larger key has a larger length, which means the passphrase will be concatenated more times with the salt. Good hash algorithms generate significantly different hashes for even small changes in the plain text. So the two generated keys should bare no similarities that could indicate what the passphrase may be.

Also hash algorithms are called one way algorithms, meaning you can't get back to the plaintext from the hash value. This means that you cannot get from the 2048-bit key back to the passphrase and then use that passphrase to break the 4096-bit key.

Update: I was thinking about this some more. If the lower bitrate key used an insecure hash algorithm then it could be easier to reverse, thus providing the passphrase. So the above holds true if both keys are generated with the same hash algorithm.

I did some more reading. It would appear that the way a key is generated varies from system to system, so a lot of it would depend on the method used to generate the keys.

From what I see it is common to use the passphrase to encrypt the private key, and use a CSPRNG (cryptographically Secure Psudo-Random Number Generator) to generate those keys. So in those scenarios the passphrase encrypted private key is never published. Even if it were (bad idea) there would still be no way to compare the two and see they used the same passphrase or determine the passphrase though having both.

Because an RSA pubic key is (basically) the product of two prime numbers, the key cannot be directly generated from a passphrase. For example the passphrase FOO does not directly translate into two prime numbers. Instead that passphrase can be used as a seed, or part of a seed for a system that generates prime numbers (usually combined with a random seed or system entropy since a passphrase does not contain enough entropy to generate even an 128-bit key)

Even if the system only used a user provided passkey to generate the prime numbers, the prime numbers would be so totally different that were used for the two different key sizes, and they would not follow any deterministic pattern, so there would be no relation between the two keys.

For example: Say the passphrase FOO always generates the 4-bit primes of 7 & 13 (for a product of 91) when it passes through the 4-bit algorithm. If that same passphrase was used in the 8-bit prime algorithm it could generate 10007 (not saying it would, but as an example of a possible relationship) as the first prime, but 100013 is not prime, so it would need to generate 10037 (for a product of 100440259) or some other prime. So even if the passphrase was used to directly generate a number, there is no guarantee that the generated number would be prime, so additional steps must be included to find a prime. These steps decouple the relationship between the generated key and the passphrase / seed used to generate it.