分类：
2008-10-13 14:40:23
Outline
GnuPG -- GNU Privacy Guard
* A quick intro to the high points of using GPG
GnuPG - General Info
* GnuPG is a complete and free replacement for PGP
* OpenPGP compliant - RFC2440
* Version 1.0.0 in September 1999, current stable at 1.2.1
* GPG written to avoid the the strict export restrictions of PGP, and to create a fully free version
Getting GPG
* Source available from
* Is packaged by distribution vendors
* Generally requires glibc, zlib, libgdbm
Setting Up GnuPG
* Once the package is installed, your user needs to have a public/private key pair
* gpg will create a subdirectory, ~/.gnupg in which to keep its files
* If you just run gpg, you will see:
[bob@yohost bob]$ gpg
gpg: /home/bob/.gnupg: directory created
gpg: /home/bob/.gnupg/options: new options file created
gpg: you have to start GnuPG again, so it can read the new options file
This is not your key pair, just the creation of your directory and options file
Generating Your Keys
* gpg --gen-key
* Key generation will ask you a number of questions
* Type of key:
Please select what kind of key you want:
(1) DSA and ElGamal (default)
(2) DSA (sign only)
(4) ElGamal (sign and encrypt)
Your selection?
* DSA is a public key algorithm used for creating digital signatures. It was created by NIST. Key size in DSA is 512 to 1024 bits. > 768 is adequate.
* ElGamal is a cryptosystem that consists of both signature and encryption variants.
* Press enter at this screen to accept the default, which is to utilize both DSA and ElGamal. If you choose to only create one or the other, the remaining keypair can be created later.
* See RSA's Crypto FAQ for more info
* Also see Bruce Schneier's Applied Cryptography
Generating Keys, cont'd
* Next, you will chose the size of your ElGamal keypair
* (DSA key is 1024 bits)
*
DSA keypair will have 1024 bits.
About to generate a new ELG-E keypair.
minimum keysize is 768 bits
default keysize is 1024 bits
highest suggested keysize is 2048 bits
What keysize do you want? (1024)
* The larger your keypair, the more resistant it is to brute-force attacks
* The larger the keypair, the longer it takes to encrypt and decrypt data
* The default of 1024 bits is plenty, so press enter
Generating Keys, cont'd
* Now choose an expiration date (to be used with all keypairs from the first selection)
* We're going to say that our personal keys never expire. If you can think of a reason for expiring your keys, well, good for you
*
Please specify how long the key should be valid.
0 = key does not expire
= key expires in n days
w = key expires in n weeks
m = key expires in n months
y = key expires in n years
Key is valid for? (0)
* You can change the expiration of the key later, but then you have to let everyone who has it know about the change
Generating Keys, cont'd
* Next you will create a user ID. This ID associates your key to you, so use your real name and most common (or reliable) email address
*
You need a User-ID to identify your key; the software constructs the user id
from Real Name, Comment and Email Address in this form:
"Heinrich Heine (Der Dichter) "
* Enter the appropriate information for Real Name, Comment, and Email
Real name: Bob Smith
Email address: bob@localhost
Comment: User Bob
You selected this USER-ID:
"Bob Smith (User Bob) "
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit?
* You cannot edit your user ID later. You can, however, add additional user IDs to your keypair
Generating Keys, cont'd
* Finally, you will be asked for your passphrase. It's a passphrase because spaces are allowed, so you can use full sentences
* Use the longest, most complex password you have a chance of remembering
* The passphrase is the weakest part of the cryptosystem, next to the password to your user account
* You know the general password rules. Make a respectable passphrase that you can remember
* If you forget your passphrase, data encrypted with this set of keys is lost. There is no way to retrieve your passphrase!
Generating Keys, cont'd
* gpg will now create your keypair
* Key generation requires entropy, which gpg pulls from activity on the machine
* If the key generation is taking a while, do some work, move your mouse around, generally generate interrupts on the system
* (generating entropy on remote and/or diskless machines may take some time -- /dev/random pulls bits from device drivers. see man 4 random)
Using Keys -- Your Keyring
* After installing gnupg, you have two keyrings: one for your publick keys, and one for your secret (private) keys
* By default, these are in ~/.gnupg/pubring.gpg and ~/.gnupg/secring.gpg
Using Keys -- Export A Public Key
* When you want someone to send you encrypted messages, they need to use your public key
* To get your key out of your keyring for exporting, use the --export option to gpg
* By default, --export will dump your public key to STDOUT in binary format
* To get the key in a usable format, use -a for ASCII text. This is the public key format you are probably familiar with
* For our friend bob, the output looks like
[bob@yohost bob]$ gpg --export -a
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see
mQGiBD3+TlYRBAC6O6PixTdUYJkpINs+0GkG5LUJoMQ2EUwHZUCGSdrFPejhopj6
WTHgcl2w0IJwfIz+N8pjoQzdYuJ8/Qns87GdkBiAZuB2u5WaoHACJkfF1rwTOs1X
uyg6cKXtju66pFEi4lNRcXNCQVdsuKWTxZDqohafgfVhGQ2BYlk9oah/TwCg1xED
eKeicQQCjId3YGdsFlY7Q2kD/2bgKLUeeLviZdrkdH5kT1qCzxzMiI0ZDWacuV57
nBSUzECk+A4x4JQOfRJRtEMraOxkQzhOcmoB+TgMmFn3iJ/hYo+qediFnaVOMgRk
VzcZ4dKRK7gYncXg8py3ASbfokJhCMCDCdmnMjSv9UYGX3++KZIkousez92PcWHO
9zi7A/9QG/GUuPZRsqvq23jIitsXQSNUPrBSZ+bHHp1E5Mc0Aqd/7jgE+mF+QVq5
aNWFA+ss2zZrsGrDz+mskiutVtgDBJ5y6NkPmecopmduoZUPMTwLnGMmIWT5UIsS
hLs9+XMRlbG/cpovrrB27m7v0kLBKVs3D0dn8jbI0tDjn+ySu7QkQm9iIFNtaXRo
IChVc2VyIEJvYikgPGJvYkBsb2NhbGhvc3Q+iFcEExECABcFAj3+TlYFCwcKAwQD
FQMCAxYCAQIXgAAKCRBY4XYhMkCh+JhiAJ4rbXfrmsOtdHzsu6KQvE5QZZjx8ACg
oknRXwARHnW6TiZbsXubB2GkbhC5AQ0EPf5OWRAEANlJFk1+p4RbF9KY0l3eDFXK
OOr4VGq/ZDMooANHzczYT6HMawHd9oELnyvQ8jVE1ZslD2TTLXa/I42TihQkmAyQ
LGWj4QrJiEm0mrYvMnz8TGp5rktBbudBFO8fGKLUWcZ1Mrz06P1A7HqAJU5VWDcl
N3fgBUj/9r90PSHXrW37AAMGA/wMhE9Ox1lEGrBef9WEkzbL8icnfMpYM2v/WRMz
Qda7lA/NMrmXcYkRRuyitpzYItP5+UbC9mxsdBXpZFxanQkD8rpPZSDWd37zvwh7
uicsYlhoG7bGPcbM7noOwEWSNraWeERQuaL4QwZ8sfKoy/TnbHrOw01dWfwDZM8v
G83hoohGBBgRAgAGBQI9/k5ZAAoJEFjhdiEyQKH4L40AoKyWs1gGhFv4vGUS8jiv
qIrJfjZaAKCMrq4Ug5BV0vVj0yRlQIgpYysOfw==
=vNY2
-----END PGP PUBLIC KEY BLOCK-----
* If you have other people's keys in your keyring, you should add your id to the command:
[bob@yohost bob]$ gpg --export -a Bob
produces the same output as above when bob has multiple keys in his keyring
Using Keys -- Import a Public Key
* In order to send encrypted messages to someone else, you need their key
* You will usually find public keys on the Internet, at keyservers or on personal or corporate websites, in ASCII format
* Let's say bob wants to import Red Hat's security public key from a keyserver. This is the key that Red Hat signs rpm packages with
* Red Hat's public key information is on their website, which includes an ASCII dump of their key
* bob is going to import Red Hat's key from the keyserver, however, which is pgp.mit.edu. He finds the key listed with a Key ID of DB42A60E
* Using the --recv-keys option, bob gets the key directly from the server:
[bob@yohost bob]$ gpg --recv-keys --keyserver pgp.mit.edu DB42A60E
gpg: requesting key DB42A60E from pgp.mit.edu ...
gpg: key DB42A60E: public key imported
gpg: /home/bob/.gnupg/trustdb.gpg: trustdb created
gpg: Total number processed: 1
gpg: imported: 1
* bob now has the security@redhat.com key:
[bob@yohost bob]$ gpg --list-keys
/home/bob/.gnupg/pubring.gpg
----------------------------
pub 1024D/3240A1F8 2002-12-16 Bob Smith (User Bob)
sub 1024g/C16A012B 2002-12-16
pub 1024D/DB42A60E 1999-09-23 Red Hat, Inc
sub 2048g/961630A2 1999-09-23
* Now bob is going to import my key, by downloading the file from my website.
* bob pulls my key down from my website:
[bob@yohost bob]$ lwp-download
1.33 KB received
* Now bob has my public key in the file "pubkey.txt". He imports my key into his keyring:
[bob@yohost bob]$ gpg --import pubkey.txt
gpg: key 7776E936: public key imported
gpg: Total number processed: 1
gpg: imported: 1
* Now bob has my key, and he can encrypt things meant for me
[bob@yohost bob]$ gpg --list-keys
/home/bob/.gnupg/pubring.gpg
----------------------------
pub 1024D/3240A1F8 2002-12-16 Bob Smith (User Bob)
sub 1024g/C16A012B 2002-12-16
pub 1024D/DB42A60E 1999-09-23 Red Hat, Inc
sub 2048g/961630A2 1999-09-23
pub 1024D/7776E936 2002-10-04 Mandi Walls
sub 1024g/E0524E3E 2002-10-04
Using Keys -- Encrypting Data
* Now bob is going to send me an encrypted file, hello.txt
[bob@yohost bob]$ cat hello.txt
hello!
how is the weather?
it is freaking cold here.
* bob uses the --encrypt option to encrypt the file:
[bob@yohost bob]$ gpg --encrypt hello.txt
You did not specify a user ID. (you may use "-r")
Enter the user ID: mandi@linuxchick.org
Could not find a valid trust path to the key. Let's see whether we
can assign some missing owner trust values.
No path leading to one of our keys found.
1024g/E0524E3E 2002-10-04 "Mandi Walls "
Fingerprint: C1A2 F26B 5714 4DC8 CD2A 1DAC F25E D76D E052 4E3E
It is NOT certain that the key belongs to its owner.
If you *really* know what you are doing, you may answer
the next question with yes
Use this key anyway? yes
* bob now has a file in his directory, called hello.txt.gpg which he can send to me and i can decrypt
* This file is not stored in ASCII format by default; it is binary. To encrypt into ASCII, use gpg --encrypt -a hello.txt, which will create a file called hello.txt.asc
Using Keys -- Decrypting Data
* I received bob's message, and have sent him a reply in the file brrr.txt.asc. This is another ASCII format file
* bob uses the --decrypt option to decrypt the message
[bob@yohost bob]$ gpg --decrypt brrr.txt.asc
You need a passphrase to unlock the secret key for
user: "Bob Smith (User Bob) "
1024-bit ELG-E key, ID 8938F5F5, created 2003-01-29 (main key ID A9187B27)
gpg: encrypted with 1024-bit ELG-E key, ID 8938F5F5, created 2003-01-29
"Bob Smith (User Bob) "
It is very cold here. That groundhog better have good news tomorrow.
(yes, bob's keys changed. i forgot his passphrase...)
Using Keys -- Deleting Keys
* So, bob forgot his passphrase. There is no way to get his keys back without it
* Bob has to delete his secret and public keys, and then generate new keys. Then he has to make sure that everyone who has his public key knows about the change
* First, he deletes his secret key:
[bob@yohost bob]$ gpg --delete-secret-key bob
gpg (GnuPG) 1.0.6; Copyright (C) 2001 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.
sec 1024D/3240A1F8 2002-12-16 Bob Smith (User Bob)
Delete this key from the keyring? y
This is a secret key! - really delete? y
* Then, he deletes his public key:
[bob@yohost bob]$ gpg --delete-key bob
gpg (GnuPG) 1.0.6; Copyright (C) 2001 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.
pub 1024D/3240A1F8 2002-12-16 Bob Smith (User Bob)
Delete this key from the keyring? y
* Then, he starts over, and creates a new key. Now his key ring looks like:
[bob@yohost bob]$ gpg --list-keys
/home/bob/.gnupg/pubring.gpg
----------------------------
pub 1024D/DB42A60E 1999-09-23 Red Hat, Inc
sub 2048g/961630A2 1999-09-23
pub 1024D/7776E936 2002-10-04 Mandi Walls
sub 1024g/E0524E3E 2002-10-04
pub 1024D/A9187B27 2003-01-29 Bob Smith (User Bob)
sub 1024g/8938F5F5 2003-01-29
* He hasn't lost the other keys on his keyring, just his old personal key set
Using Keys -- Revoking Keys
* Because bob is a bit scatterbrained, he decides to create a revocation certificate for his new keys. This will allow him to revoke his old keys, and let people know about it through a keyserver
* Bob uses --gen-revoke to create the certificate:
[bob@yohost bob]$ gpg --gen-revoke bob
sec 1024D/A9187B27 2003-01-29 Bob Smith (User Bob)
Create a revocation certificate for this key? yes
Please select the reason for the revocation:
1 = Key has been compromised
2 = Key is superseded
3 = Key is no longer used
0 = Cancel
(Probably you want to select 1 here)
Your decision?
Invalid selection.
Your decision? 3
Enter an optional description; end it with an empty line:
>
Reason for revocation: Key is no longer used
(No description given)
Is this okay? yes
You need a passphrase to unlock the secret key for
user: "Bob Smith (User Bob) "
1024-bit DSA key, ID A9187B27, created 2003-01-29
ASCII armored output forced.
Revocation certificate created.
Please move it to a medium which you can hide away; if Mallory gets
access to this certificate he can use it to make your key unusable.
It is smart to print this certificate and store it away, just in case
your media become unreadable. But have some caution: The print system of
your machine might store the data and make it available to others!
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see [/url]
Comment: A revocation certificate should follow
iEkEIBECAAkFAj44QwsCHQMACgkQ8iO+oKkYeyc57gCfaAAoa4WE8iT07euoYqBH
eL9eRB4An1AsL3mWC4UI926xVKlJpJ1QqkFm
=lCql
-----END PGP PUBLIC KEY BLOCK-----
* Bob now has a revocation certificate, which he can store in a safe place in case he loses his keys
* To actually use the certificate, bob has to import it into his keyring:
[bob@yohost bob]$ gpg --import
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see [/url]
Comment: A revocation certificate should follow
iEkEIBECAAkFAj44QwsCHQMACgkQ8iO+oKkYeyc57gCfaAAoa4WE8iT07euoYqBH
eL9eRB4An1AsL3mWC4UI926xVKlJpJ1QqkFm
=lCql
-----END PGP PUBLIC KEY BLOCK-----
gpg: key A9187B27: revocation certificate imported
gpg: Total number processed: 1
gpg: new key revocations: 1
* bob can no longer use that key:
[bob@yohost bob]$ gpg --encrypt hello.txt
You did not specify a user ID. (you may use "-r")
Enter the user ID: bob
No such user ID.
Enter the user ID: bob@localhost
No such user ID.
* Now bob creates new keys for himself, and lets everyone know that his old keys are revoked.
Using Keys -- Checking Signatures
* Software vendors use gpg to sign files as a mechanism more robust than MD5 sums to prove the authenticity of the files
* Creating a signature for the file doesn't encrypt the file; it's still in its normal format, whether it is a tarfile, package, or whatever
* You should also use gpg to check the signatures for files you download
* Bob decides he wants to install the program "wipe", which he downloads from [/url]
* Bob downloads the file wipe-2.1.0.tar.bz2.sig, which contains the signature for the file:
[bob@yohost bob]$ cat wipe-2.1.0.tar.bz2.sig
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see [/url]
iEYEABECAAYFAj1bJKAACgkQDrxthObLl9oQJwCgoyaEN6GZHSa2r6MSz45QJklY
N+IAoIiu+nhilDEd7KFeMm8uE0RDJBnb
=AVzd
-----END PGP SIGNATURE-----
* bob uses --verify to verify the file:
[bob@yohost bob]$ gpg --verify wipe-2.1.0.tar.bz2.sig wipe-2.1.0.tar.bz2
gpg: Signature made Wed 14 Aug 2002 11:48:48 PM EDT using DSA key ID E6CB97DA
gpg: Can't check signature: public key not found
* gpg tells bob that he needs to get the public key, and it tells him the ID that generated the signature, so he can get it from the keyserver:
[bob@yohost bob]$ gpg --recv-keys --keyserver pgp.mit.edu E6CB97DA
gpg: requesting key E6CB97DA from pgp.mit.edu ...
gpg: key E6CB97DA: public key imported
gpg: Total number processed: 1
gpg: imported: 1
* Now bob has a new key, and can verify the wipe tarfile:
[bob@yohost bob]$ gpg --list-keys
/home/bob/.gnupg/pubring.gpg
----------------------------
pub 1024D/DB42A60E 1999-09-23 Red Hat, Inc
sub 2048g/961630A2 1999-09-23
pub 1024D/7776E936 2002-10-04 Mandi Walls
sub 1024g/E0524E3E 2002-10-04
pub 1024D/A9187B27 2003-01-29 Bob Smith (User Bob)
sub 1024g/8938F5F5 2003-01-29
pub 1024D/9004BC23 2003-01-29 Bob Smith (User Bob)
sub 1024g/B5577FFB 2003-01-29
pub 1024D/E6CB97DA 2002-02-26 Tom Vier
uid Tom Vier
sub 2048g/7A93AEDA 2002-02-26 [expires: 2004-02-26]
[bob@yohost bob]$ gpg --verify wipe-2.1.0.tar.bz2.sig wipe-2.1.0.tar.bz2
gpg: Signature made Wed 14 Aug 2002 11:48:48 PM EDT using DSA key ID E6CB97DA
gpg: Good signature from "Tom Vier "
gpg: aka "Tom Vier "
Could not find a valid trust path to the key. Let's see whether we
can assign some missing owner trust values.
No path leading to one of our keys found.
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
gpg: Fingerprint: DD7A 5403 4596 7F5D F2A4 7B6A 0EBC 6D84 E6CB 97DA
* Bob could also use the gpgv command, which is a simplified version of gpg --verify but works the same way
* bob knows that the signature is a good signature. But what's all this trust business?
Using Keys -- Signing Files
* Bob is going to tar up his home directory and ftp it to another place. He wants to make sure the file gets there ok. Instead of using MD5sum, Bob is going to use his new friend, gpg
* Bob is going to use an ASCII signature to sign his file. He is also going to make his signature a separate file using gpg -b -a:
[bob@yohost bob]$ gpg -b -a bob.tar.bz2
You need a passphrase to unlock the secret key for
user: "Bob Smith (User Bob) "
1024-bit DSA key, ID 9004BC23, created 2003-01-29
[bob@yohost bob]$ ls
bob.tar.bz2 hello.txt pubkey.txt wipe-2.1.0.tar.bz2
bob.tar.bz2.asc hello.txt.asc scripts.tar wipe-2.1.0.tar.bz2.sig
brrr.txt.asc hello.txt.gpg tmp/
* Bob now has a separate file with the signature in it for the bob.tar.bz2 file:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see [/url]
iD8DBQA+OYHF21hmipAEvCMRAjGSAKDPU3ibnas0WYE3yRMSRzkHrXzIqACfT/bF
cUDHaiyAskl8eY1aPAKZ4mo=
=JVfm
-----END PGP SIGNATURE-----
* This signature will verify the authenticity of his file:
[bob@yohost bob]$ gpg --verify bob.tar.bz2.asc bob.tar.bz2
gpg: Signature made Thu 30 Jan 2003 02:49:25 PM EST using DSA key ID 9004BC23
gpg: Good signature from "Bob Smith (User Bob) "
* Now, why didn't that have a message about trust?
Using gpg -- Signing Keys
* Key signing spreads the "web of trust" for public keys
* You sign a key when you believe that the key is authentic and belongs to the person claiming to be the owner
* Bob knows my key belongs to me, so he is going to sign my key by using the --edit-key option:
[bob@yohost bob]$ gpg --edit-key mandi
gpg (GnuPG) 1.0.6; Copyright (C) 2001 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.
pub 1024D/7776E936 created: 2002-10-04 expires: never trust: -/q
sub 1024g/E0524E3E created: 2002-10-04 expires: never
(1). Mandi Walls
Command> sign
pub 1024D/7776E936 created: 2002-10-04 expires: never trust: -/q
Fingerprint: 62B9 6999 9988 B437 6E78 BD66 CD1D CAAA 7776 E936
Mandi Walls
Are you really sure that you want to sign this key
with your key: "Bob Smith (User Bob) "
Really sign? yes
You need a passphrase to unlock the secret key for
user: "Bob Smith (User Bob) "
1024-bit DSA key, ID 9004BC23, created 2003-01-29
Command> save
* Bob can see what signatures have been applied to a key using the --list-sigs option. From the output from that command, bob can see tht he has successfully added his signature to my key:
pub 1024D/7776E936 2002-10-04 Mandi Walls
sig 7776E936 2002-10-04 Mandi Walls
sig A9187B27 2003-01-29 [User id not found]
sig 9004BC23 2003-01-30 Bob Smith (User Bob)
sub 1024g/E0524E3E 2002-10-04
sig 7776E936 2002-10-04 Mandi Walls
* Now that Bob has signed my key, he could upload it to the keyserver (if it was on one) and anyone else who uses my key will know that bob trusts me. They can make a personal judgement for themselves how much to trust me and how much they trust bob to carefully sign keys
* gpg has a mechanism to assign trust values to certain keys. To see how much he trusts the keys he has, bob runs gpg --list-keys --with-colons:
[bob@yohost bob]$ gpg --list-keys --with-colons
/home/bob/.gnupg/pubring.gpg
----------------------------
pub:q:1024:17:219180CDDB42A60E:1999-09-23::64:-:Red Hat, Inc ::scESC:
sub:q:2048:16:C9CC699F961630A2:1999-09-23::64::::e:
pub:f:1024:17:CD1DCAAA7776E936:2002-10-04::174:-:Mandi Walls ::scESC:
sub:f:1024:16:F25ED76DE0524E3E:2002-10-04::174::::e:
pub:u:1024:17:DB58668A9004BC23:2003-01-29::184:-:Bob Smith (User Bob) ::scESC:
sub:u:1024:16:3A07B74EB5577FFB:2003-01-29::184::::e:
pub:q:1024:17:0EBC6D84E6CB97DA:2002-02-26:2004-02-26:190:-:Tom Vier ::scESC:
uid:q::::::::Tom Vier :
sub:q:2048:16:AFB04D017A93AEDA:2002-02-26:2004-02-26:190::::e:
* The second field of output is the level of trust bob has for the particular key
* The trust for Red Hat's key is "q", or unknown
* The trust for my key, is "f", or fully trusted. Bob signed my key with his signature, so he trusts my key
* The trust for bob's own key is "u", or ultimately trusted. This can only be the case when bob has the secret key for the key pair
* Trust of a key is calculated by gpg using an algorithm based on the number of signatures on the key
* For a key to be considered valid, the key must either have been signed by bob, been signed by one key fully trusted by bob, or have been signed by 3 keys marginally trusted by bob. Also, the path from bob's key to that key has to be 5 steps or less
* Bob noticed from the copious output of the --list-sigs command that Red Hat's key has been signed by several dozen other keys. He checks it out at pgp.mit.edu and sees the names of all the people who have signed Red Hat's key
* Bob thinks maybe he could increase the trust on Red Hat's key in his own keyring using the --edit-key option, even though his key doesn't link back to Red Hat's key:
[bob@yohost bob]$ gpg --edit-key redhat
gpg (GnuPG) 1.0.6; Copyright (C) 2001 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.
pub 1024D/DB42A60E created: 1999-09-23 expires: never trust: -/q
sub 2048g/961630A2 created: 1999-09-23 expires: never
(1). Red Hat, Inc
Command> trust
pub 1024D/DB42A60E created: 1999-09-23 expires: never trust: -/q
sub 2048g/961630A2 created: 1999-09-23 expires: never
(1). Red Hat, Inc
Please decide how far you trust this user to correctly
verify other users' keys (by looking at passports,
checking fingerprints from different sources...)?
1 = Don't know
2 = I do NOT trust
3 = I trust marginally
4 = I trust fully
s = please show me more information
m = back to the main menu
Your decision? 3
pub 1024D/DB42A60E created: 1999-09-23 expires: never trust: m/q
sub 2048g/961630A2 created: 1999-09-23 expires: never
(1). Red Hat, Inc
Command> save
* Bob plays it conservative and trusts Red Hat's key marginally. After all, he doesn't know any of the people who have signed Red Hat's key, even if there are a lot of them. Though, he did notice that Red Hat's key was signed by Peter Jones, whose key was signed by Hunter Matthews, whose key was signed by Theodore Ts'o, Kerberos team lead at MIT and kernel hacker. Damn that's cool. Bob is such a lamer, no one has signed his key
Using Keys -- A Keysigning! A Keysigning!
* A keysigning party is a way to bring a lot of people together to sign each other's keys
* Sign keys first, then party... ;)
* Bob gets the fingerprint for his key to send to the party coordinator:
[bob@yohost bob]$ gpg --fingerprint bob
pub 1024D/9004BC23 2003-01-29 Bob Smith (User Bob)
Key fingerprint = FC62 5CF4 8A83 4B10 54BA 8D40 DB58 668A 9004 BC23
sub 1024g/B5577FFB 2003-01-29
* While at the party, bob will get a list of fingerprints for other people's keys, and verify the identity of those people using driver's licenses, passports, or other trustworthy photo identification
* When bob gets home, he can download all the keys, verify the fingerprints, and sign the keys. Then he sends them back up to the keyserver. Voila! bob has signed keys and has had other people sign his key!
* Now bob is going to sleep off his hangover. What a party!
GPG and Email
* When working with email, there are two ways to add gpg into the mix: clearsigning messages and encrypting messages
* A clearsigned message is useful when you want to guarantee that people know who the message was sent by, but don't want/need to encrypt the data
* The signature is based on your key and the content of your message
* Your email reader will render the clearsigned message in such a way that you know the message was signed. Under pine, it looks like:
Date: Fri, 31 Jan 2003 11:22:12 -0500 (EST)
From: Mandi
To:
Subject: testing clearsign
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
testing clearsign
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see [/url]
iD8DBQE+OqK0zR3Kqnd26TYRAqA5AKCouIBErvDQd0mksC2rdyDJzy2TxgCg3XGZ
Jsx4Tab7nz/9c9kglM23CfE=
=ay+d
-----END PGP SIGNATURE-----
Or it could be an attachment, with a message appearing at the bottom of the message:
Some Dude - [email]somed@domain.org[/email] - [email]sdude@other.net[/email] - ~sdude[/url]
Private personal mail: use PGP key 12345678; more sensitive data? Use 09876543
[ Part 2, Application/PGP-SIGNATURE 240bytes. ]
[ Cannot display this part. Press "V" then "S" to save in a file. ]
* When a message is to be encrypted, you'll need to use the email address associated with that key. People may add email addresses to their main key or generate new keys for each of their addresses
* When you choose to send an encrypted message, your email client will search your gpg keyring for the correct key for the receiver's email address.
More Information on Specific Email Clients
* emacs:
o [/url] is a lisp package for incorporating PGP/GPG into emacs
* mutt:
o [/url]
o by default, mutt has PGP (and, therefore, GPG) support compiled in, and gpg directives can be added to your .muttrc file
o see section "XIV. Configuring Mutt For Use With GnuPG" of the above for more info
* pine:
o There are a few different packages that aid pine users with encryption
o Pine comes with pinegpg filters for encrypting and decrypting, signing and verifying
o Pine Privacy Guard [/url] is a perl script that works as input and output filters to pine and is useful on older versions of pine
* mozilla and netscape:
o EnigMail http://enigmail.mozdev.org/[/url] is a plugin that works with Mozilla 1.0.x and Netscape 7
o It works with commandline gpg or pgp programs
* Evolution:
o Evolution supports gpg as well. The Evolution user's guide at [/url] has more information.
o When encrypting or signing a message with Evolution, choose PGP Encrypt or PGP Sign from the Security menu
* Kmail:
o For Kmail PGP/GPG settings, go to Settings->Configure Kmail->Security->PGP
o Add your PGP user identity to the Identity page of Configure
o You can click the "Help" button for the KDE and KMail help files
Other GPG Resources
* GPG Mini-HOWTO, [/url]
* gnupg homepage, [/url] Check the FAQ.