Subkeys: howto choose which does what

[IVE_GOT_QUESTIONS319]

I'm a little uneasy about the notion of subkeys.

First off, is it possible to have a key that's used for encryption and signing without any subkey at all?

If I have 50 subkeys, how do I know which is used for signing and which is used for encryption.

I read Shane's post about how signatures greater than 1024 bits might actually do more bad than good. So if I wanted to created a RSA 1024 sig and RSA (Or DSAElGamal) at 4096, which would be the key and which would be the subkey? Or do I create one key at 4096 and have both of the sig and encryption key as subkeys...?

[rjh]

Is it possible to have a key that's used for encryption and signing without any subkey at all?

This question doesn't make any sense. Relax--the problem is with the terminology that we use, not with you.

Originally in PGP 2.6, back in the early 90s, you had just one keypair and it was used for both encryption and signing. The ability to have additional keypairs presented some engineering challenges. Ultimately, it was decided that the additonal keypairs would be called "subkeys", despite the fact there's nothing "sub" about them. Likewise, what you call your "key" isn't really a key at all--the terminology is a holdover from the days when a key really was a key. Nowadays, a key is really a collection of keys, along with some metadata for user identifiers, signatures, etc.

E.g., my "key" has four keypairs on it: 5B8709EB, D0C6AAE4, 71E177DB and 8DB02BBB3.

What GnuPG calls your "public key" is really the oldest signing key in the collection. E.g., since 5B8709EB was created first, GnuPG calls the entire set of keys and metadata the "5B8709EB key".

So, "is it possible to have a key that's used for encryption and signing without any subkey at all?" The answer here is no, because all keypairs on a key are subkeys. Even if there's only one of them.

If I have 50 subkeys, how do I know which is used for signing and which is used for encryption.

This is another meaningless question. The most accurate answer is "... and why do you care?" If a subkey exists, that means the key owner approves of you using it. If the owner didn't, the owner would have revoked it. You never need to know which is used for signing and/or encryption. GnuPG could randomly choose between them and still be in accordance with the strict letter of RFC4880. As of this writing, GnuPG's policy is to use the largest key available for the task. That's been GnuPG's policy since the 1.0 release. However, there is absolutely no guarantee it will always be this way.

Not every subkey is capable of every task. Enigmail will not tell you key capabilities (for now--there's a UI enhancement in the works to fix this!), so you'll have to "gpg --edit-key my-key-ID" to find out. To the right of each subkey row you'll see a "usage:" field. An S means this subkey is capable of signing; a C means it is capable of certifying (which really only matters to OpenSSH users); and an E means it is capable of encrypting.

I respectfully differ with Shane on the subject of >1kbit signatures doing more harm than good. 1kbit is far too short for even medium-term security. 2kbit is the current recommendation.

[john]

To the right of each subkey row you'll see a "usage:" field. An S means this subkey is capable of signing; a C means it is capable of certifying (which really only matters to OpenSSH users); and an E means it is capable of encrypting.

A means authorization and THAT is what matters to (open)SSH users.

Certifying is signing other keys (which does not matter to SSH users).

On the 1k vs 2k. For X.509 certs, the current default for most CAs is 2048-bit RSA for signing and encryption. Most sites call it "Medium-grade". You are, for most purposes, safe with the defaults. Start there and as you learn more, you can better assess your own needs.

Threat models are highly individual, like a person's shoes. Trying on another that is too small will cause you pain; too big and you risk falling on your face. 2048-bit RSA is a sane default unless there's a limitation to use 1024-bit, eg, smart cards. I still haven't made up my mind on 1024-bit DSA/2048-bit ElGamal

[IVE_GOT_QUESTIONS319]

I was referring to this post: http://mozilla-enigmail.org/forum/viewt ... p?t=53#123

And someone else (I think shane as well) mentioned something about making a 1024 bit key with a 4096 subkey for encryption. So I was wondering how Enigmail determines what does what. I can see how this works if out of all my subkeys only 1 is flagged for encryption, 1 is flagged for signing, and 1 is flagged for certification. But lets say I have 3 subkeys that are capable of signing....

I understand that this project is geared toward streamlining mail security for people. But that has a side effect of getting peoples' foot in the water enough to where they want to swim.

[john]

Usually when you see 1024/<something> in the context of OpenPGP it is referring to the default arrangement of a 1024-bit DSA signing key with a <something>-bit ElGamal encryption key. Here, capability flags don't matter, each key only has it's own function.

The key capability flags show up in discussion of RSA (sub)keys. Which subkey gets used to sign if multiple keys have the same capability is not a function of Enigmail outside of one specifying a key ID for signing in an account's preferences.

Rob already gave the answer that GnuPG will use the largest subkey for a given purpose. I believe if multiple keys of the same size exists, it chooses the newer (I may be wrong). There is no mandated behavior regarding this in the RFC - it's an implementation detail and subject to change.

At any rate, one may override GnuPG's subkey selection by suffixing the key ID with an exclamation mark, ie 0xDECAFBAD!.

I personally have never contemplated such a scenario as I abhor ambiguity.

[rjh]

John--right, A is what only matters to OpenSSH. Sorry, I can only plead a momentary attack of stupidity. I knew the right thing, I just didn't say it.

With respect to the post by Shane, I think he is (a) mischaracterizing things and (b) misquoting me. I'm the one who said "if 1024-bit crypto is broken, we need to change our algorithms more than we need to increase our key sizes". Except that I didn't say 1024-bit crypto; I said 2048-bit crypto. I stand by that.

1024-bit keys may be attackable by phenomenally well-funded adversaries within the next five years. A couple of years ago a huge key-cracking challenge using thousands of computers across the whole world was able to break a 64-bit symmetric key by brute force. It took eighteen months for this entire network to do it. Given cracking a 1024-bit asymmetric key by brute force is roughly 65,000 times harder... you don't have to be a genius to say 1024-bit asymmetric key is probably secure today, but as technology advances and networks grow larger we shouldn't be optimistic about the next ten years.

2048-bit asymmetric crypto is roughly equivalent to 128-bit symmetric crypto. Breaking this by brute force is absolutely, solidly, in the realm of utter deranged whackjob fantasy. The laws of physics themselves forbid it: the Second Law of Thermodynamics requires an amount of heat equal to 100 nuclear bombs be released. That's pretty messed up. No one is going to break a 128-bit symmetric cipher by brute force. Ever. Even quantum computation will have a really hard time with it.

If 2048-bit crypto ever falls it will be because of innate mathematical flaws in the algorithms themselves, not because computers have become faster or networks larger. That's why I say that if 2048-bit asymmetric crypto ever falls we will need to change our algorithms, not just add on a few more bits.

I also think Shane is misrepresenting GnuPG's admonition about very large keys. Very large keys do not introduce a weakness in the hashing mechanism. However, your signatures are never stronger than the weakest component in the system, much as a chain is only as strong as its weakest link. The admonition is not to believe that a large key is all there is to it: if your key provides more security than your hash algorithm (which can happen with large keys and short hashes), that an attacker will simply attack the hash rather than the key itself.

I also have the same sense John does about GnuPG's behavior with subkeys. GnuPG's current behavior is to use the largest subkey that's appropriate for the task, and if there are two or more of equal size, to use whichever of them is the newest.