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
(1.9.x).
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
generation?
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)
or
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
later)
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
signatures?
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.
http://www.scramdisk.clara.net/pgpfaq.html
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,
correct?
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
GnuPG supports: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH
I think the best preference order should be the following (from the best
to the worst):
a) AES256
b) AES192
c) AES
d) TWOFISH
e) BLOWFISH
f) CAST5
g) 3DES
Correct?
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
Correct?
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* )
b) ZLIB
c) ZIP
d) Uncompressed
Correct?
------------------------------------------------------------------------
------------------------------------------------------------------------
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
"openpgp"
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 # " " " "
verbose
verbose
verbose
z 9 #9 should be the value for best
compression
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,.. ?
force-mdc
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)
store
$
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,
Chris.
More information about the Gnupg-devel
mailing list