Concepts/OpenPGP For Beginners

Revision as of 05:47, 22 April 2013 by Aebexo (talk | contribs) (Created page with "The effective security of a cryptography solution depends more on knowing what you do and what certain technical facts mean (and what not!) than on key lengths and the softwar...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

The effective security of a cryptography solution depends more on knowing what you do and what certain technical facts mean (and what not!) than on key lengths and the software itself. Thus this article shall give an introduction to the OpenPGP core concepts. This is for beginners so any too fancy stuff is left out. Furthermore you will not find explanations how to get something done with a certain software. You have the software documentation for that. This shall help you to better understand the actions explained there.

asymmetric keys

OpenPGP uses key pairs. This means that there is always a secret key and a public key belongig together. In contrast to the very intuitive concept of symmetric encryption (i.e. the same password encrypts and decrypts the data) this is hard to understand. Don't think about that, just accept it; the math behind this is a nightmare so for most people going into details would be a stressful waste of time.

As the names say: The secret key is to be known to its owner only, and the public key should be known to everyone at best. With symmetric encryption the problem was to safely share the password with the recipient of a message. With public keys the problem has changed: Now the hard part is to be sure that you are using the correct public key (and not a forged one an attacker tries to trick you into using).


One of the two functions of OpenPGP is encryption. You encrypt data to one ore more public keys (symmetric encryption i.e. using a password instead is possible but rarely used). For decrypting the data the secret key of one of the recipient keys is needed. Except for the already mentioned problem "Which is the right key to encrypt for?" encryption - decryption is a quite simple operation because there is no room for misunderstanding: You encrypt something and nobody except the ownser(s) of the recipient key(s) can read it. And you can either decrypt data or you can't. The decrypted data itself may be hard to understand but the decryption operation is not.

digital signatures

The encryption of data can be kind of reversed: Instead of creating data which only one key can understand you can create data which everyone can understand but which only one key can have created. This impossibility to create the same data without access to the respective secret key makes this data a signature. Once again: Don't ask for how this is possible unless you really like math. One of the great things about digital cryptography is: In contrast to a handwritten signature it is very easy for everyone (OK: for everyone's computer) to check that this signature was made by a certain key. If you can relate a certain key to a person then you can also relate a digital signature to this person – unless, of course, the key has been compromised. You may have noticed: At this point the task becomes an organizational and legal one. Technology does not solve all of your problems. And it is extremely important that you are always aware where the border between the technical and organizational problems is.

And relating a key to a person is not the hard part! That is: "What does the signature mean?" Is your interpretation of a signature legally binding for its creator? The meaning can be as low as a timestamp (which is a perfectly valid an serious application for crypto signatures!), proving nothing more than that a certain document existed at a certain time (and was not created later). If somebody signs all his emails (to prevent address forgery) then the pure fact that he sent a certain document within such a signed email does not mean anything except for that he probably wanted to offer you a look at it. If the email (the signed part, not the unsigned subject) says something like "I accept the attached agreement" then the meaning is clear and the remaining risk of the recipient is mainly a technical one (compromised low security key). Thus it makes sense to have different keys at different security levels: One for reasonably securing everyday tasks and another one for signing agreements (where the key policy documents explain the limits and privileges of the respective key).

In contrast to encryption the signature of data does not (technically) have an addressee. Everyone with access to the public key can check the signature. In many cases that is not a problem (or in contrast: It may even be a requirement). Instead of selecting an addressee you select the secret key which shall be used to create the signature (if you have more than one).

The big "Which is the right public key?" problem occurs with signatures, too. Not with creating signatures but when interpreting a successful signature validation. The real life question is: "What does a signature mean?" Obviously a signature by "any" key does not mean anything. Everyone can have created it. The signature itself does not state more than: "Somebody with access to the secret key decided to create this signature." This is a technical fact without relevance in real life.

relating keys to people or organizations

This is the first really hard part. And because only few people do this correctly the whole system is much less secure than most people believe. You have to tell apart four components of this check. The first is the easiest: the key itself. You have to be sure that you are using the right key material (just the huge random number itself). As keys are to big to be compared manually a secure hash is used instead. Once again: Evil math stuff you fortunately need not understand. A hash function does this: You throw any kind and amount of data at it (from a single digit to a DVD image file) and it outputs a "number" of fixed length. If it is (considered) impossible to create two different inputs which create the same output then the hash function is secure. OpenPGP currently uses the hash function SHA-1 for identifying keys. SHA-1 has security issues but they do not affect the usage in OpenPGP. A SHA-1 value looks like this:

   7D82 FB9F D25A 2CE4 5241  6C37 BF4B 8EEF 1A57 1DF5

This is called the fingerprint of the key. There are two ways of being safe about the identity of a key (the raw key material) without third parties involved: You get either the key itself from a secure source (USB stick handed over by the key owner) or you get the fingerprint from a secure source (which is obviously much easier as you can print is on small pieces of paper, even on your business card, and spread them). Your OpenPGP application shows you the fingerprint of the key you got from an insecure source and you compare "what is" with "what it should be". If that is the same then you can be sure about the key itself. Thus: Always have small slips of paper with your fingerprint with you.

A public OpenPGP key (a "certificate") consists of two parts: the key material and the user IDs. A user ID is just a text string. The typical usage of this string is:

   Firstname Lastname (comment) <email address>

Many user IDs do not have a comment, some do not have an email address and there are keys without a (real) name, too (e.g. for anonymous usage). Even if you are sure about the fingerprint the name, email, and comment can be wrong. Email is rather easy to check (send an encrypted message to the address and wait for a response which guarantees your message to be decrypted). Checking the identity of unknown persons is not easy. at keysigning parties this is done by checking passports and the like. But would you recognize a well forged passport? Fortunately for your own purposes the identity is usually not so important. "The one I met on that event who calls himself Peter" is usually enough. So this is more a problem for the web of trust (see below). Comments can be critial, too: The comment "CEO of whatever inc." may make a real difference (if not to you then to somebody else). The question when to accept (and certify) a user ID is a really complicated one. Most people don't understand this problem and thus reduce their own security and that of others. You can make this decision for others easier by having user IDs which consist of just your name or just your email address. This may be easier accepable by someone checking your user IDs.

If you are sure about a user ID you should certify it. This means that you make a digital signature over the public key and this user ID. You can make this certification for yourself only (called a "local signature") or for the public (the "web of trust"). If a key has several user IDs then you can decide which ones you certify. You can give a rough hint how well you have checked the user ID and key, too. It makes a big difference to OpenPGP applications (and so should it to you!) whether they recognize a key as "valid" or not. The keys you have the secret key for are considered valid automatically. The others can become valid by signatures of your own keys. And by keys of others.

the web of trust (WoT)

For some keys it is very difficult to verify them directly with their owner. Thus you can decide (this decision is the default setting of the base software GnuPG) to accept keys as valid if they are certified by keys which you consider

  1. both valid
  2. and trustworthy (and technically: secure) enough

Example: You want to send an encrypted email to Steve. You are reasonably sure that Steve has the email address (in contrast to most names email addresses have the big advantage that they are unambiguous; and they have the disadvantage that the same email address can belong to different people over time). Let's assume that it is not possible for you in time to check the key with Steve directly. You search for keys with his email address on the keyservers and find one (just one luckily). This key has several certifications by other keys and you happen to know (and consider valid) two of them. Your friends Joe and Michael have created a signature for the key which you just got from an insecure source. But their signatures cannot be forged (under normal conditions). The technical part is that your application tells you that their signatures are correct and valid. The organizational part is that you have to decide if that is good enough for you. If it is and you configure your application accordingly (or make a local signature by yourself) then your applications will consider this key valid and you can send him an encrypted message (without clicking away a lot of warnings and without being too afraid).

To make this assessment easier every key which actively participates in the web of trust should have a (really securely signed) certification policy. You may have guessed: Currently nearly nobody has one. And of course it is very important that you stick to your policy!

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 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. The subkeys can be replaced later, the main key cannot. Thus if you create an offline main key at key generation which you protect by a very hard passphrase and store at least the passphrase securely and use the main key in a secure environment 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 seperation (usually don't need subkeys at all).

key security

Nobody cracks keys by brute force attacks. That is simply impossible for everyone beneath the level of a government agency of a "rich" country. 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 just compromise yourself. A key is never more secure than the system on which it is used (this, of course, includes: created). And it is more secure than the system on which it is stored just by its passphrase which is no protection against a brute force attack if it is either not really random or less than 16 characters long (for small and capital letters and digits).

It is perfectly OK to use OpenPGP on such insecure systems (at least today; this may change in the future if everyone has crypto keys on his system which are a valuable target for attackers). 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. The next level is protection against hardware attacks (obviously not a subject for a beginners article).

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:

  1. **What is comfortable (at least nearly) always threatens your security.**
  2. More secure is not always better for the given task. Just be aware of the consequences (in both directions).

Welcome to the crypto world!

Content is available under Creative Commons License SA 4.0 unless otherwise noted.