"Please select what kind of key you want"

[Robert J. Hansen]

> Michael W. Lucas on page 73 in Chapter 4 of "PGP & GPG:  Email for  
> the Practical Paranoid",
> No Starch Press, (c) 2006, shows the following choices for
> "Please select what kind of key you want":
>   (1) DSA and Elgamal (default)
>   (2) DSA (sign only)
>   (5) RSA (sign only)
>
> Michael recommends choosing "5" which turns out to be a disadvantage
> that one might not discover until the first time that she/he  
> attempts to
> encrypt something.

In 2006, Lucas's advice was pretty solid.  In 2009, not so much.  The  
introduction of DSA2 has resolved most -- if not all -- of the reasons  
that motivated him and others to suggest RSA.

> AFAIK, other people can still encrypt for the user who has selected  
> "5"
> above.  And the user can decrypt whatever she/he receives.

Not with a sign-only key.  A sign-only key is only usable for signing;  
other people cannot encrypt to a sign-only key.

> Why is there no "(3)" in the above two lists [gen-key list, addkey  
> list]?

Elgamal signing keys were #3, IIRC. They were removed years ago due to  
some catastrophic bugs and the community's near-total abjuration of  
Elgamal signing keys. (IIRC, the total number of Elgamal signing keys  
on the keyserver network was in the neighborhood of 10.)

> Why are choices "(4) Elgamal (encrypt only)" and "(6) RSA (encrypt  
> only)"
> not present in the "gen-key" list?

Because when you generate a new key you /must/ generate a signing  
key.  #s 4 and 6 are encryption-only keys, which means they can only  
be added to an already-existing signing key.

> Why is choices "(1) DSA and Elgamal (default)" not present in the  
> "addkey" list?

Why should they be?

If you want to add a new DSA signing key, you can do that.  If you  
want to add a new Elgamal encryption key, you can do that.  Where's  
the problem?

> Also, I'm guessing that although a developer might opt out of  
> creating a key of type X,
> regardless, the developer must presumably support a complete set of  
> encryption/decryption
> choices for the purpose of processing public and private keys  
> properly.  Is this the case?

Nope.  An OpenPGP implementation is not required to support most of  
those algorithms.  You can have a perfectly well conforming OpenPGP  
implementation which only supports SHA-1, DSA, Elgamal and 3DES.