Lots of questions

Christoph Anton Mitterer cam at mathematica.scientia.net
Thu Oct 27 01:29:27 CEST 2005

Hi everybody.

(First of all sorry for crossposting to *devel and *users,.. I supposed 
users list would be the appropriate,.. but Werner supposed *devel,.. so 
I took both)

I have lots of general and specific questions about OpenPGP/GnuPG.
First of all I'd like to say that I've already read most of the 
available material on the GnuPG website and even other resources on the 
Internet. I've also searced the GnuPG mailing list, so if I ask a 
question that had been asked before, I do this because I think the 
status might have changed in the meantime.

Until now I've always used a plain DSA/ElG key... for about some years 
now, but recently I've revoked it and I'm going to set up a new key and 
create new keyrings and a new personal web of trust.

Ok,.. for all questions: I want the most possible security and it 
wouldn't matter if an algorithm is patented or if computation takes very 
long or so ;-)
I also assume that my system itself is perfectly secure,... so please 
don't tell me that this or that security consideration or key size is 
stupid because everyone could much easier break in my house and steal my 
harddisk (btw: the disc is encryptet with AES ;-) ).
(btw: I'm using solely Linux so I don't have those fancy GUIs für GnuPG)

Of I think I'm going to have three kinds of questions:
I) Questions about GnuPG itself
II) Questions about the OpenPGP standard, i.e. the key format, 
weboftrust, etc
III Questions about the used algorithms

I'd be glad if you could give me exact answers, but also answers that I 
understand,... ok I study computer science but my last cryptography 
lecture is some years ago ;-)

I) GnuPG specific questions:

1) There are two development brances stable (1.4.x) and experimental 
a) Are there any differences in these two brances, for example in the 
key format, the key generation, security or so, expect the main 
difference: S/MIME support and more card reader support?
b) When creating a new key, that I want to use at least the next 10 
years or so (expect somone breaks asymmetric-key-algorithms): Should I 
create it with 1.4.x or 1.9.x? For security reasons an so on?

2) GnuPG (and I think OpenPGP specifies that, too?) uses hybrid 
algortihm, meaning that when encrypting data, it's first encryptet using 
a symmetric algorithm (e.g. AES) with a random sessions key and then the 
session key is encryptet using the asymmetric algorithm. Same thing with 
signatures: The data is first hashed and then the hash (and not the data 
itself) is encrypted with the private key, correct?
Are there ways to change this behavior? I mean can I use GnuPG to only 
use the asymmetric algortihms? That should be more secure, shouldn't it? 
Of course I'd be probably no longer compatible to OpenPGP (RFC 2440).

3) When GnuPG does encryption and signing. Does it encrypt first or sign 
first? If it would sign first, no one could use the signature to find 
out who it signed...

4) When using GnuPG with the standard compliance settings ( --gnupg). 
Are my keys and messages/signatures fully compatible to OpenPGP/RFC2440? 
If not: Is this only the case when communicating with 
non-OpenPGP-compatible users?

5) When creating a new key. What is the best random number source I can 
use,.. and are there ways to tune the configuration of random number 

6) In the GnuPG interface there is that "usage" field: "E" is for 
encryption only keys, "S" for signing only. What does "CS" and "CSA" mean?

7) Why doesn't GnuPG larger keys than 4096 bit (please don't answer 
nobody would need that ;-P )?

8) Does it make any difference wheter creating keys with 32-bit OS or 
64-bit OS?

9) What is that "--set-notation" option?

II) OpenPGP/Key specific questions:

Ok, as told above I'd like to use as much security as possible, and I'd 
like to keep my key as long as possible =)
So I'll try to explain how keysystem work as far as I understood it and 
ask my questions on the fly. If I miss something please correct me!!
-First, you allways have one primary key (which is always a signing-only 
key) (this might be an DSA or RSA-S key, only)
-Then, you have several subkeys, used for signing only (RSA-S, DSA) or 
encrypting only (ElGamal, RSA-E)
-Then, there are one or more User ID's

So you can make the following Key types:
Primary: DSA // Secondary: ElGamal (and perhaps other RSA-x or DSA or 
ElGamal-E keys)
Primary: RSA // Secondary: and perhaps other RSA-x or DSA or ElGamal-E keys

1) What is about RSA and ElGamal keys that can both, sign and encrypt? 
Why can't I use them? Any security reasons?
2) Is ElGamal the same as Diffie/Hellman?

-Each public key connected to it's secret key? How?

-The keys (primary and secondary) are signed with a self-signature. This 
ensures that no one modified the key, correct? Does it also assure that 
a subkey belongs to a primary key and thus to the UIDs? If so: How (e.g. 
contains the sub-key-self-signature the fingerprint of the primary key 
or so)?
-The keys (primary and secondary) self are only signed with the 
self-signature, not with signatures from other users.
-The key signatures don't contain information like preferred algorithms 
or user identifiers and so.
-Are there other reasons for primary/secondary key signatures?

-The User IDs are self-signed to. This assures that the signed UID(s) is 
from the user that has the private key (from that specific public key) 
and that nobody changed the UID, correct? Any other reasons?

-All self signatures (to my keys and UIDs) and signatures to other UIDs 
(I think I can't sign other users primary/subkeys at all) are generated 
using the primary (sign-only) key.

3) Why can't I use a (signing) subkey for self-signatures or signing 
other UIDs? Would this make sense at all?
4) How are my secondary keys connected to the primary? I know that the 
UID are connected by something like the fingerprint in the UID. And the 
UID is self-signed so nobody can change this (expect the owner of course)

5) All signatures (those that I make and that I receive) are ONLY 
connected to the Key-ID of the signing key and NOT to (one of) the UID 
of signing key, correct?
a) Thus when I change my primary UID from e.g. old at email.example to 
new at email.example all signatures that I made to other keys automatically 
show the new UID (new at email.example), correct? The same thing sould 
apply to the things on keyservers, correct? The same thing sould apply 
of course when others change ther UIDs.
6) Is this (that keyservers and software know which UID they should show 
on signatures) the only reason for making on UID the "default-UID"?

-Ok, as far as I understood there should be three types of signatures:
a) Signatures to "normal" data like an email. This should consist solely 
of the encrypted hash (by the private key) the used hashing algorithm 
and the KeyID of the signing key, correct?
b) Self-Signatures to primary/secondary keys. This should consist solely 
of the encrypted hash (by the private PRIMARY key) the used hashing 
algorithm and the KeyID of the signing key, correct?
c) Signatures to UIDs ... ok now it gets complicated?

7) Is there a difference between self-signatures to UIDs and Signatures 
to other UIDs? Which?
8) What is stored in a UID-signature?
a) It should contain the used hash-algorithm and the hash itself (of 
course) and the KeyID of the signing key (think that should be always 
primary keys), too?
b) It contains also name, email and comment, correct? (btw: Would 
RFC2440 allow other fields like address, phone, etc.?)
c) Prefered algorithms (symmetric, hash, compression). Only with 
self-signatures or with signatures to other UIDs, too?
d) The features "MDC" or "Keyserver no-modify". Are there other such 
features? Where can I find a documentation to these features? Which 
should I select for maximum security? Are those (for maximum security) 
compliant with RFC2440?
e) Other things stored in the UIDs?
f) What is about things like policy URL or photo or so?

Ok,.. now it gets even worse, I think:
When other people "sign my key" they do not sign my key, but rather one 
(or all) of my UIDs, correct? Thus they tell everybody, that this UID 
belongs to the key AND that the settings in the UID are true (more 
questions about the different kinds of signatures from others to my UIDs 
Ok,.. I told you I'd use my key as long as possible. But sometimes my 
email address changes, so I'll defenitely have more than one UID.
Big problem:
When I change my UID all signatures that I received until that would not 
count for the new ID and thus other people wouldn't recognise my new UID 
as true, correct.?
I think the best solution would be that my default UID is always 
"Christoph Anton Mitterer" without an email at all. So I could ask other 
people to sign only my default UID and (solely) because I sign my other 
UIDs with a self-signature, they would trust those UIDs, too. Correct?
Or can you think of a better model for my needs?

btw: The same thing should work with new subkeys:
Only primary keys can be used to sign other UIDs (I asked that above). 
So when someone signed (one of) my UIDs he trusts them and also the key 
that is specified in the UID (should be always the primary key). So if I 
add a subkey (and self-sign it) that someone should also trust my 
subkey, correct?

9) Another big problem: There are those things like prefered algorithms 
or features or signing policy or . What is if I change these things in 
one of my UIDs? Are oll signatures (by other people) on that UID 
invaildated? (If not: why not?)
If so: I should from the beginning set these things to final values,.. 
so perhaps once againg the question: What are the most secure settings? :-D
10) Ok I know they secret key itself is encrypted (symetricallay) with a 
passphrase... What do those s2k-x options have to do with that,.. an 
most important,.. if I decide later to change them,.. would I loose my 
signatures (from other people)
11) Are there any other options you can think of,.. that are stored in 
the key/UID that I might change later and that would lead to loosing 

12) When creating more that one encryption subkey... What could be a 
reason for doing so?
13) Same question with signing subkeys?

14) Ok,... I've got also a lot of questions to revokation, trust, 
validity the different kinds of signatures that I can make to other UIDs 
(like non-revokable and so on) but I'll ask them in a seperate email.

III) Algortihm specific questions:
Ok these questions are probably asked very often, but I risk flaming and 
ask again ;-)

1) Asymmetric algorithms:
GnuPG only supports RSA-E, RSA-S, ElGamal-E and DSA, correct? (I'd love 
to see ECC =P~ btw: is ECC only used for encryption or for (primary) 
signing keys too?)

Ok,.. I've read lots of sources,.. e.g. 

What should I use? *G*
ok,.. uhm I think DSA has one big problem,.. it's limited to 1024 bit 
(please don't say that is enough,.. I'm paranoid ;-) ) and even NIST 
seems to think about a reimplementation of DSS...
So I'd say,... for primary (signature only) key RSA-S would be the best, 

Secondary (encryption, I think at first I won't need additiona 
encryption or signing keys) key,.. in reference to the URL above,... 
they said that ElGamal is a very tiny little bit more secure than RSA-S....
So should I use the following: Primary RSA-S,... secondary ElGamal??????
I know that the default is DSA/ElGamal,.. so that RSA-S/ElGamal sounds a 
bit strange to me *g*

btw: I've read that one can create RSA keys with any fingerprint the 
attacker wants to have (but different key-size),.. does this only work 
with RSA-E or also with RSA-S,.. I mean is this a reason not to use 
RSA-S as primary key? Does it work with ElGamal, too?

2) Symmetric algorithms
I think the best preference order should be the following (from the best 
to the worst):
a) AES256
b) AES192
c) AES
f) CAST5
g) 3DES

3) Hashing algorithms
GnuPG supports: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512
I think the best preference order should be the following (from the best 
to the worst):
a) SHA512
b) SHA384
c) SHA256
d) RIPEMD160 (no sure if SHA-1 should be before this because of that 
chinese team that found collisions and so on)
e) SHA1
f) MD5

3) Compression algorithms
GnuPG supports: Uncompressed, ZIP, ZLIB, BZIP2
I think the best preference order should be the following (from the best 
to the worst):
a) BZIP2 (I don't bother if there are Windows users or so that "can't" 
support bzip2 *g* )
c) ZIP
d) Uncompressed

IV) How to create my new key the best way?

Ok these days the "Systems" is in Munich and there's the c't Magazine 
that signs keys and so on.... :-D
So I'd like to make a new key asap.... and have it signed,.. ;-)

Ok,.. now I wonder how I should do this the best and cleanest way.
I suppose my assumtions above are correct and RSA-R/ElGamal would be the 
best and that the algorithm preference is also the best, if one could 
say so...

And I suppose that the default random settings in Linux (normally I use 
debian, but I think I'll boot from a Knoppix CD to create the key,.. 
hope the include the latest version of GnuPG) are already the best, correct?

My ~/.gnupg looks:
openpgp                            #to be fully compliant to 
OpenPGP/RFC2440 AND to create v4 keys
no-force-v3-sigs                   #do I need this when I've already 
charset utf-8                      #yes my terminal uses UTF-8 :-D // or 
is the option display-charset ???
keyserver hkp://subkeys.pgp.net    #not important for key generation
list-options show-photos           #  "     "      "       "
verify-options show-photos         #  "     "      "       "
z 9                                #9 should be the value for best 
compress-level 9                   #  "     "      "       "      "     "
bzip2-compress-level 9             #  "     "      "       "      "     "

#sig-notation                      #shoudl I set one of these for better 
security of my new keys?
#cert-notation                     #  "     "      "       "      "     
"      "       "
#sig-policy-url                    #Will add this later ot my UIDs (hope 
it doens't invalidate all sigantures)
#cert-policy-url                   #  "     "      "       "      "     
"      "       "        "       "
#set-policy-url                    #  "     "      "       "      "     
"      "       "        "       "
#sig-keyserver-url                 #  "     "      "       "      "     
"      "       "        "       "

#s2k-cipher-algo                   #What is the best here? AES256?
#s2k-digest-algo                   #What is the best here? SHA384?
#s2k-mode                          #What is the best here? 3?
#simple-sk-checksum                #Shouldn't be used I think,.. ?

personal-cipher-preferences S9 S8 S7 S10 S4 S3 S2 S1      #Do these also 
set my prefered settings in my key?
personal-digest-preferences H10 H9 H8 H3 H2 H1            #Do these also 
set my prefered settings in my key?
personal-compress-preferences Z3 Z2 Z1 Z0                 #Do these also 
set my prefered settings in my key?

#cipher-algo                       #Should be already set via 
personal-XXX, correct?
#digest-algo                       #  "     "      "       "      "     "
#compress-algo                     #  "     "      "       "      "     "
#cert-digest-algo                  #  "     "      "       "      "     "

$ gpg --gen-key
$ gpg --edit-key <keyid>
adduid (Add user id "Christoph Anton Mitterer 
<mail at christoph.anton.mitterer.name>")
showpref (verify if preferences from config file are correct)

Ok the following should now apply:
-Having a default UID "Christoph Anton Mitterer"
-Havin a secondary UID "Christoph Anton Mitterer 
<mail at christoph.anton.mitterer.name>"
-private key encryptet with ??? algorithm? (Can I change this later, 
without loosing signatures?)
-all UIDs have the following settings:
S9 S8 S7 S10 S4 S3 S2 S1
H10 H9 H8 H3 H2 H1
Z3 Z2 Z1 Z0
[mdc] [no-ks-modify]
-The key have newest format (v4)?

Can I change that "sig-policy-url", "cert-policy-url", "set-policy-url" 
and "sig-keyserver-url" later without loosing signatures on the UID?

Ok,.. later I'm going to play with Smartcards, too :-)

Ok,.. that's it for the moment,... *puhh*

Lots of thanks and hugs for any help. :-)

Best wishes,

More information about the Gnupg-devel mailing list