diff options
Diffstat (limited to 'doc/faq.raw')
| -rw-r--r-- | doc/faq.raw | 932 |
1 files changed, 932 insertions, 0 deletions
diff --git a/doc/faq.raw b/doc/faq.raw new file mode 100644 index 000000000..eac856bd3 --- /dev/null +++ b/doc/faq.raw @@ -0,0 +1,932 @@ +[$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=Douglas Calvert, <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] + + +Version: 1.5.6[H p] +Last-Modified: Sep 14, 2001[H p] +Maintained-by: [$maintainer] + + +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. 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 questions <Rcompat>ff. 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] [H a href=[$hGPG]/docs.html]<[$hGPG]/docs.html>[H/a] is the + documentation page. 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.: + 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], + 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 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 + 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] + how 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 + avoided. 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 version 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: + "gpg --fingerprint <user ID>". + + 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, 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/[u]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 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. + +<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 we GnuPG implements a special way to do + deal with it: Simply use the long keyid which you can figure out + 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 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 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 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? + + 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 "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 you 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] Cd to this directory. [H LI] gpg --homedir + . --edit foo and use "passwd" to remove the pass-phrase 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 a 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 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, the trustdb, 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 + + 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 + + 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", "blowfish" does not + work with all versions of pgp5. 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 an 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 one 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 a too serious 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 the some informations are 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 files, 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 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 on Windows 1.0.2 or older. 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 + key. Because of security fixes, you should keep your gpg + 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 + currectly. You may want to apply this patch if you can't upgrade: + http://www.gnupg.org/developer/gpg-woody-fix.txt + + + +<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 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 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 + [H pre] + gpg --fingerprint user-id + [H/pre] + 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 + 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 Key generated by GnuPG in v3 (rfc1991) 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 + accept 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) + + [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 trust-DB 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? + + 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 are not changes 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-signatures is increaded by one second when running this + command. + + +<S> ACKNOWLEDGEMENTS + + Many thanks to Nils Ellmenreich for maintaining this FAQ file for + a long time and to all posters to gnupg-users and gnupg-devel. They + all provided most of the answers. + + Also thanks to Casper Dik for providing me 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. |