Key generation, subkeys and improved documentation

[Nex6|Bill]

> On Jan 5, 2015, at 7:54 AM, Sandeep Murthy <s.murthy at mykolab.com> wrote:
> 
> Hi
> 
> I have a couple of questions about key generation, subkeys and the documentation
> on gnupg.org.
> 
> (FYI I have GnuPG/MacGPG (v. 2.0.26) on my Mac.)
> 
> 1. I just tried to generate an RSA keypair using `gpg` on the command line, and it
> asks me to choose a key length between 1024 and 8192.  Here is the relevant output
> from my terminal session:
> 
>    RSA keys may be between 1024 and 8192 bits long.
>    What keysize do you want? (2048) 8192
>    Requested keysize is 8192 bits
> 
> I thought the maximum was 4096?  For example, GPGKeychain (the GUI keychain
> utility from the GPGTools suite which installs the GnuPG/MacGPG) doesnt’t allow
> key sizes bigger than 4096.  In any case, choosing 8192 fails with `gpg`:
> 
>    gpg: keysize invalid; using 4096 bits
> 
> Shouldn’t this be changed to ensure that 4096 is the limit, or is it possible to have
> an 8192 length RSA key or this limited by the current capabilities of the random
> number generator?
> 
> 2. The key generation dialogue for v. 2.0.26 (started by `gpg —gen-key`) shows
> the following list of options for keys:
> 
>    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)
> 
> As a user this is confusing to see, for example, RSA and RSA - of course I worked
> out afterwards that this was going to generate two keypairs one for signatures (S),
> the other for encryption (E), but at the moment it’s just confusing, even if have to
> generate new keys again.  There is also no explanation that the public key itself is
> a pair of keys, one which actually makes the signatures using the private key, and
> the other (subkey) which others use to encrypt messages to you.
> 
> Also these subway codes S, E, and also C, A are not explained at all - I had to
> lookup the source code (‘keyedit.c` in the `/g10/ subfolder of the source folder) to
> guess at what they mean.
> 
> For example, here is the information provided by `gpg` for my keybase.io public key:
> 
> pub  4096R/9EAB92B4  created: 2014-12-30  expires: never       usage: SCEA
>                     trust: ultimate      validity: ultimate
> sub  2048R/238026C5  created: 2014-12-30  expires: 2022-12-28  usage: S
> sub  2048R/66C9185A  created: 2014-12-30  expires: 2022-12-28  usage: E
> [ultimate] (1). keybase.io/sandeepmurthy <sandeepmurthy at keybase.io>
> 
> There should be an explanation surely of what S C E A mean: S (signatures),
> E (encryption), C (creating a certificate) and A (authentication?).
> 
> 3. At the moment the documentation on gnupg.org - both the manuals and the
> privacy handbook - are out of date for v. 2.x+), e.g. the privacy handbook
> https://www.gnupg.org/gph/en/manual/c14.html showing the possible keypair
> choices as
> 
>   (1) DSA and ElGamal (default)
>   (2) DSA (sign only)
>   (4) ElGamal (sign and encrypt)
> 
> which is obviously different from what the current one version allows.  Perhaps
> there should be a much better explanation of subways and the codes S, C, E, A,
> because I don’t think it’s there right now.  Since the handbook is aimed at first
> time users it seems these updates should be (and could be) made very quickly.
> 
> I use GnuPG but I would also like to contribute.  Would it be possible to clone
> the repo and make a pull request or something like that?
> 
> Sandeep Murthy
> s.murthy at mykolab.com <mailto:s.murthy at mykolab.com>


I believe the recommendation from the GPG folks is a 2048 key pair. But I have seen some of the more paranoid privacy folks doing 4096 key pairs.

Other than that most of the defaults are good.

Nex6
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150105/99f31fde/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </pipermail/attachments/20150105/99f31fde/attachment.sig>