Lots of questions

[Sven Radde]

Hello!

I can't answer all your questions, but I will go for those that I can.


Christoph Anton Mitterer schrieb:

> 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?

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).

AFAIK, it is actually *less* secure to conduct purely asymmetric
operations on large amounts of data.
Think of it so that encrypting/signing only hash-values exposes your
private key much less as there is less data available to analyze.
And using purely asymmetric encryption would be much (and I mean
*really* much) slower.

> 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...

I think it signs first. After all, no one who can't decrypt a message
should know whether it's signed or not.
You could use detached signatures on encrypted files, though.

> 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?

As there are prefenrences embedded in the keys regarding the available
algorithms, GnuPG in general does a good job to find a compatible way of
handling things. There are some more subtle issues, though, so if you
know what software your communication partner uses, you should go for
the appropriate --pgp# option.

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

It is already the case with 4096bit keys that the asymmetric operations
aren't the weakest link of the whole process any longer. It's more the
hash functions and maybe even the symmetric algorithms under these
circumstances.
In other words: It doesn't gain you anything while only making the whole
thing go much slower (4096 bit signing/decrypting already takes a
noticeable amount of time on my PC and it scales badly).

> 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

Right.

> 1) What is about RSA and ElGamal keys that can both, sign and encrypt?
> Why can't I use them? Any security reasons?

ElGamal signing keys were found to be fatally insecure and therefore
have been removed from GnuPG with version 1.2.3 (or so).
You *can* create a RSA sign+encrypt key with "gpg --gen-key --expert".

> 2) Is ElGamal the same as Diffie/Hellman?

Yes. Two names for essentially the same thing.

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

Simplified, the public key is derived via a mathematical computation
from the secret key. The computation is designed in a way that can not
easily be reversed (such as factoring the product of two very large
prime numbers).
The logical connection would simply be that only the fitting secret key
can decrypt anything from the respective public key.

> -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 primary is used to "self-sign" itself and all subkeys and user-ids
on your key.
Think of the key as being separated in several parts that are all
treated as separate documents signed with the usual procedure to sign
any kind of data.

> -The keys (primary and secondary) self are only signed with the
> self-signature, not with signatures from other users.

Yes. Other users would sign user-ids associated with the key. Thereby
they state that they are convinced that the signed user-id actually
belongs to the user with the given id. The connection between the
user-id and the cryptographic key itself is accompliched via the
self-signature.

> -The key signatures don't contain information like preferred
> algorithms or user identifiers and so.

I don't know where exactly it is stored, but a key (as a whole) contains
algorithm preferences. user-ids are only stored in user-ids.

> -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?

Right. This makes the connection between the key and the user-ids.

> 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)

The secondary keys are signed with the private key.

> 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.

Yes, if the others update their key.

> 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"?

I think so. You simply choose which of you UIDs will be displayed first.

> 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.?

Yes. That's actually the whole point with signing UIDs.

> 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?

See the discussion currently going in the "Delete key from keyserver"
thread. People are argumenting about this very issue.

> 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?

This is 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?)

At least the algorithm-preferences can be changed without invalidating
anything as they are IMHO not tied to an UID but rather to your primary key.

> 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?)

Correct.

> 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?

In your case, I would simply go for 4096 bit RSA.

> 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?

I don't like CAST, but this is a personal opinion.

> 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?

You may want to deactivate MD5 altogether. (Just leave its number out of
your preferences-list.)

> 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?

There is no need to bother: If you encrypt to a windows user, his key
will indicate that it doesn't understand bzip2 and your GnuPG will
automatically choose a mutually supported algorithm.

That's what I can answer.

cu, Sven