Bunch of stupid(?) Newbie Questions :)

[David Picón Álvarez]

--=_W_Lxz1fZ.5XiMkIG0nnxfhpcRy8C.P
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

I hope I can shed some light on your questions.

> - - DSA/RSA + ElGamal
> In the beginning there was only a keypair - divided into public and
> private part. Like two puzzle pieces, none works without the other
> part. Private is my very secret and the public key is for the public
> to send me encrypted messages. OK so far. But creating a new key
> (--gen-key) I see there is more. In the Handbook there is also a
> little mention that there is the DSA/RSA Keypair is for signing and
> the ElGamal Part for encryption. But do I have then two keypairs? How
> does this work together? Why two keypairs?


OK, at present, the most standard situation is to have two keypairs, one for
signing and one for encrypting. In actuality, the two keypairs are bound
together by a signature, that is, the encryption keypair is considered
secondary, and the signing keypair is considered primary. This is because
you need to bind one of the keypairs to the other, and the way to do this is
through a digital signature. At any rate, if you don't want to play all that
much you don't need to know much about this. The reasons, as I understand
them, why ElGamal is not used for signatures is because ElGamal signatures
are somewhat tricky to make secure, and they are bigger. A DSA key (digital
signature algorithm) cannot have more than 1024 bits because that would
break compliance with the DSA specification. An RSA signing key can go up to
4096 bits, at least under gnupg, and probably higher under other openpgp
software.

Moreover, you can set expiry dates on the encryption subkey in order to
increase security. You can change the encryption key every six months, and
yet keep all your signatures, since only your primary key gets signed, and
maintain the same key ID and keep capability to sign like before and so on.
You can keep (if you bother enough) both keypairs separate, so that if the
govermment forces you to surrender the encryption key you don't need to
surrender the signing key, and thus can revoke the encryption key and start
again without needing to revoke the whole thing and without loosing
signatures.

However, if you run --gen-key with the option --expert, you will see there
are some more options. Options 4 and 7 don't work on the basis of two
keypairs, but only one. 4 uses a single ElGamal key (which can go up to 4096
bits) both for signing and encryption. This is my personal preferencxe, but
it is incompatible with pgp and with certain keyservers, and the signatures
are big, so it is disrecomended. On the other hand, I don't know if there is
something wrong with type 7. In my understanding type 7 keys are secure and
so on. They are RSA (sign and encrypt) and can go up to 4096 bits as well.

> - - _Why_ the DSA/RSA Part cannot be bigger than 1024 Bit key length?

DSA compliance. The RSA part can be bigger than 1024.

> - - What is the fingerprint of a public key? What does it tell me? What
> do I need it for? Is it a signature?

The fingerprint of a v4 (modern) key is made of the last 8 bytes of the hash
of the key. It is quasi-unique, and in that sense you can talk of it as a
signature of the key. It serves you to verify that the key with a certain
User ID belongs to the user, by contacting the user through a secure channel
and asking him the fingerprint for his key. As far as I know, it is not
feasible to generate a key with the fingerprint of another key, so if the
fingerprint corresponds, you can be quite sure the key belongs to the right
person. This can avoid a man-in-the-middle attack in which someone would
pretend to be the guy you want to talk to, slip his own key, intercept the
mail, re-encrypt it with the real key and transparently snoop on the
channel.
Also, it makes it easier for the software to find a key inside the keyring.

> - - I have generated a revoke certificate - How to use it? How to tell
> the keyservers? It'll only work as revoked if my keymates regularly
> check the keyserver if my pub key is still valid, right?

In order to use a revocation certificate, import it as though it were a key,
with --import. You can then upload your key to the keyservers. You should
distribute the key to your regular friends, so that even if they don't check
with the keyserver they'll know the key is revoked. If they don't update the
key from keyservers and don't receive it from somewhere else (such as you)
they won't nknow it's revoked and they'll keep on using it.

> - - Net of Trust: I download a pub key of my friend. Sign it with my
> private key (DSA/RSA?). Than upload it to the keyserver where I got
> it from and everything is fine. Now the public key of my friend has
> two signatures - his own and mine. Does this process add or overwrite
> the public key? I mean could I taint a public key of someone by
> uploading his pub key with no or less signatures or uploading a pub
> key with his key ID and different pub key? I mean how secure is this
> key server stuff?

The key ID is obtainable from the key itself, thus no chance to pretend you
have a different key ID. When you upload a public key, the server doesn't
overwrite, qbut just merges. Same as when you import a key, gpg doesn't
overwrite but just mergers new signatures, user ids, new expiry dates, etc.

> - - what is the great difference between gpg and pgp? License?

GnuPG is free software. PGP is not. Also there are other issues, but at this
particular point, gpg seems to implement a wider range of capabilities than
PGP, functionally speaking. PGP's interface seems to be more ameanable to
point-and-click people, though.

Hope this helps, and hope it's not too much detail.
--David.


--=_W_Lxz1fZ.5XiMkIG0nnxfhpcRy8C.P
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----

iQQXAwUAPe1f3oVy4iYQ9LKqFAId9RAAq8mnE6Z2SgVvjfFIfzH7FAvsxBL4PMcT
fxQWnOcZ9CFvGZgqiUAsR1X+OQCGArmpsf3TIgBElF84gJeYXIsy4BGXKoOGhxla
qA0sNia1dHqos0S511T0MQF68kul5tz8v70BPm4Ucv3fc02JlqEx2PSyWahkMUZJ
ZCaTCXvdXObEawv0p++XM+AH5ae1z3h1R4Q1iSIH1sscRNJTFRb+B0/lvarKcI1n
PHdnYf1VH6izwd/+YPlQ4aMC7Y0x4m7diINvFpP2Ble/a1H5uNeu58H7TlTsNq8m
yTiEj8KxsX378ylAz0czIKZVtH1oEb9/o2xtdt8h8kCwDZcx4UnnJiSw8CitZA57
Cjtg37modOoJwZnc8JSBchAyZYKWJGSvjSqb/E3fv6lmeQQql1Mi+Dxn0VkzSyWE
wlWQVwMtAM/WtAY3ci4Ibw/+epdFsJQzzXHbbldZdLLHpyUG4hLF9GmG+ZCJ8/6f
BKohDkErepFYd8gRDIQGm1EjFhG8ZtmAjlInX7bbQdDqA4G4drO/Iny3EKOOIbmp
/dIqWWChoO6KJmETzdUQ15dmBWyOaMXGDlnaVPi+q7uGX6uk0FYqvkMxN0t3aY5S
oBm5ZMuUqsbw205t0J1djWCfVnxFP5TQngpXY8dyW12MJjZrMdkVybAnlWHqrKZa
5d/NibyQT+gQAJyIJPS2z0vxb7D7Ny52hX8G27XIRA5xHGOlX08/f+4fJo68R+2w
L7LFUG08WYLKn46s8WSqEroYisU6R3qmAdPMEL0dq3b9ZD/z0Ecxsqx2xbbK8zHW
pKkJkkR+5lOsmgTBgrd8rXKxVOx8EDznS6MRTPYJVpXVm4so+rN/tMkLmf6QfFEm
A5e4WUdA3jWF4l2A5122fDopImRslpHj1nO3MwFdJhUTAh6qSDAof9XShubbY4Z6
tGGRGd8NgNm6miOg6B3U+Sf9eDjrrjCKZlt1eYVg0jqYAqpkoMGdnSUT6nccZ71s
SSCjh0oRW0JE6tlO15pU4sEv+4S5/78pFAJX3IJv9lgKtl0SBFKSfMlo86ZJPPVR
86ZrVukZbKuQU0Ub42GTTN7V45ucednF0JSo97ZGtkoEOMt5HlubelzsbjNshOJk
X7l3jj+FojYE3Epi/5K+AS6NuWX+dtRQBOMooGcfctpodAhPS3p+CFZ6xqvszlk/
1w8JXaOLzXx4AAmCWt3e4HuZnDItkb+nWjzUDlfMM2bGc9CYfYyxKpyCcYH4aiT+
GPtRfyXgtnZrLTLL9qNaF6VBIwrO1uasiBC0CKreAxSHUE4cXYNPujC8GHJAkle7
ZGCW9FLnb6Mjv6WQZpQmQW/bW3HZ8qWlpveM/QwmrQhqP5voSaaiRcFe
=jAec
-----END PGP SIGNATURE-----

--=_W_Lxz1fZ.5XiMkIG0nnxfhpcRy8C.P--