Lots of questions

[Alphax]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Disclaimer: I'm not a developer, hence I haven't crossposted to -devel.

Any answers given here are my own opinions and might be completely
wrong. You have been warned.

Christoph Anton Mitterer wrote:
<snip>
> (btw: I'm using solely Linux so I don't have those fancy GUIs für GnuPG)
> 

KGPG is available for KDE and SeaHorse is available for GNOME.

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

There shouldn't be.

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

Either; they should be the same.

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

You /can/ encrypt thing symmetrically only using the --symmetric option;
keep in mind that this requires you and the recipients to have somehow
securely agreed on a passphrase to be used for such purposes. I suggest
Diceware (http://world.std.com/~reinhold/diceware.html) be used to
generate such passphrases.

Signing with a symmetric algorithm is useless, because in order to
verify the signature you would need to have the key used to sign the
message digest (hash); however, if you have the key, you can generate
your own signature!

Public Key crytography relies on asymmetric algorithms, with a public
half and a secret half. If you have the public half, you can communicate
with (encrypt messages to and decrypt (verify) messages from) the secret
half; if you have the secret half, you can communicate with (encrypt
messages to (sign) and decrypt messages from) the public half. But if
you only have the public half, you cannot read what someone else has
encrypted using the public half.

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

Not entirely sure. I think it might actually do both, depending on your
settings.

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

Well, they /should/ be. The best answer I can give is the manpage entry:

> --gnupg     Use  standard  GnuPG behavior.  This is essentially
>             OpenPGP behavior (see  --openpgp),  but  with  some
>             additional  workarounds  for  common  compatibility
>             problems in different versions of PGP.  This is the
>             default  option, so it is not generally needed, but
>             it may be useful to override a different compliance
>             option in the gpg.conf file.
> 
> --openpgp   Reset all packet, cipher and digest options to
>             strict OpenPGP behavior.  Use this option to  reset
>             all   previous  options  like  --rfc1991,  --force-v3-sigs,
>            --s2k-*, --cipher-algo, --digest-algo  and
>            --compress-algo  to  OpenPGP compliant values.  All
>            PGP workarounds are disabled.

You can use --openpgp to be sure.

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

A radiation source. Failing that, HotBits
(http://www.fourmilab.ch/hotbits/). Failing that, dice. Failing that,
the Entropy Gathering Daemon (http://egd.sourceforge.net/), which was
designed for use with GPG. The EGD homepage has instructions on how to
configure GPG to use it. EGD is the most practical of all these suggestions.

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

C is "certification" - I believe this means that you can sign other keys
with it (not entirely sure). A is "authentication" which I think means
you can use it for eg. SSH authentication, unlocking your computer -
authentication keys are probably most useful when on a smartcard.

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

Because not everyone has the internet bandwidth or processer/memory
requirements to encrypt/decrypt with anything much bigger. It's also
believed that at present, such keys are "sufficiently large" to prevent
all known attacks for the forseeable future. Again, no guarantees.

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

It shouldn't...

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

No idea. Probably for future uses.


> II) OpenPGP/Key specific questions:
>
> -First, you allways have one primary key (which is always a signing-only
> key) (this might be an DSA or RSA-S key, only)

Yes, although this can be disabled. The reasons for why you might want
are far too long to detail here.

> -Then, you have several subkeys, used for signing only (RSA-S, DSA) or
> encrypting only (ElGamal, RSA-E)

It's also possible to generate RSA keys which do any combination of
signing, encryption and authentication, and DSA keys can any signing
and/or authentication (I think).

Note that ElGamal keys can NOT be used for signing, only encryption. I
believe that ElGamal signing keys leak the secret key.

> -Then, there are one or more User ID's
> 

Yes. I have no idea what the actual key structure is though.

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

If a sign+encrypt key is compromised, you stand to lose far more than if
only a signing or only an encryption key is compromised.

As I stated above, ElGamal can *NOT* be used for signing.

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

No. I have no idea what Diffie/Hellman keys are or how they work. Note
that Diffie/Hellman can also refer to the key exchange protocol or DSA
(DSS?) keys; it's possibly the most ambiguous term in public key
cryptography - "trust" comes a very close second.

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

The simplest (most understood) system is that which RSA uses. Wikipedia
has a fairly detailed article on it, available in:

 - English (http://en.wikipedia.org/wiki/RSA)
 - German (http://de.wikipedia.org/wiki/RSA-Kryptosystem)
 - French (http://fr.wikipedia.org/wiki/Rivest_Shamir_Adleman)
 - Italian (http://it.wikipedia.org/wiki/RSA)
 - Dutch (http://nl.wikipedia.org/wiki/RSA_%28Cryptografie%29)

and several other languages. </end plug>

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

Yes, the selfsigs bind UIDs and subkeys to the primary key. All UIDs and
subkeys are signed with the secret part of the primary key. If the
selfsig on a subkey was the the selfsigned fingerprint of the primary, I
could attach my subkey to anyone else's primary key.

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

I believe so.

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

No.

> -Are there other reasons for primary/secondary key signatures?
> 

Apart from to ensure that the secret part of the primary key exists and
that the subkey does indeed belong to the primary it is attached to, I
don't think so.

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

That the owner of the key is making a claim that they are who the UID
says they are?

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

Yes.

> 3) Why can't I use a (signing) subkey for self-signatures or signing
> other UIDs? Would this make sense at all?

Because subkeys are a relatively new thing; many keyservers (and
probably much software) cannot correctly deal with subkeys. Apart from
that, it makes no sense. I can't tell you exactly why; I just know that
it doesn't make sense.

> 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 UIDs are connected the primary by 1) being attached to the primary
key, 2) being (self-)signed with the secret part of the primary key. GPG
(or any other OpenPGP program that I know of) won't allow you to change
a UID once it's been created; you can only add, delete and revoke UIDs.

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

Signatures are made with the keyid; hence you can have signing subkeys.

> 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. However, this *does* affect how trust calculations are done, since
signatures are made *to* the 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"?
> 

You might use the "primary" flag on a UID to indicate "I check this
email address every day; the others I only check once a week" or whatever.

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

Yes, although the last 2 are extractable from the signature itself,
depending on the particular software, keytype and such.

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

I think so.

> c) Signatures to UIDs ... ok now it gets complicated?
> 

The encrypted hash using (I have no idea what hash algorithm) of the UID
as a UTF-8 string. I think.

> 7) Is there a difference between self-signatures to UIDs and Signatures
> to other UIDs? Which?

I believe that they are functionaly equivalent.

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

And the timestamp, verification level, expiry date, revocation status,
and notation data (eg. policy URL).

> b) It contains also name, email and comment, correct? (btw: Would
> RFC2440 allow other fields like address, phone, etc.?)

It contains whatever the UID says it contains. There are also PhotoIDs
and "freeform" UIDs, with the possibility of expansion in the "user
attribute packet" area (currently used for PhotoIDs).

> c) Prefered algorithms (symmetric, hash, compression). Only with
> self-signatures or with signatures to other UIDs, too?

Not entirely sure how these are stored; I believe as a packet attached
to the UID, with the selfsig timestamp updated whenever prefs are changed.

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

The GPG man pages. MDC lets you know when an encrypted message has been
tampered with; I have no idea what keyserver no-modify does and cannot
find it in the man page.

> e) Other things stored in the UIDs?

Notation data? Not entirely sure.

> f) What is about things like policy URL or photo or so?
> 

Policy URL is stored in signatures; to communicate a policy URL via a
UID, self-sign your key while specifying the policy URL. Photos get
their own UIDs.

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

I don't think the anything but the selfsig makes any claim about the
prefs on the key. Hrm. Maybe selfsigs *are* different.

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

There have been many suggestions on this. Read and ask around some more,
lots of people will tell you what they think. I have no personal opinion
on the matter (that I'm aware of).

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

Yes.

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

No. It sounds more and more like selfsigs are indeed "special".

> 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

Whatever meets your security needs and keytype...

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

No. The s2k-* options determine how your secret key is stored locally
(or how it is exported, if you export it). Changing it does *not* change
the secret key, only how it is stored.

Note that if you change any s2k-* options, you need to change your
passphrase (even to the same thing) before the changes take effect.

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

What you put in your UID is up to you, but the contents will determine
who will/won't sign/trust your key.

> 12) When creating more that one encryption subkey... What could be a
> reason for doing so?

If you planned to expire or revoke one... again, not entirely sure.

> 13) Same question with signing subkeys?
> 

Aha! It lets you send signed email from an "insecure" environment
without exposing the secret part of the primary key. An excellent
subkeys tutorial:

http://fortytwo.ch/gpg/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.

Good idea, this one is pretty long :)

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

ECC is (apparantly) on it's way in a future version of OpenPGP; I
believe that there is a keytype reserved for it. The same goes for
Diffie/Hellman.

ElGamal primary keys existed very briefly, but were found to be
incredibly insecure. I believe that they have been dropped from OpenPGP.

> Ok,.. I've read lots of sources,.. e.g.
> http://www.scramdisk.clara.net/pgpfaq.html
> 

Wow, that's old :) Try the GNU Privacy Guard Handbook:

http://www.gnupg.org/gph/en/manual.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?
> 

Yes. Earlier this year new timing attacks were published against SHA1
which have severely weakened the value of DSA keys, due to the fact that
current DSA signatures don't actually say in the signature block itself
which has was used. At present, RSA is "recommended" by various people,
myself included. Again, I'm not an expert - I haven't even properly
studied cryptography.

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

Bit-for-bit, ElGamal is believed to be "marginally" more secure. Several
people I have spoken to have done exactly this; generate an RSA
sign-only primary key, and add ElGamal encryption subkeys. It's even
possible to add extra RSA signing keys - I did this to "fix" my current
DSA key in the short-term.

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

Not exactly...

It's possible to fake the last 32 bits of a key, ie. the shortid. The
most common example of this is 0xDEADBEEF. However, I believe that the
other half (usually secret) of such a key is impossible to produce. Not
entirely sure though.

Forging key fingerprints is (as yet) not possible.

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

No guarantees of "correctness", EVER, but it's a reaonsable choice.

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

SHA384 is /useless/. It's just a truncuated version of SHA512. In my
mind (and remember, I'm just some guy answering your email), it's a
security risk.

RIPEMD160 is currently the best choice for a 160-bit hash algorithm,
provided you use an RSA key. SHA1 is not completely broken *yet*, but
it's a lot less secure than it was before Februrary.

MD5 is completly and utter broken, in real time.

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

Since you "don't care" about Windows users, bzip2 is fine. GPG is pretty
good though; I use Windows and don't have any problems with bzip2.

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

Join a Linux User's Group, put your key on Biglumber, and attend
keysignings.

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

RSA-S/ElGamal-E with your prefs should be OK; prefs can always be changed.

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

Set your s2k-* options as strong as you can and use the best RNG you can.

> My ~/.gnupg looks:
<snip>

A lot fuller than mine :)

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

These are settings in gpg.conf and are only applied when making signatures.

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

Keep in mind that you will be "called on" to help debug new them if you
get one :)

- --
Alphax                      |   /"\
Encrypted Email Preferred   |   \ /     ASCII Ribbon Campaign
OpenPGP key ID: 0xF874C613  |    X   Against HTML email & vCards
http://tinyurl.com/cc9up    |   / \
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQEVAwUBQ2Cw0LMAAH8MeUlWAQh8MggAiYkxFPaB+y75tXWI52nvCYgKI1C9bYgV
nPyiOPjTl32Hywa4f1C2KmZ/bTLr7FWTN7kcZdu7Ws/ZrmgqRkL7/vPpLNNi6+K3
jNDsMeM7+m7IlYKf7VQeuJiqhGCT9guvSKLBcC648joayUxJjUHIU/G1oYaQhWTC
cpzVJsmFOhli2pUxAv6G4/01jcqmdDeJv0yfvpUHMrWLctpQv/kPcR7UyI7QVT1T
n9HFE2FBBqz63c4uDkJZGodNlgRjk7bZWL5dI3cjCrinHutoNTkfN8lzWhdNtVyJ
0K5zMVukB44nHodCiSVWdNk1h9nhvi71q1VbDMubb0+r7wxlDNfDBA==
=EzW3
-----END PGP SIGNATURE-----