5

Currently the default maximum key size is 4096. I know this can be changed by recompiling the software, and I don't mind doing that.

My problem is about compatibility issues. It makes sense that some implementation may not / may have trouble supporting 8k or 16k keys.

However, I've heard of sub-keys. I don't want my "day-to-day" encryption / signing keys to be incompatible with others. Its also likely that those sub-keys should have an expiration date.

A "master signing key" (ie your identity) should be safe enough for a lifetime, because ideally you don't ever want to change it, right?

I am considering using 4k keys for encryption and documents signing, and a 8k+ key as "master key". That means I will use my master key only to sign my owns keys, and other people's keys. That should be ok, as my gpg2 binary would support 8k+ keys. Is that a correct assumption ?

However, I also need other people signing my key. And that is when trouble could arise. Would a default implementation be able to sign a 8k+ keys?

Have a missed something? Would you consider that a good way to start using OpenPGP?

Flimzy
  • 655
  • 1
  • 6
  • 14
Xaqq
  • 235
  • 2
  • 9

3 Answers3

5

A "master signing key" (ie your identity) should be safe enough for a lifetime, because ideally you don't ever want to change it, right ?

Yes, that's the idea.

I am considering using 4k keys for encryption and documents signing, and a 8k+ key as "master key". That means I will use my master key only to sign my owns keys, and other ppls keys.

Also the route I was going, and was fine with that up to now.

[...] as my pgp2 binary would support 8k+ keys. Is that a correct assumption?

I don't know of pgp2, but if you're speaking about gpg2, namely GnuPG version 2: yes if it's new enough. And this includes all versions of the last few years.

However, I also need other ppl signing my key. And that is when trouble could arise. Would a default implementation be able to sign a 8k+ keys?

In theory, this should not matter, as other users just sign your key and user ID fingerprint with their own key. But in the end, the implementation will have to understand what it's signing (for example to display the user ID string) and might fail for large keys. What reason for will you be using the key? Most people in the free software world use GnuPG, which supports large keys since a really long time (was it ever limited?). If you have to deal with some businesses with really old versions of PGP, you might have to think a little bit deeper about compatibility.

Have a missed something? Would you consider that a good way to start using OpenPGP?

Even if you're using smaller subkeys, the "other" client/user must support that large keys to verify your primary key. Also remember that the actual gain in key strength is not linear to the RSA key size!

Creating large keys like 8K RSA does not require recompiling GnuPG any more on most systems and since quite some time. I think I created mine by using batch key generation.

I put together a list of pros and cons of large keys on SuperUser, also giving references further references. This answer on the purpose of multiple keys also might be of interest, although you already seem to be aware of the implications and possibilities using subkeys.

Jens Erat
  • 23,446
  • 12
  • 72
  • 96
  • Yeah I meant `gpg2`, I edited. Thanks for the links, turns out I already read them a few days ago. On Debian (Jessie) the max key size is 4096 w/o manually re-compiling. I can't really find links discussing very large key. Does it makes any sense to use more than 8k? – Xaqq Apr 02 '14 at 08:27
  • Regarding creating the keys: There was some issue, but I'm not sure how I was able to do so. I _think_ it was using batch key creation. If you find a solution, please tell me. ;) Regarding keys >8k: I don't think so. The post on Super User contains a link to a NIST document showing how much actual strength you get for each key size. I wouldn't go for more than 8k, this is reasonably fast to use and probably will not break for next few next 10k years if RSA will not be broken itself. And if it does, it is very likely that even larger keys will not help you anyway. – Jens Erat Apr 02 '14 at 09:30
  • I generated my keys using a modified version of `gpg` – Xaqq Apr 04 '14 at 09:08
2

Your "master key" has value only insofar as its public part can be used to verify that which was signed with it; and this includes other people. For instance, your "master key" is your ultimate resource to revoke sub-keys. So if you mind about interoperability, then you cannot make the master key as big as you would wish, even if your GnuPG binary has been compiled with appropriate support.

Of course, other people could use your sub-keys only, but what would be the point of the master key then ? If people have to trust your sub-keys by out-of-band means, without getting up to your master key, then the sub-keys are really master keys in their own right. If you want sub-keys to be really "sub", and the master key to be the "master", then you have to use a master key that other people can use (i.e. verify signatures made with the master private key).

As the standard says:

 * OpenPGP does not put limits on the size of public keys.  However,
   larger keys are not necessarily better keys.  Larger keys take
   more computation time to use, and this can quickly become
   impractical.  Different OpenPGP implementations may also use
   different upper bounds for public key sizes, and so care should
   be taken when choosing sizes to maintain interoperability.  As of
   2007 most implementations have an upper bound of 4096 bits.

First sentence is technically wrong, because the format for big integers used in OpenPGP (the "MPI") works "only" up to 524280 bits (which is still quite large). The important point is that back in 2007, using a key of more than 4096 bits incurred the risk of interoperability issues. Given the pace at which people, as a whole, upgrade their software, it would be inordinately optimistic to assume that bigger keys can be used everywhere in 2014.

As for performance, it rarely matters for emails, because emails happen at human pace, so using a "slow" algorithm is not much of an issue as long as it still happens in less than one second. Usual RSA implementations are cubic in key size, meaning that signing with a 4096-bit key will be 64 times slower than signing with a 1024-bit key; therefore you do not want to use really huge keys. However, interoperability issues will bite you much sooner than performance issues.

Right now, in April 2014, no properly generated 1024-bit RSA key has ever been broken publicly. Academics have long worked on the subject, and have come to the conclusion that breaking a 1024-bit key is feasible with existing technology, but entails building a dedicated machine with a very specific architecture, for a cost of several dozens of millions of dollars (even if the work force is "free", i.e. PhD students). In that sense, 1024-bit RSA is in a situation reminiscent to what 56-bit DES was in the early 1980s. Larger keys, e.g. 1536 bits, are way beyond current Earth-based technology. Even with a very optimistic prediction of technological advances, 2048-bit RSA keys ought to be fine for at least 30 years, probably more.

4096-bit keys are overkill, and can be "rationally" justified only as a way to quiet your own paranoia. 8192-bit keys are just plain wrong.

Now, of course, one may imagine that there could be a mathematical advance, in the form of a half-crazed mathematician from some remote location you've never heard of, finding a nifty and efficient way to solve integer factorization. This is highly speculative. Believing that a bigger key would still thwart that hypothetical breaking method is piling speculation on speculation: hardly a sane way to evaluate risks. In fact, physicians have already come up with an efficient method to break RSA, called a quantum computer. Fortunately (or not ?), building a working QC of non-ridiculous size appears quite hard. The important point here, though, is that a 8192-bit RSA key is not really stronger than a 2048-bit RSA key when the attacker has a QC.


Remember that security is an all-encompassing field. That you use OpenPGP with big keys does not mean that attackers are compelled to attack you only through breaking your key. Breaking through your door and planting a hidden video camera in your apartment are effective and way cheaper ways to spy on you. If your secrets are really interesting enough to warrant attention from bad guys, then they will use physical eavesdropping methods that are known to work, have been used for centuries, and have a moderate cost; bigger RSA keys won't change anything to it.

(On the other hand, using stupendously huge RSA keys may send the signal that you are an unrealistic crackpot, and being classified as "harmless fool" is a good way to evade deep scrutiny. This could work.)

Tom Leek
  • 168,808
  • 28
  • 337
  • 475
  • Thank you for the information. Some parts remind me of http://xkcd.com/538/ :) – Xaqq Apr 04 '14 at 09:09
  • While we don't know for sure historically most attacks on cryptograhic primitives tend to reduce the number of "effective bits of security" rather than breaking them open completely. It stands to reason that you have a better chance if you have more "effective bits of security" to start with. – Peter Green Dec 13 '15 at 04:17
1

I made a 16384-bit master signing key with 4096-bit subkeys using a modified version of GnuPG about a week ago. Then I imported it into a trial version of Symantec Encryption Desktop (formerly PGP Desktop). The key (and all of its subkeys):

  1. will not encrypt, sign, or decrypt anything.
  2. cannot change password.
  3. cannot modify preferences (like encryption, hash, and compression algorithms)

In fact, nothing could be done with the key.

As for using a normal version of GnuPG, some operations will give out-of-memory-esque errors. Keep in mind that having a huge master key might render all of its subkeys useless too in some software.

Kevin Li
  • 601
  • 4
  • 6