1998-10-06 12:10:02 +00:00
|
|
|
GNU Privacy Guard -- Frequently Asked Questions
|
|
|
|
=================================================
|
|
|
|
|
|
|
|
This FAQ is partly compiled from messages of the developers mailing list.
|
|
|
|
|
|
|
|
Many thanks to Kirk Fort, Brian Warner, ...
|
|
|
|
|
|
|
|
|
|
|
|
Q: How does this whole thing work?
|
|
|
|
A: To generate a secret/public keypair, run
|
|
|
|
|
|
|
|
gpg --gen-key
|
|
|
|
|
|
|
|
and choose the default values.
|
|
|
|
|
|
|
|
Data that is encrypted with a public key can only be decrypted by the
|
|
|
|
matching secret key. The secret key is protected by a password, the
|
|
|
|
public key is not.
|
|
|
|
|
|
|
|
So to send your friend a message, you would encrypt your message with his
|
|
|
|
public key, and he would only be able to decrypt it by having the secret
|
|
|
|
key and putting in the password to use his secret key.
|
|
|
|
|
1999-05-20 12:11:41 +00:00
|
|
|
GnuPG is also useful for signing things. Things that are encrypted with
|
1998-10-06 12:10:02 +00:00
|
|
|
the secret key can be decrypted with the public key. To sign something, a
|
1999-02-10 16:22:40 +00:00
|
|
|
hash is taken of the data, and then the hash is in some form encoded with
|
|
|
|
the secret key. If someone has your public key, they can verify that it
|
|
|
|
is from you and that it hasn't changed by checking the encoded form of
|
|
|
|
the hash with the public key.
|
1998-10-06 12:10:02 +00:00
|
|
|
|
|
|
|
A keyring is just a large file that stores keys. You have a public keyring
|
|
|
|
where you store yours and your friend's public keys. You have a secret
|
|
|
|
keyring that you keep your secret key on, and be very careful with this
|
|
|
|
secret keyring: Never ever give anyone else access to it and use a *good*
|
|
|
|
passphrase to protect the data in it.
|
|
|
|
|
|
|
|
You can 'conventionally' encrypt something by using the option 'gpg -c'.
|
|
|
|
It is encrypted using a passphrase, and does not use public and secret
|
|
|
|
keys. If the person you send the data to knows that passphrase, they can
|
1999-01-12 10:20:24 +00:00
|
|
|
decrypt it. This is usually most useful for encrypting things to
|
1998-10-06 12:10:02 +00:00
|
|
|
yourself, although you can encrypt things to your own public key in the
|
|
|
|
same way. It should be used for communication with partners you know and
|
|
|
|
where it is easy to exchange the passphrases (e.g. with your boy friend or
|
1999-01-12 10:20:24 +00:00
|
|
|
your wife). The advantage is that you can change the passphrase from time
|
|
|
|
to time and decrease the risk, that many old messages may be decrypted by
|
1998-10-06 12:10:02 +00:00
|
|
|
people who accidently got your passphrase.
|
|
|
|
|
|
|
|
You can add and copy keys to and from your keyring with the 'gpg --import'
|
|
|
|
and 'gpg --export' option. 'gpg --export-secret-keys' will export secret
|
1999-01-12 10:20:24 +00:00
|
|
|
keys. This is normally not useful, but you can generate the key on one
|
1998-10-06 12:10:02 +00:00
|
|
|
machine then move it to another machine.
|
|
|
|
|
|
|
|
Keys can be signed under the 'gpg --edit-key' option. When you sign a
|
|
|
|
key, you are saying that you are certain that the key belongs to the
|
|
|
|
person it says it comes from. You should be very sure that is really
|
1999-01-12 10:20:24 +00:00
|
|
|
that person: You should verify the key fingerprint
|
1998-10-06 12:10:02 +00:00
|
|
|
|
|
|
|
gpg --fingerprint user-id
|
|
|
|
|
|
|
|
over phone (if you really know the voice of the other person) or at
|
|
|
|
a key signing party (which are often held at computer conferences)
|
|
|
|
or at a meeting of your local GNU/Linux User Group.
|
|
|
|
|
|
|
|
Hmm, what else. You may use the option "-o filename" to force output
|
1999-02-10 16:22:40 +00:00
|
|
|
to this filename (use "-" to force output to stdout). "-r" just lets you
|
|
|
|
specify the recipient (which public key you encrypt with) on the command
|
|
|
|
line instead of typing it interactively.
|
1998-10-06 12:10:02 +00:00
|
|
|
|
|
|
|
Oh yeah, this is important. By default all data is encrypted in some weird
|
1999-02-10 16:22:40 +00:00
|
|
|
binary format. If you want to have things appear in ASCII text that is
|
1999-01-12 10:20:24 +00:00
|
|
|
readable, just add the '-a' option. But the preferred method is to use
|
1998-10-06 12:10:02 +00:00
|
|
|
a MIME aware mail reader (Mutt, Pine and many more).
|
|
|
|
|
1999-05-20 12:11:41 +00:00
|
|
|
There is a small security glitch in the OpenPGP (and therefore GnuPG) system;
|
1998-10-06 12:10:02 +00:00
|
|
|
to avoid this you should always sign and encrypt a message instead of only
|
|
|
|
encrypting it.
|
|
|
|
|
|
|
|
|
|
|
|
Q: What is the recommended key size?
|
|
|
|
A: 1024 bit for DSA signatures; even for plain ElGamal
|
|
|
|
signatures this is sufficient as the size of the hash
|
1999-01-12 10:20:24 +00:00
|
|
|
is probably the weakest link if the keysize is larger
|
1998-10-06 12:10:02 +00:00
|
|
|
than 1024 bits. Encryption keys may have greater sizes,
|
1999-05-04 13:55:41 +00:00
|
|
|
but you should than check the fingerprint of this key:
|
|
|
|
"gpg --fingerprint --fingerprint <user ID>".
|
1998-10-06 12:10:02 +00:00
|
|
|
|
|
|
|
Q: Why are some signatures with an ELG-E key valid?
|
1999-05-20 12:11:41 +00:00
|
|
|
A: These are ElGamal Key generated by GnuPG in v3 (rfc1991)
|
1998-10-06 12:10:02 +00:00
|
|
|
packets. The OpenPGP draft later changed the algorithm
|
|
|
|
identifier for ElGamal keys which are usable for signatures
|
1999-05-20 12:11:41 +00:00
|
|
|
and encryption from 16 to 20. GnuPG now uses 20 when it
|
1998-10-06 12:10:02 +00:00
|
|
|
generates new ElGamal keys but still accept 16 (which is
|
|
|
|
according to OpenPGP "encryption only") if this key is in
|
1999-05-20 12:11:41 +00:00
|
|
|
a v3 packet. GnuPG is the only program which had used
|
1998-10-06 12:10:02 +00:00
|
|
|
these v3 ElGamal keys - so this assumption is quite safe.
|
|
|
|
|
1999-04-06 18:04:55 +00:00
|
|
|
Q: Why is PGP 5.x not able to encrypt messages with some keys?
|
1998-10-06 12:10:02 +00:00
|
|
|
A: PGP Inc refuses to accept ElGamal keys of type 20 even for
|
1999-04-06 18:04:55 +00:00
|
|
|
encryption. They only support type 16 (which is identical
|
|
|
|
at least for decryption). To be more inter-operable, GnuPG
|
1998-10-06 12:10:02 +00:00
|
|
|
(starting with version 0.3.3) now also uses type 16 for the
|
|
|
|
ElGamal subkey which is created if the default key algorithm
|
1999-02-19 14:54:00 +00:00
|
|
|
is chosen. You may add an type 16 ElGamal key to your public
|
1998-10-06 12:10:02 +00:00
|
|
|
key which is easy as your key signatures are still valid.
|
|
|
|
|
1999-02-10 16:22:40 +00:00
|
|
|
Q: Why is PGP 5.x not able to verify my messages?
|
1998-10-18 15:21:22 +00:00
|
|
|
A: PGP 5.x does not accept V4 signatures for data material but
|
1999-04-06 18:04:55 +00:00
|
|
|
OpenPGP requires generation of V4 signatures for all kind of
|
1998-10-18 15:21:22 +00:00
|
|
|
data. Use the option "--force-v3-sigs" to generate V3 signatures
|
|
|
|
for data.
|
|
|
|
|
1999-01-12 10:20:24 +00:00
|
|
|
Q: I can't delete an user id because it is already deleted on my
|
1999-02-10 16:22:40 +00:00
|
|
|
public keyring?
|
1998-10-06 12:10:02 +00:00
|
|
|
A: Because you can only select from the public key ring, there is
|
1999-02-10 16:22:40 +00:00
|
|
|
no direct way to do this. However it is not very complicated
|
|
|
|
to do it anyway. Create a new user id with exactly the same name
|
|
|
|
and you will see that there are now two identical user ids on the
|
|
|
|
secret ring. Now select this user id and delete it. Both user
|
|
|
|
ids will be removed from the secret ring.
|
1998-10-06 12:10:02 +00:00
|
|
|
|
1999-02-10 16:22:40 +00:00
|
|
|
Q: How can I encrypt a message so that pgp 2.x is able to decrypt it?
|
1998-10-06 12:10:02 +00:00
|
|
|
A: You can't do that because pgp 2.x normally uses IDEA which is not
|
1999-05-20 12:11:41 +00:00
|
|
|
supported by GnuPG because it is patented, but if you have a modified
|
1998-10-06 12:10:02 +00:00
|
|
|
version of PGP you can try this:
|
|
|
|
|
|
|
|
gpg --rfc1991 --cipher-algo 3des ...
|
|
|
|
|
1999-05-20 12:11:41 +00:00
|
|
|
Please don't pipe the data to encrypt to gpg but give it as a filename;
|
|
|
|
other wise, pgp 2 will not be able to handle it.
|
|
|
|
|
1998-10-06 12:10:02 +00:00
|
|
|
Q: How can I conventional encrypt a message, so that PGP can decrypt it?
|
|
|
|
A: You can't do this for PGP 2. For PGP 5 you should use this:
|
|
|
|
|
1999-04-06 18:04:55 +00:00
|
|
|
gpg -c --cipher-algo 3des --compress-algo 1 myfile
|
1998-10-06 12:10:02 +00:00
|
|
|
|
1999-02-10 16:22:40 +00:00
|
|
|
You may replace "3des" by "cast5". "blowfish" does not work with
|
1998-10-06 12:10:02 +00:00
|
|
|
all versions of pgp5. You may also want to put
|
|
|
|
compress-algo 1
|
1999-02-10 16:22:40 +00:00
|
|
|
into your ~/.gnupg/options file - this does not affect normal
|
1998-10-06 12:10:02 +00:00
|
|
|
gnupg operation.
|
|
|
|
|
|
|
|
|
|
|
|
Q: Why does it sometimes take so long to create keys?
|
|
|
|
A: The problem here is that we need a lot of random bytes and for that
|
|
|
|
we (on Linux the /dev/random device) must collect some random data.
|
|
|
|
It is really not easy to fill the Linux internal entropy buffer; I
|
1999-02-10 16:22:40 +00:00
|
|
|
talked to Ted Ts'o and he commented that the best way to fill the buffer
|
|
|
|
is to play with your keyboard. Good security has it's price. What I do
|
|
|
|
is to hit several times on the shift, control, alternate, and capslock
|
|
|
|
keys, because these keys do not produce output to the screen. This way
|
|
|
|
you get your keys really fast (it's the same thing pgp2 does).
|
1998-10-06 12:10:02 +00:00
|
|
|
|
|
|
|
Another problem might be another program which eats up your random bytes
|
|
|
|
(a program (look at your daemons) that reads from /dev/[u]random).
|
|
|
|
|
|
|
|
Q: And it really takes long when I work on a remote system. Why?
|
1999-04-06 18:04:55 +00:00
|
|
|
A: Don't do this at all! You should never create keys or even use GnuPG
|
1999-02-10 16:22:40 +00:00
|
|
|
on a remote system because you normally have no physical control over
|
|
|
|
your secret keyring (which is in most cases vulnerable to advanced
|
|
|
|
dictionary attacks) - I strongly encourage everyone to only create keys
|
|
|
|
on a local computer (a disconnected laptop is probably the best choice)
|
|
|
|
and if you need it on your connected box (I know: We all do this) be
|
|
|
|
sure to have a strong password for your account and for your secret key
|
|
|
|
and trust your Root.
|
1998-10-06 12:10:02 +00:00
|
|
|
|
1999-04-06 18:04:55 +00:00
|
|
|
When I check GnuPG on a remote system via ssh (I have no Alpha here ;-)
|
1999-02-10 16:22:40 +00:00
|
|
|
I have the same problem. It takes a *very* long time to create the
|
|
|
|
keys, so I use a special option, --quick-random, to generate insecure
|
|
|
|
keys which are only good for some tests.
|
1998-10-06 12:10:02 +00:00
|
|
|
|
|
|
|
|
|
|
|
Q: How does the whole trust thing work?
|
1999-02-10 16:22:40 +00:00
|
|
|
A: It works more or less like PGP. The difference is that the trust is
|
|
|
|
computed at the time it is needed. This is one of the reasons for the
|
1998-10-06 12:10:02 +00:00
|
|
|
trustdb which holds a list of valid key signatures. If you are not
|
|
|
|
running in batch mode you will be asked to assign a trust parameter
|
1999-04-06 18:04:55 +00:00
|
|
|
(ownertrust) to a key.
|
1998-10-06 12:10:02 +00:00
|
|
|
|
1999-02-10 16:22:40 +00:00
|
|
|
You can see the validity (calculated trust value) using this command.
|
1998-10-06 12:10:02 +00:00
|
|
|
|
|
|
|
gpgm --list-keys --with-colons
|
|
|
|
|
1999-04-06 18:04:55 +00:00
|
|
|
If the first field is "pub" or "uid", the second field shows you the trust:
|
1998-10-06 12:10:02 +00:00
|
|
|
|
|
|
|
o = Unknown (this key is new to the system)
|
|
|
|
e = The key has expired
|
|
|
|
q = Undefined (no value assigned)
|
|
|
|
n = Don't trust this key at all
|
|
|
|
m = There is marginal trust in this key
|
|
|
|
f = The key is full trusted.
|
|
|
|
u = The key is ultimately trusted; this
|
|
|
|
is only used for keys for which
|
|
|
|
the secret key is also available.
|
|
|
|
|
1999-04-06 18:04:55 +00:00
|
|
|
The value in the "pub" record is the best one of all "uid" records.
|
|
|
|
|
1999-02-10 16:22:40 +00:00
|
|
|
You can get a list of the assigned trust values (how much you trust
|
|
|
|
the owner to correctly sign another person's key)
|
1998-10-06 12:10:02 +00:00
|
|
|
|
|
|
|
gpgm --list-ownertrust
|
|
|
|
|
1999-02-10 16:22:40 +00:00
|
|
|
The first field is the fingerprint of the primary key, the second field
|
|
|
|
is the assigned value:
|
1998-10-06 12:10:02 +00:00
|
|
|
|
|
|
|
- = No Ownertrust value yet assigned.
|
1999-01-12 10:20:24 +00:00
|
|
|
n = Never trust this keyholder to correctly verify others signatures.
|
1998-10-06 12:10:02 +00:00
|
|
|
m = Have marginal trust in the keyholders capability to sign other keys.
|
|
|
|
f = Assume that the key holder really knows how to sign keys.
|
|
|
|
u = No need to trust ourself because we have the secret key.
|
|
|
|
|
1999-02-10 16:22:40 +00:00
|
|
|
Keep these values confidential because they express your opinions
|
|
|
|
about others. PGP stores this information with the keyring thus
|
|
|
|
it is not a good idea to publish a PGP keyring instead of exporting the
|
|
|
|
keyring. gnupg stores the trust in the trust-DB so it is okay
|
|
|
|
to give a gpg keyring away (but we have a --export command too).
|
1998-10-06 12:10:02 +00:00
|
|
|
|
|
|
|
|
1999-01-12 10:20:24 +00:00
|
|
|
Q: What is the difference between options and commands?
|
1999-02-10 16:22:40 +00:00
|
|
|
A: If you do a "gpg --help", you will get two separate lists. The first is
|
|
|
|
a list of commands. The second is a list of options. Whenever you run GPG,
|
|
|
|
you *must* pick exactly one command (**with one exception, see below). You
|
|
|
|
*may* pick one or more options. The command should, just by convention,
|
|
|
|
come at the end of the argument list, after all the options. If the
|
|
|
|
command takes a file (all the basic ones do), the filename comes at the
|
|
|
|
very end. So the basic way to run gpg is:
|
1998-10-06 12:10:02 +00:00
|
|
|
|
|
|
|
gpg [--option something] [--option2] [--option3 something] --command file
|
|
|
|
|
|
|
|
Some options take arguments, for example the --output option (which can be
|
1999-02-10 16:22:40 +00:00
|
|
|
abbreviated -o) is an option that takes a filename. The option's argument
|
|
|
|
must follow immediately after the option itself, otherwise gpg doesn't know
|
1998-10-06 12:10:02 +00:00
|
|
|
which option the argument is supposed to go with. As an option, --output and
|
|
|
|
its filename must come before the command. The --remote-user (-r) option takes
|
|
|
|
a name or keyid to encrypt the message to, which must come right after the -r
|
1999-02-10 16:22:40 +00:00
|
|
|
argument. The --encrypt (or -e) command comes after all the options followed
|
|
|
|
by the file you wish to encrypt. So use
|
1998-10-06 12:10:02 +00:00
|
|
|
|
|
|
|
gpg -r alice -o secret.txt -e test.txt
|
|
|
|
|
1999-02-10 16:22:40 +00:00
|
|
|
If you write the options out in full, it is easier to read
|
1998-10-06 12:10:02 +00:00
|
|
|
|
|
|
|
gpg --remote-user alice --output secret.txt --encrypt test.txt
|
|
|
|
|
|
|
|
If you're saving it in a file called ".txt" then you'd probably expect to see
|
1999-02-10 16:22:40 +00:00
|
|
|
ASCII-armored text in there, so you need to add the --armor (-a) option,
|
|
|
|
which doesn't take any arguments.
|
1998-10-06 12:10:02 +00:00
|
|
|
|
|
|
|
gpg --armor --remote-user alice --output secret.txt --encrypt test.txt
|
|
|
|
|
|
|
|
If you imagine square brackets around the optional parts, it becomes a bit
|
|
|
|
clearer:
|
|
|
|
|
|
|
|
gpg [--armor] [--remote-user alice] [--output secret.txt] --encrypt test.txt
|
|
|
|
|
1999-02-10 16:22:40 +00:00
|
|
|
The optional parts can be rearranged any way you want.
|
1998-10-06 12:10:02 +00:00
|
|
|
|
|
|
|
gpg --output secret.txt --remote-user alice --armor --encrypt test.txt
|
|
|
|
|
|
|
|
If your filename begins with a hyphen (e.g. "-a.txt"), gnupg assumes this is
|
|
|
|
an option and may complain. To avoid this you have either to use
|
|
|
|
"./-a.txt" or stop the option and command processing with two hyphens:
|
|
|
|
"-- -a.txt".
|
|
|
|
|
|
|
|
** the exception: signing and encrypting at the same time. Use
|
|
|
|
|
|
|
|
gpg [--options] --sign --encrypt foo.txt
|
|
|
|
|
|
|
|
|
1998-10-12 20:16:38 +00:00
|
|
|
Q: What kind of output is this: "key C26EE891.298, uid 09FB: ...."?
|
1999-01-12 10:20:24 +00:00
|
|
|
A: This is the internal representation of an user id in the trustdb.
|
1998-10-12 20:16:38 +00:00
|
|
|
"C26EE891" is the keyid, "298" is the local id (a record number
|
1999-02-10 16:22:40 +00:00
|
|
|
in the trustdb) and "09FB" is the last two bytes of a ripe-md-160
|
1998-10-12 20:16:38 +00:00
|
|
|
hash of the user id for this key.
|
|
|
|
|
|
|
|
|
|
|
|
Q: What is trust, validity and ownertrust?
|
|
|
|
A: "ownertrust" is used instead of "trust" to make clear that
|
1999-04-06 18:04:55 +00:00
|
|
|
this is the value you have assigned to a key to express how much you
|
1998-10-12 20:16:38 +00:00
|
|
|
trust the owner of this key to correctly sign (and so introduce)
|
1999-02-10 16:22:40 +00:00
|
|
|
other keys. "validity", or calculated trust, is a value which
|
1999-04-06 18:04:55 +00:00
|
|
|
says how much GnuPG thinks a key is valid (that it really belongs
|
1998-10-12 20:16:38 +00:00
|
|
|
to the one who claims to be the owner of the key).
|
|
|
|
For more see the chapter "The Web of Trust" in the
|
|
|
|
Manual [gpg: Oops: Internal error: manual not found - sorry]
|
|
|
|
|
1999-04-06 18:04:55 +00:00
|
|
|
Q: How do I interpret some of the informational outputs?
|
1999-02-10 16:22:40 +00:00
|
|
|
A: While checking the validity of a key, GnuPG sometimes prints
|
|
|
|
some information which is prefixed with information about
|
|
|
|
the checked item.
|
1998-11-05 18:00:08 +00:00
|
|
|
"key 12345678.3456"
|
|
|
|
This is about the key with key ID 12345678 and the internal
|
|
|
|
number 3456, which is the record number of the so called
|
|
|
|
directory record in the trustdb.
|
|
|
|
"uid 12345678.3456/ACDE"
|
1999-02-10 16:22:40 +00:00
|
|
|
This is about the user ID for the same key. To identify the
|
1998-11-05 18:00:08 +00:00
|
|
|
user ID the last two bytes of a ripe-md-160 over the user ID
|
1999-01-12 10:20:24 +00:00
|
|
|
ring is printed.
|
1998-11-05 18:00:08 +00:00
|
|
|
"sig 12345678.3456/ACDE/9A8B7C6D"
|
|
|
|
This is about the signature with key ID 9A8B7C6D for the
|
|
|
|
above key and user ID, if it is a signature which is direct
|
|
|
|
on a key, the user ID part is empty (..//..).
|
1998-10-06 12:10:02 +00:00
|
|
|
|
1998-11-25 11:55:58 +00:00
|
|
|
|
|
|
|
Q: How do I sign a patch file?
|
|
|
|
A: Use "gpg --clearsign --not-dash-escaped ...".
|
1999-02-10 16:22:40 +00:00
|
|
|
The problem with --clearsign is that all lines starting with a dash are
|
|
|
|
quoted with "- "; obviously diff produces many of lines starting with a
|
|
|
|
dash and these are then quoted and that is not good for patch ;-). To
|
|
|
|
use a patch file without removing the cleartext signature, the special
|
|
|
|
option --not-dash-escaped may be used to suppress generation of these
|
1999-02-19 14:54:00 +00:00
|
|
|
escape sequences. You should not mail such a patch because spaces and
|
1999-02-10 16:22:40 +00:00
|
|
|
line endings are also subject to the signature and a mailer may not
|
|
|
|
preserve these. If you want to mail a file you can simply sign it
|
|
|
|
using your MUA.
|
1998-11-25 11:55:58 +00:00
|
|
|
|
|
|
|
|
1999-02-19 14:54:00 +00:00
|
|
|
Q: Where is the "encrypt-to-self" option?
|
|
|
|
A: Use "--encrypt-to your_keyid". You can use more than one
|
|
|
|
of these options. To temporary override the use of this additional
|
|
|
|
keys, you can use the option "--no-encrypt-to".
|
|
|
|
|
|
|
|
|
|
|
|
Q: How can I get rid of the Version and Comment headers in
|
|
|
|
armored messages?
|
|
|
|
A: Use "--no-version --comment ''". Note that the left over blank line
|
|
|
|
is required by the protocol.
|
|
|
|
|
|
|
|
|
1999-03-02 15:48:37 +00:00
|
|
|
Q: What does the "You are using the xxxx character set." mean?
|
|
|
|
A: This note is printed when UTF8 mapping has to be done. Make sure that
|
|
|
|
the displayed charset is the one you have activated on your system
|
|
|
|
"iso-8859-1" is the most used one, so this is the default. You can
|
|
|
|
change the charset with the option "--charset". It is important that
|
1999-04-06 18:04:55 +00:00
|
|
|
you active characterset matches the one displayed - if not, restrict
|
1999-03-02 15:48:37 +00:00
|
|
|
yourself to plain 7 bit ASCII and no mapping has to be done.
|
|
|
|
|