mirror of
git://git.gnupg.org/gnupg.git
synced 2024-12-23 10:29:58 +01:00
1020 lines
40 KiB
Plaintext
1020 lines
40 KiB
Plaintext
[$htmltitle=GnuPG FAQ]
|
|
[$sfaqheader=The GnuPG FAQ says:]
|
|
[$sfaqfooter=
|
|
The most recent version of the FAQ is available from
|
|
<http://www.gnupg.org/>
|
|
]
|
|
[$usenetheader=
|
|
]
|
|
[$maintainer=David D. Scribner, <faq 'at' gnupg.org>]
|
|
[$hGPG=http://www.gnupg.org]
|
|
|
|
[H body bgcolor=#ffffff text=#000000 link=#1f00ff alink=#ff0000 vlink=#9900dd]
|
|
[H H1]GnuPG Frequently Asked Questions[H /H1]
|
|
|
|
|
|
[H p]
|
|
Version: 1.5.7[H br]
|
|
Last-Modified: Aug 21, 2002[H br]
|
|
Maintained-by: [$maintainer]
|
|
[H /p]
|
|
|
|
|
|
This is the GnuPG FAQ. The latest HTML version is available
|
|
[H a href=[$hGPG]/faq.html]here[H/a].
|
|
|
|
The index is generated automatically, so there may be errors here. Not
|
|
all questions may be in the section they belong to. Suggestions about
|
|
how to improve the structure of this FAQ are welcome.
|
|
|
|
Please send additions and corrections to the maintainer. It would be
|
|
most convenient if you could provide the answer to be included here
|
|
as well. Your help is very much appreciated.
|
|
|
|
Please, don't send message like "This should be a FAQ - what's the answer?".
|
|
If it hasn't been asked before, it isn't a FAQ. In that case you could
|
|
search in the mailing list archive.
|
|
|
|
[H HR]
|
|
<C>
|
|
[H HR]
|
|
|
|
|
|
<S> GENERAL
|
|
|
|
<Q> What is GnuPG?
|
|
|
|
[H a href=[$hGPG]]GnuPG[H /a] stands for GNU Privacy Guard and
|
|
is GNU's tool for secure communication and data storage. It can be
|
|
used to encrypt data and to create digital signatures. It includes
|
|
an advanced key management facility and is compliant with the
|
|
proposed OpenPGP Internet standard as described in [H a href=http://www.gnupg.org/rfc2440.html]RFC 2440[H/a].
|
|
As such, it is aimed to be compatible with PGP from NAI, Inc.
|
|
|
|
<Q> Is GnuPG compatible with PGP?
|
|
|
|
In general, yes. GnuPG and newer PGP releases should be implementing
|
|
the OpenPGP standard. But there are some interoperability
|
|
problems. See question <Rcompat> for details.
|
|
|
|
|
|
<S> SOURCES of INFORMATION
|
|
|
|
<Q> Where can I find more information?
|
|
|
|
Here's a list of on-line resources:
|
|
|
|
[H UL]
|
|
[H LI]The documentation page is located at [H a href=[$hGPG]/docs.html]<[$hGPG]/docs.html>[H/a].
|
|
Have a look at the HOWTOs and the GNU Privacy Handbook (GPH, available
|
|
in English, Spanish and Russian). The latter provides a detailed user's
|
|
guide to GnuPG. You'll also find a document about how to convert from
|
|
PGP 2.x to GnuPG.
|
|
|
|
[H LI]On [H a href=http://lists.gnupg.org]<http://lists.gnupg.org>[H/a] you'll find an online archive of the
|
|
GnuPG mailing lists. Most interesting should be gnupg-users for all
|
|
user-related issues and gnupg-devel if you want to get in touch with
|
|
the developers.
|
|
|
|
In addition, searchable archives can be found on MARC, e.g.: [H br]
|
|
GnuPG-users: [H a href=http://marc.theaimsgroup.com/?l=gnupg-users&r=1&w=2]<http://marc.theaimsgroup.com/?l=gnupg-users&r=1&w=2>[H/a],[H br]
|
|
GnuPG-devel: [H a href=http://marc.theaimsgroup.com/?l=gnupg-devel&r=1&w=2]<http://marc.theaimsgroup.com/?l=gnupg-devel&r=1&w=2>[H/a].[H br]
|
|
|
|
[H B]PLEASE:[H/B]
|
|
Before posting to a list, read this FAQ and the available
|
|
documentation. In addition, search the list archive - maybe your
|
|
question has already been discussed. This way you help people focus
|
|
on topics that have not yet been resolved.
|
|
|
|
[H LI]The GnuPG source distribution contains a subdirectory:
|
|
|
|
[H PRE]
|
|
./doc
|
|
[H /PRE]
|
|
|
|
where some additional documentation is located (mainly interesting
|
|
for hackers, not the casual user).
|
|
[H /UL]
|
|
|
|
<Q> Where do I get GnuPG?
|
|
|
|
You can download the GNU Privacy Guard from its primary FTP server
|
|
[H a href=ftp://ftp.gnupg.org/pub/gcrypt]ftp.gnupg.org[H /a] or from one of the mirrors:
|
|
|
|
[H a href=[$hGPG]/mirrors.html]
|
|
<[$hGPG]/mirror.html>
|
|
[H /a]
|
|
|
|
The current version is 1.0.4, please upgrade to this version as it
|
|
fixes a security bug regarding the verification of multiple signatures.
|
|
|
|
|
|
<S> INSTALLATION
|
|
|
|
<Q> Which OSes does GnuPG run on?
|
|
|
|
It should run on most Unices as well as Windows 95 and Windows NT. A
|
|
list of OSes reported to be OK is presented at:
|
|
|
|
[H a href=http://www.gnupg.org/backend.html#supsys]
|
|
<http://www.gnupg.org/gnupg.html#supsys>
|
|
[H /a]
|
|
|
|
<Q> Which random gatherer should I use?
|
|
|
|
"Good" random numbers are crucial for the security of your encryption.
|
|
Different operating systems provide a variety of more or less quality
|
|
random data. Linux and *BSD provide kernel generated random data
|
|
through /dev/random - this should be the preferred choice on these
|
|
systems. Also Solaris users with the SUNWski package installed have
|
|
a /dev/random. In these cases, use the configure option:
|
|
|
|
[H pre]
|
|
--enable-static-rnd=linux
|
|
[H/pre]
|
|
|
|
In addition, there's also the kernel random device by Andi Maier
|
|
[H a href= http://www.cosy.sbg.ac.at/~andi]<http://www.cosy.sbg.ac.at/~andi>[H /a], but it's still beta. Use at your
|
|
own risk!
|
|
|
|
On other systems, the Entropy Gathering Daemon (EGD) is a good choice.
|
|
It is a perl-daemon that monitors system activity and hashes it into
|
|
random data. See the download page [H a href=http://www.gnupg.org/download.html]<http://www.gnupg.org/download.html>[H /a]
|
|
to obtain egd. Use:
|
|
|
|
[H pre]
|
|
--enable-static-rnd=egd
|
|
[H/pre]
|
|
|
|
here.
|
|
|
|
If the above options do not work, you can use the random number
|
|
generator "unix". This is [H B]very[H /B] slow and should be avoiced. The
|
|
random quality isn't very good so don't use it on sensitive data.
|
|
|
|
<Didea>
|
|
<Q> How do I include support for RSA and IDEA?
|
|
|
|
RSA is included as of GnuPG 1.0.3.
|
|
|
|
The official GnuPG distribution does not contain IDEA due to a
|
|
patent restriction. The patent does not expire before 2007 so don't
|
|
expect official support before then.
|
|
|
|
However, there is an unofficial module to include it even
|
|
in earlier versions of GnuPG. It's available from
|
|
[H a href=ftp://ftp.gnupg.org/pub/gcrypt/contrib/]<ftp://ftp.gnupg.org/pub/gcrypt/contrib/>[H /a]. Look for:
|
|
|
|
[H pre]
|
|
idea.c
|
|
[H /pre]
|
|
|
|
Compilation directives are in the headers of these files. Then add
|
|
the following line to your ~/.gnupg/options:
|
|
|
|
[H pre]
|
|
load-extension idea
|
|
[H /pre]
|
|
|
|
|
|
<S> USAGE
|
|
|
|
<Q> What is the recommended key size?
|
|
|
|
1024 bit for DSA signatures; even for plain ElGamal signatures
|
|
this is sufficient as the size of the hash is probably the weakest
|
|
link if the key size is larger than 1024 bits. Encryption keys may
|
|
have greater sizes, but you should then check the fingerprint of
|
|
this key:
|
|
|
|
[H pre]
|
|
gpg --fingerprint <user ID>
|
|
[H /pre]
|
|
|
|
As for the key algorithms, you should stick with the default (i.e.,
|
|
DSA signature and ElGamal encryption). A ElGamal signing key has the
|
|
following disadvantages: the signature is larger, it is hard to
|
|
create such a key useful for signatures which can withstand some
|
|
real world attacks, you don't get any extra security compared to
|
|
DSA, and there might be compatibility problems with certain PGP
|
|
versions. It has only been introduced because at the time it was
|
|
not clear whether there was a patent on DSA.
|
|
|
|
<Q> Why does it sometimes take so long to create keys?
|
|
|
|
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
|
|
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 its price.
|
|
What I do is to hit several times on the shift, control, alternate,
|
|
and caps lock 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).
|
|
|
|
Another problem might be another program which eats up your random
|
|
bytes (a program (look at your daemons) that reads from /dev/random).
|
|
|
|
<Q> And it really takes long when I work on a remote system. Why?
|
|
|
|
Don't do this at all! You should never create keys or even use GnuPG
|
|
on a remote system because you normally have no physical control
|
|
over your secret key ring (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 that you can trust your system
|
|
administrator.
|
|
|
|
When I check GnuPG on a remote system via ssh (I have no Alpha here
|
|
;-) 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.
|
|
|
|
<Q> What is the difference between options and commands?
|
|
|
|
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 [H B]must[H /B] pick exactly one command (with one exception,
|
|
see below). You [H B]may[H /B] 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:
|
|
|
|
[H pre]
|
|
gpg [--option something] [--option2] [--option3 something] --command file
|
|
[H/pre]
|
|
|
|
Some options take arguments. For example, the --output option (which
|
|
can be 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 which option the argument is supposed to
|
|
go with. As an option, --output and its filename must come before
|
|
the command. The --recipient (-r) option takes a name or keyid to
|
|
encrypt the message to, which must come right after the -r argument.
|
|
The --encrypt (or -e) command comes after all the options followed
|
|
by the file you wish to encrypt. So use:
|
|
|
|
[H pre]
|
|
gpg -r alice -o secret.txt -e test.txt
|
|
[H/pre]
|
|
|
|
If you write the options out in full, it is easier to read:
|
|
|
|
[H pre]
|
|
gpg --recipient alice --output secret.txt --encrypt test.txt
|
|
[H/pre]
|
|
|
|
If you're saving it in a file called ".txt" then you'd probably
|
|
expect to see ASCII-armored text in there, so you need to add the
|
|
--armor (-a) option, which doesn't take any arguments:
|
|
|
|
[H pre]
|
|
gpg --armor --recipient alice --output secret.txt --encrypt test.txt
|
|
[H/pre]
|
|
|
|
If you imagine square brackets around the optional parts, it becomes
|
|
a bit clearer:
|
|
|
|
[H pre]
|
|
gpg [--armor] [--recipient alice] [--output secret.txt] --encrypt test.txt
|
|
[H/pre]
|
|
|
|
The optional parts can be rearranged any way you want:
|
|
|
|
[H pre]
|
|
gpg --output secret.txt --recipient alice --armor --encrypt test.txt
|
|
[H/pre]
|
|
|
|
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". [H B]The exception:[H /B] signing and encrypting at the
|
|
same time. Use:
|
|
|
|
[H pre]
|
|
gpg [--options] --sign --encrypt foo.txt
|
|
[H/pre]
|
|
|
|
<Q> I can't delete a user ID because it is already deleted on my public
|
|
keyring?
|
|
|
|
Because you can only select from the public key ring, there is no
|
|
direct way to do this. However it is not very complicated to do
|
|
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.
|
|
|
|
<Q> I can't delete the secret key because my public key disappeared?
|
|
|
|
To select a key a search is always done on the public keyring,
|
|
therefore it is not possible to select an secret key without
|
|
having the public key. Normally it shoud never happen that the
|
|
public key got lost but the secret key is still available. The
|
|
reality is different, so GnuPG implements a special way to deal
|
|
with it: Simply use the long keyid which can be obtained by using
|
|
the --with-colons options (it is the fifth field in the lines
|
|
beginning with "sec").
|
|
|
|
<Q> What are trust, validity and ownertrust?
|
|
|
|
"ownertrust" is used instead of "trust" to make clear that this is
|
|
the value you have assigned to a key to express how much you trust
|
|
the owner of this key to correctly sign (and so introduce) other
|
|
keys. "validity", or calculated trust, is a value which says how
|
|
much GnuPG thinks a key is valid (that it really belongs to the one
|
|
who claims to be the owner of the key). For more see the chapter
|
|
"The Web of Trust" in the Manual.
|
|
|
|
<Q> How do I sign a patch file?
|
|
|
|
Use "gpg --clearsign --not-dash-escaped ...". The problem with
|
|
--clearsign is that all lines starting with a dash are quoted with
|
|
"- "; obviously diff produces many lines starting with a dash and
|
|
these are then quoted and that is not good for a 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 escape sequences. You should not mail such a patch because
|
|
spaces and 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.
|
|
|
|
<Q> Where is the "encrypt-to-self" option?
|
|
|
|
Use "--encrypt-to your_keyid". You can use more than one of these
|
|
options. To temporarily override the use of this additional key,
|
|
you can use the option "--no-encrypt-to".
|
|
|
|
<Q> How can I get rid of the Version and Comment headers in armored
|
|
messages?
|
|
|
|
Use "--no-version --comment ''". Note that the left over blank line
|
|
is required by the protocol.
|
|
|
|
<Q> What does the "You are using the xxxx character set." mean?
|
|
|
|
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. Since "iso-8859-1" is the charset most used, this is the
|
|
default. You can change the charset with the option "--charset".
|
|
It is important that your active character set matches the one
|
|
displayed - if not, restrict yourself to plain 7 bit ASCII and no
|
|
mapping has to be done.
|
|
|
|
<Q> How can a get list of key IDs used to encrypt a message?
|
|
|
|
[H pre]
|
|
gpg --batch --decrypt --list-only --status-fd 1 2>/dev/null | \
|
|
awk '/^\[GNUPG:\] ENC_TO / { print $3 }'
|
|
[H /pre]
|
|
|
|
<Q> I can't decrypt my symmetrical only (-c) encrypted message with
|
|
a new version of GnuPG.
|
|
|
|
There used to be a bug in GnuPG < 1.0.1 which happens only if 3DES
|
|
or Twofish has been used for symmetric only encryption (this has
|
|
never been the default). The bug has been fixed but to enable you
|
|
to decrypt old messages, you should run gpg with the option
|
|
"--emulate-3des-s2k-bug", decrypt the message and encrypt it again
|
|
without this option. The option will be removed in 1.1, so better
|
|
re-encrypt your message now.
|
|
|
|
<Q> How can I use GnuPG in an automated environment?
|
|
|
|
You should use the option --batch and don't use pass phrases as
|
|
there is usually no way to store it more secure than the secret
|
|
keyring itself. The suggested way to create the keys for the
|
|
automated environment is:
|
|
|
|
On a secure machine:
|
|
[H OL]
|
|
[H LI] If you want to do automatic signing, create a signing
|
|
subkey for your key (edit menu, choose "addkey" and the DSA).
|
|
[H LI] Make sure that you use a passphrase (needed by the current
|
|
implementation).
|
|
[H LI] gpg --export-secret-subkeys --no-comment foo >secring.auto
|
|
[H LI] Copy secring.auto and the public keyring to a test directory.
|
|
[H LI] Change to this directory.
|
|
[H LI] gpg --homedir . --edit foo and use "passwd" to remove the
|
|
passphrase from the subkeys. You may also want to remove all
|
|
unused subkeys.
|
|
[H LI] Copy secring.auto to a floppy and carry it to the target box.
|
|
[H /OL]
|
|
|
|
On the target machine:
|
|
[H OL]
|
|
[H LI] Install secring.auto as secret keyring.
|
|
[H LI] Now you can start your new service. It is a good idea to
|
|
install some intrusion detection system so that you hopefully
|
|
get a notice of an successful intrusion, so that you in turn
|
|
can revoke all the subkeys installed on that machine and
|
|
install new subkeys.
|
|
[H /OL]
|
|
|
|
<Q> Which email-client can I use with GnuPG?
|
|
|
|
Using GnuPG to encrypt email is one of the most popular uses.
|
|
Several mail clients or mail user-agents (MUA) support GnuPG at
|
|
varying degrees. Simplifying a bit, there are two ways mail can be
|
|
encrypted with GnuPG: the "old style" ASCII armor, i.e. plain text
|
|
encryption, and RFC2015 style (previously PGP/MIME, now OpenPGP).
|
|
The latter has full MIME support. Some MUAs support only one of
|
|
them, so whichever you actually use depends on your needs as well
|
|
as the capabilities of your addressee.
|
|
|
|
The following list is probably not exhaustive:
|
|
|
|
OpenPGP: Mutt (Unix), Emacs/Mew, Becky2 (Windows, with plugin),
|
|
TkRat (Unix). There is effort for a Mozilla plugin and
|
|
Emacs/GNUS has support in the current CVS.
|
|
|
|
ASCII: Emacs/{VM,GNUS}/MailCrypt, Mutt(Unix), Pine(Unix), and
|
|
probably many more.
|
|
|
|
Good overviews of OpenPGP-support can be found at
|
|
[H a href=http://cryptorights.org/pgp-users/pgp-mail-clients.html]http://cryptorights.org/pgp-users/pgp-mail-clients.html[H /a]
|
|
and [H a href=http://www.geocities.com/openpgp/courrier_en.html]http://www.geocities.com/openpgp/courrier_en.html[H /a].
|
|
|
|
<Q> Can't we have a gpg library?
|
|
|
|
This has been frequently requested. However, the current viewpoint
|
|
of the GnuPG maintainers is that this would lead to several security
|
|
issues and will therefore not be implemented in the foreseeable
|
|
future. However, for some areas of application gpgme could do the
|
|
trick. You'll find it at [H a href=ftp://ftp.guug.de/pub/gcrypt/alpha/gpgme]ftp://ftp.guug.de/pub/gcrypt/alpha/gpgme[H /a].
|
|
|
|
<Q> I have successfully generated a revocation certificate, but I don't
|
|
understand how to send it to the key servers.
|
|
|
|
Most keyservers don't accept a 'bare' revocation certificate. You
|
|
have to import the certificate into gpg first:
|
|
|
|
[H pre]
|
|
gpg --import my-revocation.asc
|
|
[H /pre]
|
|
|
|
then send the revoked key to the keyservers:
|
|
|
|
[H pre]
|
|
gpg --keyserver certserver.pgp.com --send-keys mykeyid
|
|
[H /pre]
|
|
|
|
(or use a keyserver web interface for this).
|
|
|
|
<Q> How do I put my keyring in a different directory?
|
|
|
|
GnuPG keeps several files in a special homedir directory. These
|
|
include the options file, pubring.gpg, secring.gpg, trustdb.gpg,
|
|
and others. GnuPG will always create and use these files. On unices,
|
|
the homedir is usually ~/.gnupg; on Windows "C:\gnupg\".
|
|
|
|
If you want to put your keyrings somewhere else, use:
|
|
|
|
[H pre]
|
|
--homedir /my/path/
|
|
[H /pre]
|
|
|
|
to make GnuPG create all its files in that directory. Your keyring
|
|
will be "/my/path/pubring.gpg". This way you can store your secrets
|
|
on a floppy disk. Don't use "--keyring" as its purpose is to specify
|
|
additional keyring files.
|
|
|
|
|
|
<S> COMPATIBILITY ISSUES
|
|
|
|
<Dcompat>
|
|
<Q> How can I encrypt a message with GnuPG so that PGP is able to decrypt it?
|
|
|
|
It depends on the PGP version.
|
|
|
|
[H UL]
|
|
[H LI]PGP 2.x[H br]
|
|
You can't do that because PGP 2.x normally uses IDEA which is not
|
|
supported by GnuPG as it is patented (see <Ridea>), but if you have a
|
|
modified version of PGP you can try this:
|
|
|
|
[H pre]
|
|
gpg --rfc1991 --cipher-algo 3des ...
|
|
[H/pre]
|
|
|
|
Please don't pipe the data to encrypt to gpg but provide it using a
|
|
filename; otherwise, PGP 2 will not be able to handle it.
|
|
|
|
As for conventional encryption, you can't do this for PGP 2.
|
|
|
|
[H LI]PGP 5.x and higher[H br]
|
|
You need to provide two additional options:
|
|
|
|
[H pre]
|
|
--compress-algo 1 --cipher-algo cast5
|
|
[H/pre]
|
|
|
|
You may also use "3des" instead of "cast5", and "blowfish" does not
|
|
work with all versions of PGP 5. You may also want to put:
|
|
|
|
[H pre]
|
|
compress-algo 1
|
|
[H/pre]
|
|
|
|
into your ~/.gnupg/options file - this does not affect normal GnuPG
|
|
operation.
|
|
|
|
This applies to conventional encryption as well.
|
|
[H /UL]
|
|
|
|
<Q> How do I migrate from PGP 2.x to GnuPG?
|
|
|
|
PGP 2 uses the RSA and IDEA encryption algorithms. Whereas the RSA
|
|
patent has expired and RSA is included as of GnuPG 1.0.3, the IDEA
|
|
algorithm is still patented until 2007. Under certain conditions you
|
|
may use IDEA even today. In that case, you may refer to Question
|
|
<Ridea> about how to add IDEA support to GnuPG and read
|
|
[H a href=http://www.gnupg.org/gph/en/pgp2x.html]http://www.gnupg.org/gph/en/pgp2x.html[H /a] to perform the migration.
|
|
|
|
<Q> (removed)
|
|
|
|
(empty)
|
|
|
|
<Q> Why is PGP 5.x not able to encrypt messages with some keys?
|
|
|
|
PGP, Inc. refuses to accept ElGamal keys of type 20 even for
|
|
encryption. They only support type 16 (which is identical at least
|
|
for decryption). To be more inter-operable, GnuPG (starting with
|
|
version 0.3.3) now also uses type 16 for the ElGamal subkey which is
|
|
created if the default key algorithm is chosen. You may add a type
|
|
16 ElGamal key to your public key, which is easy as your key
|
|
signatures are still valid.
|
|
|
|
<Q> Why is PGP 5.x not able to verify my messages?
|
|
|
|
PGP 5.x does not accept v4 signatures for data material but OpenPGP
|
|
requests generation of v4 signatures for all kind of data, that's why
|
|
GnuPG defaults to them. Use the option "--force-v3-sigs" to generate
|
|
v3 signatures for data.
|
|
|
|
<Q> How do I transfer owner trust values from PGP to GnuPG?
|
|
|
|
There is a script in the tools directory to help you. After you have
|
|
imported the PGP keyring you can give this command:
|
|
|
|
[H pre]
|
|
$ lspgpot pgpkeyring | gpg --import-ownertrust
|
|
[H /pre]
|
|
|
|
where pgpkeyring is the original keyring and not the GnuPG keyring
|
|
you might have created in the first step.
|
|
|
|
<Q> PGP does not like my secret key.
|
|
|
|
Older PGPs probably bail out on some private comment packets used by
|
|
GnuPG. These packets are fully in compliance with OpenPGP; however
|
|
PGP is not really OpenPGP aware. A workaround is to export the
|
|
secret keys with this command:
|
|
|
|
[H pre]
|
|
$ gpg --export-secret-keys --no-comment -a your-key-id
|
|
[H /pre]
|
|
|
|
Another possibility is this: by default, GnuPG encrypts your secret
|
|
key using the Blowfish symmetric algorithm. Older PGPs will only
|
|
understand 3DES, CAST5, or IDEA symmetric algorithms. Using the
|
|
following method you can re-encrypt your secret gpg key with a
|
|
different algo:
|
|
|
|
[H pre]
|
|
$ gpg --s2k-cipher-algo=CAST5 --s2k-digest-algo=SHA1 \
|
|
--compress-algo=1 --edit-key <username>
|
|
[H /pre]
|
|
|
|
Then use passwd to change the password (just change it to the same
|
|
thing, but it will encrypt the key with CAST5 this time).
|
|
|
|
Now you can export it and PGP should be able to handle it.
|
|
|
|
For PGP 6.x the following options work to export a key:
|
|
|
|
[H pre]
|
|
$ gpg --s2k-cipher-algo 3des --compress-algo 1 --rfc1991 \
|
|
--export-secret-keys <key-ID>
|
|
[H /pre]
|
|
|
|
|
|
<S> PROBLEMS and ERROR MESSAGES
|
|
|
|
<Q> Why do I get "gpg: Warning: using insecure memory!"
|
|
|
|
On many systems this program should be installed as setuid(root).
|
|
This is necessary to lock memory pages. Locking memory pages prevents
|
|
the operating system from writing them to disk and thereby keeping your
|
|
secret keys really secret. If you get no warning message about insecure
|
|
memory your operating system supports locking without being root. The
|
|
program drops root privileges as soon as locked memory is allocated.
|
|
|
|
On UnixWare 2.x and 7.x you should install GnuPG with the 'plock'
|
|
privilege to get the same effect:
|
|
|
|
[H pre]
|
|
filepriv -f plock /path/to/gpg
|
|
[H /pre]
|
|
|
|
If you can't or don't want to install GnuPG setuid(root), you can
|
|
use the option "--no-secmem-warning" or put:
|
|
|
|
[H pre]
|
|
no-secmem-warning
|
|
[H /pre]
|
|
|
|
in your ~/.gnupg/options file (this disables the warning).
|
|
|
|
On some systems (e.g., Windows) GnuPG does not lock memory pages
|
|
and older GnuPG versions (<=1.0.4) issue the warning:
|
|
|
|
[H pre]
|
|
gpg: Please note that you don't have secure memory
|
|
[H /pre]
|
|
|
|
This warning can't be switched off by the above option because it
|
|
was thought to be too serious an issue. However, it confused users
|
|
too much, so the warning was eventually removed.
|
|
|
|
<Q> Large File Support doesn't work ...
|
|
|
|
LFS is correctly working in post-1.0.4 CVS. If configure doesn't
|
|
detect it correctly, try a different (i.e., better) compiler. egcs
|
|
1.1.2 works fine, other gccs sometimes don't. BTW, several
|
|
compilation problems of GnuPG 1.0.3 and 1.0.4 on HP-UX and Solaris
|
|
were due to broken LFS support.
|
|
|
|
<Q> In the edit menu the trust values is not displayed correctly after
|
|
signing uids - why?
|
|
|
|
This happens because some information is stored immediately in
|
|
the trustdb, but the actual trust calculation can be done after the
|
|
save command. This is a "not easy to fix" design bug which will be
|
|
addressed in some future release.
|
|
|
|
<Q> What does "skipping pubkey 1: already loaded" mean?
|
|
|
|
As of GnuPG 1.0.3, the RSA algorithm is included. If you still have
|
|
a "load-extension rsa" in your options file, the above message
|
|
occurs. Just remove the load command from the options file.
|
|
|
|
<Q> GnuPG 1.0.4 doesn't create ~/.gnupg ...
|
|
|
|
That's a known bug, already fixed in newer versions.
|
|
|
|
<Q> An ElGamal signature does not verify anymore since version 1.0.2 ...
|
|
|
|
Use the option --emulate-md-encode-bug.
|
|
|
|
<Q> Old versions of GnuPG can't verify ElGamal signatures
|
|
|
|
Update to GnuPG 1.0.2 or newer.
|
|
|
|
<Q> When I use --clearsign, the plain text has sometimes extra dashes
|
|
in it - why?
|
|
|
|
This is called dash-escaped text and is required by OpenPGP.
|
|
It always happens when a line starts with a dash ("-") and is
|
|
needed to make the lines that structure signature and text
|
|
(i.e., "-----BEGIN PGP SIGNATURE-----") to be the only lines
|
|
that start with two dashes.
|
|
|
|
If you use GnuPG to process those messages, the extra dashes
|
|
are removed. Good mail clients remove those extra dashes when
|
|
displaying such a message.
|
|
|
|
<Q> What is the thing with "can't handle multiple signatures"?
|
|
|
|
Due to different message formats GnuPG is not always able to split
|
|
a file with multiple signatures unambiguously into its parts. This
|
|
error message informs you that there is something wrong with the input.
|
|
|
|
The only way to have multiple signatures in a file is by using the
|
|
OpenPGP format with one-pass-signature packets (which is GnuPG's
|
|
default) or the cleartext signed format.
|
|
|
|
<Q> If I submit a key to a keyserver, nothing happens ...
|
|
|
|
You are most likely using GnuPG 1.0.2 or older on Windows. That's
|
|
feature isn't yet implemented, but it's a bug not to say it. Newer
|
|
versions issue a warning. Upgrade to 1.0.4 or newer.
|
|
|
|
<Q> I get "gpg: waiting for lock ..."
|
|
|
|
A previous gpg has most likely exited abnormally and left a lock
|
|
file. Go to ~/.gnupg and look for .*.lock files and remove them.
|
|
|
|
<Q> Older gpg's (e.g., 1.0) have problems with keys from newer gpgs ...
|
|
|
|
As of 1.0.3, keys generated with gpg are created with preferences to
|
|
TWOFISH (and AES since 1.0.4) and that also means that they have the
|
|
capability to use the new MDC encryption method. This will go into
|
|
OpenPGP soon and is also suppoted by PGP 7. This new method avoids
|
|
a (not so new) attack on all email encryption systems.
|
|
|
|
This in turn means that pre-1.0.3 gpg's have problems with newer
|
|
keys. Because of security fixes, you should keep your GnuPG
|
|
installation in a recent state anyway. As a workaround, you can
|
|
force gpg to use a previous default cipher algo by putting:
|
|
|
|
[H pre]
|
|
cipher-algo cast5
|
|
[H /pre]
|
|
|
|
into your options file.
|
|
|
|
<Q> With 1.0.4, I get "this cipher algorithm is deprecated ..."
|
|
|
|
If you just generated a new key and get this message while
|
|
encrypting, you've witnessed a bug in 1.0.4. It uses the new AES
|
|
cipher Rijndael that is incorrectly being referred as "deprecated".
|
|
Ignore this warning, more recent versions of gpg are corrected.
|
|
|
|
<Q> Some dates are displayed as ????-??-??, why?
|
|
|
|
Due to constraints in most libc implementations, dates beyond
|
|
2038-01-19 can't be displayed correctly. 64 bit OSes are not
|
|
affected by this problem. To avoid printing wrong dates, GnuPG
|
|
instead prints some question marks. To see the correct value, you
|
|
can use the options --with-colons and --fixed-list-mode.
|
|
|
|
<Q> I still have a problem. How do I report a bug?
|
|
|
|
Are you sure that it's not been mentioned somewhere on the mailing
|
|
lists? Did you have a look at the bug list (you'll find a link to
|
|
the list of reported bugs on the documentation page). If you're not
|
|
sure about it being a bug, you can send mail to the gnupg-devel
|
|
list. Otherwise, use the GUUG bug tracking system
|
|
[H a href=http://bugs.guug.de/Reporting.html]http://bugs.guug.de/Reporting.html[H /a].
|
|
|
|
<Q> Why doesn't GnuPG support X509 certificates?
|
|
|
|
GnuPG, first and foremost, is an implementation of the OpenPGP
|
|
standard (RFC 2440), which is a competing infrastructure, different
|
|
from X509.
|
|
|
|
They are both public-key cryptosystems, but how the public keys are
|
|
actually handled is different.
|
|
|
|
<Q> Why do national characters in my user ID look funny?
|
|
|
|
According to OpenPGP, GnuPG encodes user ID strings (and other
|
|
things) using UTF-8. In this encoding of Unicode, most national
|
|
characters get encoded as two- or three-byte sequences. For
|
|
example, å (0xE5 in ISO-8859-1) becomes Ã¥ (0xC3,
|
|
0xA5). This might also be the reason why keyservers can't find
|
|
your key.
|
|
|
|
<Q> I get 'sed' errors when running ./configure on Mac OS X ...
|
|
|
|
This will be fixed after GnuPG has been upgraded to autoconf-2.50.
|
|
Until then, find the line setting CDPATH in the configure script
|
|
and place a:
|
|
|
|
[H pre]
|
|
unset CDPATH
|
|
[H /pre]
|
|
|
|
statement below it.
|
|
|
|
<Q> Why does GnuPG 1.0.6 bail out on keyrings used with 1.0.7?
|
|
|
|
There is a small bug in 1.0.6 which didn't parse trust packets
|
|
correctly. You may want to apply this patch if you can't upgrade:
|
|
|
|
[H pre]
|
|
http://www.gnupg.org/developer/gpg-woody-fix.txt
|
|
[H /pre]
|
|
|
|
|
|
<S> ADVANCED TOPICS
|
|
|
|
<Q> How does this whole thing work?
|
|
|
|
To generate a secret/public keypair, run:
|
|
|
|
[H pre]
|
|
gpg --gen-key
|
|
[H/pre]
|
|
|
|
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.
|
|
|
|
GnuPG is also useful for signing things. Things that are encrypted
|
|
with the secret key can be decrypted with the public key. To sign
|
|
something, a 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.
|
|
|
|
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 should be very
|
|
careful with. 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 decrypt it. This is usually most useful for encrypting things to
|
|
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 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 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 keys. This is normally not useful, but you can generate
|
|
the key on one 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
|
|
that person: You should verify the key fingerprint with:
|
|
|
|
[H pre]
|
|
gpg --fingerprint user-id
|
|
[H/pre]
|
|
|
|
over the phone (if you really know the voice of the other person), 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
|
|
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.
|
|
|
|
Oh yeah, this is important. By default all data is encrypted in some
|
|
weird binary format. If you want to have things appear in ASCII text
|
|
that is readable, just add the '-a' option. But the preferred method
|
|
is to use a MIME aware mail reader (Mutt, Pine and many more).
|
|
|
|
There is a small security glitch in the OpenPGP (and therefore GnuPG)
|
|
system; to avoid this you should always sign and encrypt a message
|
|
instead of only encrypting it.
|
|
|
|
<Q> Why are some signatures with an ELG-E key valid?
|
|
|
|
These are ElGamal keys generated by GnuPG in v3 (RFC 1991) packets.
|
|
The OpenPGP draft later changed the algorithm identifier for ElGamal
|
|
keys which are usable for signatures and encryption from 16 to 20.
|
|
GnuPG now uses 20 when it generates new ElGamal keys but still
|
|
accepts 16 (which is according to OpenPGP "encryption only") if this
|
|
key is in a v3 packet. GnuPG is the only program which had used
|
|
these v3 ElGamal keys - so this assumption is quite safe.
|
|
|
|
<Q> How does the whole trust thing work?
|
|
|
|
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 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 (ownertrust) to a key.
|
|
|
|
You can see the validity (calculated trust value) using this
|
|
command.
|
|
|
|
[H pre]
|
|
gpg --list-keys --with-colons
|
|
[H/pre]
|
|
|
|
If the first field is "pub" or "uid", the second field shows you the
|
|
trust:
|
|
|
|
[H pre]
|
|
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.
|
|
r = The key has been revoked
|
|
d = The key has been disabled
|
|
[H/pre]
|
|
|
|
The value in the "pub" record is the best one of all "uid" records.
|
|
You can get a list of the assigned trust values (how much you trust
|
|
the owner to correctly sign another person's key) with:
|
|
|
|
[H pre]
|
|
gpg --list-ownertrust
|
|
[H/pre]
|
|
|
|
The first field is the fingerprint of the primary key, the second
|
|
field is the assigned value:
|
|
|
|
[H pre]
|
|
- = No Ownertrust value yet assigned.
|
|
n = Never trust this keyholder to correctly verify others signatures.
|
|
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.
|
|
[H/pre]
|
|
|
|
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 trustdb.gpg file so it is okay
|
|
to give a gpg keyring away (but we have a --export command too).
|
|
|
|
<Q> What kind of output is this: "key C26EE891.298, uid 09FB: ...."?
|
|
|
|
This is the internal representation of a user ID in the trustdb.
|
|
"C26EE891" is the keyid, "298" is the local ID (a record number in
|
|
the trustdb) and "09FB" is the last two bytes of a ripe-md-160 hash
|
|
of the user ID for this key.
|
|
|
|
<Q> How do I interpret some of the informational outputs?
|
|
|
|
While checking the validity of a key, GnuPG sometimes prints some
|
|
information which is prefixed with information about the checked
|
|
item.
|
|
|
|
[H pre]
|
|
"key 12345678.3456"
|
|
[H/pre]
|
|
|
|
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.
|
|
|
|
[H pre]
|
|
"uid 12345678.3456/ACDE"
|
|
[H/pre]
|
|
|
|
This is about the user ID for the same key. To identify the user ID
|
|
the last two bytes of a ripe-md-160 over the user ID ring is printed.
|
|
|
|
[H pre]
|
|
"sig 12345678.3456/ACDE/9A8B7C6D"
|
|
[H/pre]
|
|
|
|
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 (..//..).
|
|
|
|
<Q> Are the header lines of a cleartext signature part of the signed
|
|
material?
|
|
|
|
No. For example you can add or remove "Comment:" lines. They have
|
|
a purpose like the mail header lines. However a "Hash:" line is
|
|
needed for OpenPGP signatures to tell the parser which hash
|
|
algorithm to use.
|
|
|
|
<Q> What is the list of preferred algorithms?
|
|
|
|
The list of preferred algorithms is a list of cipher, hash and
|
|
compression algorithms stored in the self-signature of a key during
|
|
key generation. When you encrypt a document, GnuPG uses this list
|
|
(which is then part of a public key) to determine which algorithms
|
|
to use. Basically it tells other people what algorithms the
|
|
recipient is able to handle and provides an order of preference.
|
|
|
|
<Q> How do I change the list of preferred algorithms?
|
|
|
|
In version 1.0.7 or later, you can use the edit menu and set the
|
|
new list of preference using the command "setpref"; the format of
|
|
this command resembles the output of the command "pref". The
|
|
preference is not changed immediately but the set preference will
|
|
be used when a new user ID is created. If you want to update the
|
|
preferences for existing user IDs, select those user IDs (or select
|
|
none to update all) and enter the command "updpref". Note that the
|
|
timestamp of the self-signature is increased by one second when
|
|
running this command.
|
|
|
|
|
|
<S> ACKNOWLEDGEMENTS
|
|
|
|
Many thanks to Nils Ellmenreich for maintaining this FAQ file for
|
|
a long time, Werner Koch for the original FAQ file, and to all
|
|
posters to gnupg-users and gnupg-devel. They all provided most
|
|
of the answers.
|
|
|
|
Also thanks to Casper Dik for providing us with a script to generate
|
|
this FAQ (he uses it for the excellent Solaris2 FAQ).
|
|
|
|
[H HR]
|
|
|
|
Copyright (C) 2000-2002 Free Software Foundation, Inc.,
|
|
59 Temple Place - Suite 330, Boston, MA 02111, USA
|
|
|
|
Verbatim copying and distribution of this entire article is permitted in
|
|
any medium, provided this notice is preserved.
|