Introduction

The most ancient problem of the asymmetric cryptography is to keep secret the private key so that it cannot be compromised by falling in an attacker's hand.

To solve (at least partially) this problem, it is possible to set an expiration date for the key. In this way, if it were not possible (for whatever reason) to revoke the key, this would become automatically invalid after its expiration.
However, this imply another problem: all the signatures made on other keys would be invalid too after the expiration of our key, unless we renew it periodically. Moreover, if we decided not to renew our old key after its expiration but to generate a new one, we would need to collect again on the new key all the signatures that other persons made on the old one.

On the other hand, it is possible to create one or more subkeys and to set an expiration only for these last ones.

In this way, we could sign what must not expire (e.g. certifications of others' keys) with the main key and what can expire without problems (e.g. encrypted messages) with one of the subkeys.

When the subkeys expire, they can be replaced by generating new subkeys or simply renewed, if we are sure that they have not been compromised.

However, since our key includes also the master private key, if we suspect that it has been compromised, we have the problem of revoking it and wasting all the work we did for the Web-Of-Trust, making invalid all the signatures we did on others' keys and, also, the ones which others may have done on our own key.

We can avoid this problem using a main key which cannot be compromised and one or more expendable subkeys (which can therefore be revoked) for daily use.

As an example, we may need to use our keys in insecure environments (Internet Points, Shared PCs in a school, in workplaces, in holidays...), and we want to avoid that they can be compromised during this "not fully secure" usage.
In these cases, then, an "event key", created with the following procedure, may simplify our work keeping an acceptable security level.
The keys may therefore have a validity limited to the duration of the event (one week, one month, ...) and will expire at its end (unless they are renewed by the owner).
Moreover, in extreme cases (stolen devices and/or media carrying the keyrings), it will be not necessary to revoke and recreate the entire keypair, avoiding all the implications of this procedure.

Using GnuPG, all of this is possible.

With this page I am not showing that I invented the hot water, I am only explaining how to create a keypair which is enough secure.
The proposed technique is not therefore the solution to all the key storage problems, but it is only yet another hardening of the sake keeping techniques (which absolutely must not suggest us to lower the usual minimum alert level).

I must emphasize that the secret keys created with this technique would work only with GnuPG, while the corresponding public keys would work with PGP also. In this way we would be able to exchange messages with anybody who is using an OpenPGP compliant software.


Let's go...

First, we must make a backup copy of our keyrings (so to avoid catastrophes) and move them away, so that we can start with new and empty keyrings.

T:\GnuPG>dir  Volume in drive T is TJL73  Volume Serial Number is 47C1-741C  Directory of T:\GnuPG 18/07/2007  10.10    <DIR>          . 18/07/2007  10.10    <DIR>          .. 18/07/2007  10.10                 0 pubring.gpg 18/07/2007  10.10                 0 secring.gpg 18/07/2007  10.10                40 trustdb.gpg                3 File(s)             40 bytes                2 Dir(s)     123.456.789 bytes free

We now generate a new keypair, with the command "gpg --gen-key":

T:\GnuPG>gpg --gen-key gpg (GnuPG) 1.4.8; Copyright (C) 2007 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. Please select what kind of key you want:    (1) DSA and Elgamal (default)    (2) DSA (sign only)    (5) RSA (sign only) Your selection?

In this example we will create a DSA (sign only) key (the one labeled with number 2), but also a RSA (sign only) key would work fine.

Your selection? 2 DSA keypair will have 1024 bits.

We are asked now for the expiration date of the primary key (which will be used to sign only). Our primary key must have no expiration.

Please specify how long the key should be valid.          0 = key does not expire       <n>  = key expires in n days       <n>w = key expires in n weeks       <n>m = key expires in n months       <n>y = key expires in n years Key is valid for? (0) 0 Key does not expire at all Is this correct? (y/N) y

We must now enter our personal data (the UserID), the Passphrase and, after a confirmation, our primary keypair will be generated inside our keyrings.

You need a user ID to identify your key; the software constructs the user ID from the Real Name, Comment and Email Address in this form:     "Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>" Real name: Test Key Email address: address@mail.invalid Comment: No Comment You selected this USER-ID:     "Test Key (No Comment) <address@mail.invalid>" Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o You need a Passphrase to protect your secret key. Enter passphrase: *********************** Repeat passphrase: *********************** gpg: NOTE: you should run 'diskperf -y' to enable the disk statistics We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++.+++++.++++++++ +++++++++++++++++..++++++++++.+++++.+++++++++++++++.+++++>++++++++++..>+++++...+ ++++ gpg: NOTE: you should run 'diskperf -y' to enable the disk statistics gpg: key 1A2B3INV marked as ultimately trusted public and secret key created and signed. gpg: checking the trustdb gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u pub   1024D/1A2B3INV 2007-07-18       Key fingerprint = XXXX XXXX XXXX XXXX XXXX  XXXX XXXX XXXX 1A2B 3INV uid                  Test Key (No Comment) <address@mail.invalid> Note that this key cannot be used for encryption.  You may want to use the command "--edit-key" to generate a subkey for this purpose.

We have now our new keys in our new keyring:

T:\GnuPG>dir  Volume in drive T is TJL73  Volume Serial Number is 47C1-741C  Directory of T:\GnuPG 18/07/2007  10.10    <DIR>          . 18/07/2007  10.10    <DIR>          .. 18/07/2007  10.10               570 pubring.bak 18/07/2007  10.10               570 pubring.gpg 18/07/2007  10.10               600 random_seed 18/07/2007  10.10               633 secring.gpg 18/07/2007  10.10             1.280 trustdb.gpg                5 File(s)          3.653 bytes                2 Dir(s)     123.456.789 bytes free

We must now perform a new backup of the new keyrings, which contain the keypair capable to sign only (we will use this keyring only to sing other persons' keys; in this way our signatures on their keys will not expire until such keys themselves expire).

T:\GnuPG>md backup1 T:\GnuPG>copy *.gpg backup1 pubring.gpg secring.gpg trustdb.gpg         3 file(s) copied.

Now we proceed with the generation of the subkeys with time limited validity (with expiration). One will be to daily sign and the other for the encryption.

In this example we will create, first, a 2048-bit RSA signing key expiring in 1 year:

T:\GnuPG>gpg --edit-key 1A2B3INV gpg (GnuPG) 1.4.8; Copyright (C) 2007 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. Secret key is available. pub  1024D/1A2B3INV  created: 2007-07-18  expires: never       usage: SC                      trust: ultimate      validity: ultimate [ultimate] (1). Test Key (No Comment) <address@mail.invalid> Command> addkey Key is protected. You need a passphrase to unlock the secret key for user: "Test Key (No Comment) <address@mail.invalid>" 1024-bit DSA key, ID 1A2B3INV, created 2007-07-18 Please select what kind of key you want:    (2) DSA (sign only)    (4) Elgamal (encrypt only)    (5) RSA (sign only)    (6) RSA (encrypt only) Your selection? 5 RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) 2048 Requested keysize is 2048 bits Please specify how long the key should be valid.          0 = key does not expire       <n>  = key expires in n days       <n>w = key expires in n weeks       <n>m = key expires in n months       <n>y = key expires in n years Key is valid for? (0) 1y Key expires at 07/18/08 10:10:10 Is this correct? (y/N) y Really create? (y/N) y We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. gpg: NOTE: you should run 'diskperf -y' to enable the disk statistics ...+++++ .+++++ pub  1024D/1A2B3INV  created: 2007-07-18  expires: never       usage: SC                      trust: ultimate      validity: ultimate sub  2048R/8E9F0INV  created: 2007-07-18  expires: 2008-07-18  usage: S [ultimate] (1). Test Key (No Comment) <address@mail.invalid>

and, next, a 2048-bit Elgamal encrypting key, also expiring in 1 year (at the end, we will save the changes with the command "save"):

Command> addkey Key is protected. You need a passphrase to unlock the secret key for user: "Test Key (No Comment) <address@mail.invalid>" 1024-bit DSA key, ID 1A2B3INV, created 2007-07-18 Please select what kind of key you want:    (2) DSA (sign only)    (4) Elgamal (encrypt only)    (5) RSA (sign only)    (6) RSA (encrypt only) Your selection? 4 ELG-E keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) 2048 Requested keysize is 2048 bits Please specify how long the key should be valid.          0 = key does not expire       <n>  = key expires in n days       <n>w = key expires in n weeks       <n>m = key expires in n months       <n>y = key expires in n years Key is valid for? (0) 1y Key expires at 18/07/2008 10:10:10 Is this correct? (y/N) y Really create? (y/N) y We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. ++++++++++.++++++++++++++++++++++++++++++++++++++++++++++++++.++++++++++..+++++. .++++++++++.+++++++++++++++++++++++++.+++++.+++++.++++++++++.+++++.+++++.+++++>+ +++++++++>+++++............................>+++++......................<...+++++ ..............................+++++^^^^^ gpg: NOTE: you should run 'diskperf -y' to enable the disk statistics pub  1024D/1A2B3INV  created: 2007-07-18  expires: never       usage: SC                      trust: ultimate      validity: ultimate sub  2048R/8E9F0INV  created: 2007-07-18  expires: 2008-07-18  usage: S sub  2048g/7A8B9INV  created: 2007-07-18  expires: 2008-07-18  usage: E [ultimate] (1). Test Key (No Comment) <address@mail.invalid> Command> save

As it is show above, in our example we will have a primary key which does not expire ("expires: never") to sign and certify ("usage: SC") and two subkeys, both expiring in 1 year ("expires: 2008-07-18"), the first one for signing ("usage: S") and the second one for encrypting ("usage: E").


We can now ask GnuPG to print the present status of our keyrings (and therefore of our keys), with the two commands "gpg --list-keys" and "gpg --list-secret-keys":

T:\GnuPG>gpg --list-keys t:/gnupg\pubring.gpg -------------------- pub   1024D/1A2B3INV 2007-07-18 uid                  Test Key (No Comment) <address@mail.invalid> sub   2048R/8E9F0INV 2007-07-18 [expires: 2008-07-18] sub   2048g/7A8B9INV 2007-07-18 [expires: 2008-07-18] T:\GnuPG>gpg --list-secret-keys t:/gnupg\secring.gpg -------------------- sec   1024D/1A2B3INV 2007-07-18 uid                  Test Key (No Comment) <address@mail.invalid> ssb   2048R/8E9F0INV 2007-07-18 ssb   2048g/7A8B9INV 2007-07-18

Now we can export our keys with the following three commands:

T:\GnuPG>gpg --output public.asc --armor --export 1A2B3INV T:\GnuPG>gpg --output secret.asc --armor --export-secret-keys 1A2B3INV T:\GnuPG>gpg --output subsecret.asc --armor --export-secret-subkeys 1A2B3INV

We have now obtained three files ("public.asc", "secret.asc" and "subsecret.asc"):

T:\GnuPG>dir  Volume in drive T is TJL73  Volume Serial Number is 47C1-741C  Directory of T:\GnuPG 18/07/2007  10.10    <DIR>          . 18/07/2007  10.10    <DIR>          .. 18/07/2007  10.10    <DIR>          backup1 18/07/2007  10.10             2.616 public.asc 18/07/2007  10.10               570 pubring.bak 18/07/2007  10.10             1.828 pubring.gpg 18/07/2007  10.10               600 random_seed 18/07/2007  10.10             3.770 secret.asc 18/07/2007  10.10             2.666 secring.gpg 18/07/2007  10.10             3.696 subsecret.asc 18/07/2007  10.10             1.280 trustdb.gpg                8 File(s)         17.026 bytes                3 Dir(s)     123.456.789 bytes free

The first one ("public.asc") contains our public keys, which we must give to everybody (directly, putting on the WEB or using a Keyserver); the second one ("secret.asc") contains all our secret keys, which we must keep secret and never show to anyone; the third one ("subsecret.asc") also contains our secret keys, but without the secret part of the primary key (also this file must be kept secret and never shown to anyone but, contrary to the second one, it can be daily used).
For completeness, I recall here that both the files which contain the secret keys contains also the corresponding public keys.


We do now a new backup of the keyrings (only to be safe during the following procedure, we will erase such backups at the end):

T:\GnuPG>md backup2 T:\GnuPG>copy *.gpg backup2 pubring.gpg secring.gpg trustdb.gpg         3 file(s) copied.

and we delete the keys from our keyrings (we will understand the reason later):

T:\GnuPG>gpg --delete-secret-and-public-key 1A2B3INV gpg (GnuPG) 1.4.8; Copyright (C) 2007 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. sec  1024D/1A2B3INV 2007-07-18 Test Key (No Comment) <address@mail.invalid> Delete this key from the keyring? (y/N) y This is a secret key! - really delete? (y/N) y pub  1024D/1A2B3INV 2007-07-18 Test Key (No Comment) <address@mail.invalid> Delete this key from the keyring? (y/N) y

Instead of using this command, it is also possible to delete completely the keyrings, so to start again with clean keyrings where the keys can be reimported (you are free to chose the method).

Now, our keyrings will be empty:

T:\GnuPG>gpg --list-keys gpg: checking the trustdb gpg: no ultimately trusted keys found T:\GnuPG>gpg --list-secret-keys T:\GnuPG>

We can therefore reimport what we are now really interested in (the file "subsecret.asc"):

T:\GnuPG>gpg --import subsecret.asc gpg: key 1A2B3INV: secret key imported gpg: key 1A2B3INV: "Test Key (No Comment) <address@mail.invalid>" not changed gpg: Total number processed: 1 gpg:               imported: 1 gpg:       secret keys read: 1 gpg:   secret keys imported: 1

Asking the present status of our keyrings, we would get:

T:\GnuPG>gpg --list-keys t:/gnupg\pubring.gpg -------------------- pub   1024D/1A2B3INV 2007-07-18 uid                  Test Key (No Comment) <address@mail.invalid> sub   2048R/8E9F0INV 2007-07-18 [expires: 2008-07-18] sub   2048g/7A8B9INV 2007-07-18 [expires: 2008-07-18] T:\GnuPG>gpg --list-secret-keys t:/gnupg\secring.gpg -------------------- sec#  1024D/1A2B3INV 2007-07-18 uid                  Test Key (No Comment) <address@mail.invalid> ssb   2048R/8E9F0INV 2007-07-18 ssb   2048g/7A8B9INV 2007-07-18

As you can see, the ("#") alongside the "sec" means that the secret part of the primary key is missing.
This key therefore cannot be used to perform any operation which requires the primary secret key (as, e.g., signing other keys).

Now, it is necessary to set the trust level of our key before using it:

T:\GnuPG>gpg --edit-key 1A2B3INV gpg (GnuPG) 1.4.8; Copyright (C) 2007 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. Secret key is available. pub  1024D/1A2B3INV  created: 2007-07-18  expires: never       usage: SC                      trust: unknown       validity: unknown sub  2048R/8E9F0INV  created: 2007-07-18  expires: 2008-07-18  usage: S sub  2048g/7A8B9INV  created: 2007-07-18  expires: 2008-07-18  usage: E [ unknown] (1). Test Key (No Comment) <address@mail.invalid> Command> trust pub  1024D/1A2B3INV  created: 2007-07-18  expires: never       usage: SC                      trust: unknown       validity: unknown sub  2048R/8E9F0INV  created: 2007-07-18  expires: 2008-07-18  usage: S sub  2048g/7A8B9INV  created: 2007-07-18  expires: 2008-07-18  usage: E [ unknown] (1). Test Key (No Comment) <address@mail.invalid> Please decide how far you trust this user to correctly verify other users' keys (by looking at passports, checking fingerprints from different sources, etc.)   1 = I don't know or won't say   2 = I do NOT trust   3 = I trust marginally   4 = I trust fully   5 = I trust ultimately   m = back to the main menu Your decision? 5 Do you really want to set this key to ultimate trust? (y/N) y pub  1024D/1A2B3INV  created: 2007-07-18  expires: never       usage: SC                      trust: ultimate      validity: unknown sub  2048R/8E9F0INV  created: 2007-07-18  expires: 2008-07-18  usage: S sub  2048g/7A8B9INV  created: 2007-07-18  expires: 2008-07-18  usage: E [ unknown] (1). Test Key (No Comment) <address@mail.invalid> Please note that the shown key validity is not necessarily correct unless you restart the program. Command> quit

We can now perform the last backup:

T:\GnuPG>md backup3 T:\GnuPG>copy *.gpg backup3 pubring.gpg secring.gpg trustdb.gpg         3 file(s) copied. T:\GnuPG>copy *.asc backup1 public.asc secret.asc subsecret.asc         3 file(s) copied.

Now, all we need is:

T:\GnuPG>dir  Volume in drive T is TJL73  Volume Serial Number is 47C1-741C  Directory of T:\GnuPG 18/07/2007  10.10    <DIR>          . 18/07/2007  10.10    <DIR>          .. 18/07/2007  10.10    <DIR>          backup1 18/07/2007  10.10    <DIR>          backup2 18/07/2007  10.10    <DIR>          backup3 18/07/2007  10.10             2.616 public.asc 18/07/2007  10.10             1.828 pubring.bak 18/07/2007  10.10             1.828 pubring.gpg 18/07/2007  10.10               600 random_seed 18/07/2007  10.10             3.770 secret.asc 18/07/2007  10.10             2.611 secring.gpg 18/07/2007  10.10             3.696 subsecret.asc 18/07/2007  10.10             1.280 trustdb.gpg                8 File(s)         18.229 bytes                5 Dir(s)     123.456.789 bytes free T:\GnuPG>

• the file "public.asc", which me must give to everybody in the usual ways (WEB, Keyserver, etc.).
• the content of the "backup3" folder, which we can use daily (but still keeping it as much safe as possible);
• the content of the "backup1" folder, which we must store in an absolutely safe place and use only in special occasions (e.g.: when we have to sing other keys);

• a keypair for daily use, made of a public primary key and one or more pairs of subkeys (these last ones have a time limited validity);
• a primary keypair, made of a public primary key and a secret primary key, to be used only to sign or certify objects which do not expire (e.g. to sign other keys);
• the possibility to keep our own secret primary key in a safe place, still having together with us the secret subkeys for daily use;
• the possibility to revoke only the subkeys, if these become compromised, or to let them naturally expire ("virtually" revoking them automatically) generating new ones without any problem for the primary key;
• the possibility to keep others' signatures collected on our primary key, without having to collect them again.

• if we are almost sure that our keys have not been compromised, it will be enough to set a new expiration date for the subkeys, editing our key and using the command "expire";
• if, on the contrary, we suspect that the key has been compromised, it will be enough to revoke the subkeys or, if they are close to their expiration, to let them expire and create new ones with the command "addkey" (as already seen above);
• if we are really paranoid, we will always let the subkeys expire and we will create new ones each time.