I do a lot of security training, and often teach people how to use gnupg. One of the main criticisms that come back
to me all the time is that it is really hard to use from a user interface perspective. I've been collecting those
criticisms over the years and have been thinking of ways to make things easier for people.

One easy way to start would be at the beginning, with key generation. This is typically what we do a training, and
often don't get much further than just generating the keys and then maybe trying them out. I'd like to streamline the
key generation process so we can get into the more important things sooner, like how to encrypt files, or emails, or
how to revoke your key, etc.

I think there is a simple way to do this. Make gpg --gen-key pick sensible defaults for you and only ask you the easy
questions (unless an --advanced flag is passed).

That means that when you do 'gpg --gen-key' you should not be prompted immediately with the type of key that you
want:

Please select what kind of key you want:

(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
(7) DSA (set your own capabilities)
(8) RSA (set your own capabilities)

Your selection?

just use the default option, which is marked default and don't even ask (again, unless an advanced flag is set). Do
the same for the key size, which is 2048 by default, and the subkey. Don't ask for bitsize, just make the key.

What is RSA, DSA, and Elgamal, why would I want to pick one over the other, what is bitsize, and which one do I want
and why? All of these are complicated questions that quickly overload people who are not familiar with the concepts.
I don't want to say that these things people should not learn, I'm simply saying that from the beginning, someone who
has absolutely no clue about this stuff, needs to learn a lot of other more important concepts before they start
digging around into crypto algo choices. Once you are familiar with the concept of PKI, and can send and receive
emails encrypted, and know how to do some basic maintenance on your key, only then should you be starting to get into
these more difficult concepts.

The next step in key generation is about key expiration. This is one of the more difficult concepts for people to
understand. From a usability perspective, I would suggest automatically setting the key to expire after 2 years (this
is somewhat of a guess about time frame based on how long people I've worked with have had their keys for before they
"lost" them. This time frame could be debated, but I think that 1 year is too short, and never is too long). Instead
of prompting the user for this time, instead print something short and clear, such as the following, "Your key will
be usable for 2 years, after that time it will not work unless you update the expiration. Please make a note in your
calendar for <date>, which is one week before it will stop being usable, to update the expiration. Include in the
note that you will need to run gpg --update-expiration to do so." and then require that the user hit <enter> here to
acknowledge and move on. Notice that this is the first time that the user has to do anything.

Note: --update-expiration is not a real flag right now, but this should be added to streamline this process. Another
major stumbling block for people with gnupg is the --edit-key process. Not only the name is confusing, but then
interacting with the gnupg cli to toggle keys and their expiration is arcane, at best. The --update-expiration flag
would make this entire process simple by simply asking you when the next expiration should be and then updating all
of your keys (primary and subkeys) and automatically pushing those changes to the keyserver. That usability
improvement alone would change a lot for people. Again, you still would maintain the option of doing --edit-key for
more advanced users.

The next step in key creation process is:

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:

I suggest to remove all of that, and just ask "Enter your full name:", then "Enter your email address", and then do
*not* ask for a Comment. Why? Because this is a stumbling block for new people. They have no idea what this comment
is for, and they require an expert to explain to them that they don't need it right now. The --advanced flag would
allow you to specify this if you like. This results in:

You selected this USER-ID:

    "Heinrich Heine <heinrichh@duesseldorf.de>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit?

I would suggest the following change:

Your user-id will be the following:

    "Heinrich Heine <heinrichh@duesseldorf.de>"

Is this correct? [Y/n]

Some small wording changes, and a simpler prompt that allows you to change things if necessary.

Now the key is generated. I would suggest removing some of the output, changing this:

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.
..........+++++
..+++++
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: key 0x5484E77F06DAF39A 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: 3 signed: 77 trust: 0-, 0q, 0n, 0m, 0f, 3u
gpg: depth: 1 valid: 77 signed: 233 trust: 64-, 0q, 0n, 8m, 5f, 0u
gpg: depth: 2 valid: 22 signed: 145 trust: 20-, 0q, 0n, 2m, 0f, 0u
gpg: next trustdb check due at 2013-06-13
pub 2048R/0x5484E77F06DAF39A 2013-06-12 [expires: 2013-06-13]

Key fingerprint = EDD2 5F8D 623C 2CF0 284D  C7C9 5484 E77F 06DA F39A

uid [ultimate] Heinrich Heine <heinrichh@duesseldorf.de>
sub 2048R/0x5BB6EF1C99219EC1 2013-06-12 [expires: 2013-06-13]

To this:

We are generating your key now. This might take some time.

You can speed up this process by doing other things on your computer
which will help us create a secure key, such as typing, moving your mouse,
or accessing your disk.

......>

Congratulations! Your key has been created.

Make note of your new key ID and fingerprint so you can share it with others:
Your key ID: 0x5484E77F06DAF39A
Its fingerprint is: EDD2 5F8D 623C 2CF0 284D C7C9 5484 E77F 06DA F39A

We are almost finished. Now we need to create a "revocation certificate" so that
if you lose access to your key, your hard drive crashes and you have no backups, or
something else happens, you can disable your key.

Creating revocation certificate.... done!

Your revocation certificate has been placed in <path to revocation certificate>, you
should print a hardcopy of the certificate and store it somewhere safe, or put this
digital copy somewhere safe. If someone gets access to this file, they can revoke your key,
which is very inconvenient.

The last step is publishing your key to the public key servers. Do you wish to publish
your key now? [Y/n]

Sending your key to the keyservers now.... success!

You are now ready to use your new key.
<end>

Notice a few things:

1. I removed the technobabble, things like entropy and mysterious dots and plus symbols while gathering the entropy

don't help people who have no idea what they are. Instead just make the text simple and provide a simple "progress
bar" (I know, it isn't possible to make a reasonable progress bar, but the whole thing is more or less psychological
and is familiar to people).

2. Congratulating the user helps them feel like they did the right thing. I know it seems stupid, but crypto is hard

for people, and getting some kind of positive feedback helps reassure them that they are doing the right thing.

3. Tell them to note their key id and fingerprint, but don't provide any of the other stuff which is confusing.

4. Remove all the trustdb output, nobody knows what that means, and the concepts are too hard there to explain to new

people, so I always just tell people to ignore it.

5. Immediately step people through the revocation certificate creation process and publishing to the keyservers.

People should have these things and the new key generation process should walk them through it.

Ok, that is all for now. I think if you were able to do any one of the above, it would be an immediate and
significant improvement for people who do not use this stuff on a regular basis. I am aware that it is uncomfortable
to remove some of the options and useful information that is presented, this is why I think that it should continue
to be there for people who want/need that information, but otherwise made simple for those who are just starting out
and struggling to understand the basic concepts.

Thanks for your time in considering this! I'm tired of people complaining that this is too hard, and I think we can
make it better so they stop.