Concepts/OpenPGP Getting Started: Difference between revisions
No edit summary |
No edit summary |
||
Line 23: | Line 23: | ||
== User IDs == | == User IDs == | ||
User IDs | User IDs are formally just arbitrary strings but expected to consist of a name, an optional comment, and an email address. This structure allows email software to find the suitable key for a recipient address (which most programs require you to confirm for obvious reasons). An OpenPGP public key (more precise: certificate) must have a user ID but can have as many as you like. Thus you can use the same key for several email addresses (which makes sense only if these addresses shall be used at the same security level). Combining addresses has advantages and disadvantages. The main advantage is that you need less keys and thus you and others have less work with certifications. The main disadvantages are that you can revoke user IDs but they keep visible forever and that such a combined key allows to make a trivial connections between different roles of you which you may not want connected: private person, business, other organizations (associations, political parties, whatever). You may want to keep these groups separate. And there are even reasons to keep addresses from the same group separate: reputable addresses (firstname.lastname@example.com), anonymous addresses (heejei7u@example.org), fun addresses (superman17@example.org). It also may be that you have no reason to ever use OpenPGP with certain addresses; such addresses should not be part of a user ID, of course. The decision to add an address to a key and publish that key is forever. But it is easy to add an address later. Thus consider this well before you generate the key. In case of doubt start with fewer addresses. | ||
It makes sense to have a special user ID without an email address. With most email addresses you cannot be sure to have them forever. If you revoke a User ID because you don't use the address any more then you lose all the certifications for this user ID. But you will never lose your name (even if you marry or the like there is usually little reason to revoke that user ID). So you keep the certifications for this ID at any rate. And you can use the comment for this ID for a statement about the key itself: "everyday key with secure offline mainkey and key policy" | |||
Revision as of 23:55, 27 June 2013
Introduction
When creating a key you make several technical and organizational decisions (whether you are aware of that or not) which heavily influence the security and usability of your key, as a result the operating life of the key. Some of these decisions cannot be changed afterwards. For several reasons it is desirable that normal keys – even rather insecure ones – (at least their core) have a long operating life.
Thus this article shall make you familiar with the important aspects of key generation and help you generate a good key which you can use for many years. This article covers just the concepts you should be familiar with, it does not contain a step by step tutorial for key generation because these should be separate phases: First understand and plan what you are going to do and make the necessary preparations. If you have finished that have a look at the OpenPGP key generation article.
Key security
If keys are involved then the main question is: How secure / reliable are them and their usage? The most important rule in cryptography is not "Make it even more secure" but "(1) Think about how much security you need. (2) Decide which technical effort seems necessary (lower limit) and reasonable (upper limit) to fulfill these requirements. (3) Strictly observe the rules you have determined (write them down). (4) If other people are involved (which usually is the case) let them know precisely and securely what the usage limits and the security level of this key are." Most of the following considerations are about the security and the transparency of their security and meaning.
Nobody cracks keys by brute force attacks. That is (even for rather short keys, say 1024 bit) simply impossible for everyone beneath the level of a government agency of a "rich" country within the next decades. And it would not make sense: It's so easy to just steal them. With a huge probability the system which you are just using to read this text (if not printed...) is not very secure. De facto no system which is used for reading email or reading web pages is safe. Don't argue, just accept this. If you don't you probably just compromise yourself. A key is never more secure than the least secure system on which it has been used (this, of course, includes: created). And it is more secure than the least secure system on which it has been stored just by its passphrase which is no protection against a brute force attack if it is either not really random or less than about 16 characters long (for small and capital letters and digits).
It is perfectly OK to use OpenPGP on such insecure systems (i.e. normal computers). You and your communication partners(!) just have to be aware of the security level. The next security level are smartcards. You cannot steal a key from a smartcard (you can abuse it nonetheless if you control the system to which the smardcard is connected). The next level after smartcards are secure systems: Unconnect your harddisk, all USB sticks (and the like) and the network, boot from a secure medium like a Linux live DVD (from a trusted source, of course!). Use high security keys in such a secure environment only (and maybe even limited to safe document formats like plain text or HTML).
Main key and subkeys
Most OpenPGP keys have at least one subkey (all have exactly one main key). You usually need not care about this difference; your application (or rather the base application, usually GnuPG) selects the right one automatically. The main key is the one which the key fingerprint refers to and only the main key can certify: your own subkeys and user IDs and the user IDs of other keys. The subkeys can do everything else (mainly decryption and signing) if you configure them so. The reason the difference between these key types is mentioned here is that this is very important for key generation: You can separate the secret main key from the secret subkeys (with GnuPG; this is not part of the OpenPGP standard!). The subkeys can be replaced later, the main key cannot (that would be a new key not just a modified key). Thus if you create an offline main key at key generation which you protect by a very hard passphrase, store at least the passphrase securely and use the main key (and its passphrase) in secure environments only then you can keep this key "forever" (say 20 years). This is important for everyday keys. High security keys don't really need this separation (usually don't need subkeys at all).
User IDs
User IDs are formally just arbitrary strings but expected to consist of a name, an optional comment, and an email address. This structure allows email software to find the suitable key for a recipient address (which most programs require you to confirm for obvious reasons). An OpenPGP public key (more precise: certificate) must have a user ID but can have as many as you like. Thus you can use the same key for several email addresses (which makes sense only if these addresses shall be used at the same security level). Combining addresses has advantages and disadvantages. The main advantage is that you need less keys and thus you and others have less work with certifications. The main disadvantages are that you can revoke user IDs but they keep visible forever and that such a combined key allows to make a trivial connections between different roles of you which you may not want connected: private person, business, other organizations (associations, political parties, whatever). You may want to keep these groups separate. And there are even reasons to keep addresses from the same group separate: reputable addresses (firstname.lastname@example.com), anonymous addresses (heejei7u@example.org), fun addresses (superman17@example.org). It also may be that you have no reason to ever use OpenPGP with certain addresses; such addresses should not be part of a user ID, of course. The decision to add an address to a key and publish that key is forever. But it is easy to add an address later. Thus consider this well before you generate the key. In case of doubt start with fewer addresses.
It makes sense to have a special user ID without an email address. With most email addresses you cannot be sure to have them forever. If you revoke a User ID because you don't use the address any more then you lose all the certifications for this user ID. But you will never lose your name (even if you marry or the like there is usually little reason to revoke that user ID). So you keep the certifications for this ID at any rate. And you can use the comment for this ID for a statement about the key itself: "everyday key with secure offline mainkey and key policy"
How to get started
You can easily create a key for playing around. But if you let others verify such a key you risk throwing work away later. Your aim should be to create one or more long term keys. The best advice is: Don't try on your own if you can avoid it. Ask experts if you can, people who already have replaced a key of their own and learnt from that. Use a secure system to create a key, use an offline main key and give both the main key and the subkeys an expiration date (not more than a year). Select a key policy (describing the security and usage of main key and subkeys) and stick to it. If you certify other keys before you have a certification policy, do not certify them for the public (web of trust), make local signatures instead (just for yourself). Avoid doing new things before you understand well what they mean.
And remember this:
- What is comfortable (at least nearly) always threatens your security.
- More secure is not always better for the given task. Just be aware of the consequences (in both directions).
Welcome to the crypto world!