* KEYSERVER: New. Documents the --with-colons format for keyserver
[gnupg.git] / doc / faq.raw
1 [$htmltitle=GnuPG FAQ]
2 [$sfaqheader=The GnuPG FAQ says:]
3 [$sfaqfooter=
4 The most recent version of the FAQ is available from
5 <http://www.gnupg.org/>
6 ]
7 [$usenetheader=
8 ]
9 [$maintainer=David D. Scribner, <faq 'at' gnupg.org>]
10 [$hGPG=http://www.gnupg.org]
11
12 [H body bgcolor=#ffffff text=#000000 link=#1f00ff alink=#ff0000 vlink=#9900dd]
13 [H H1]GnuPG Frequently Asked Questions[H /H1]
14
15
16 [H p]
17 Version: 1.5.7[H br]
18 Last-Modified: Aug 21, 2002[H br]
19 Maintained-by: [$maintainer]
20 [H /p]
21
22
23 This is the GnuPG FAQ. The latest HTML version is available
24 [H a href=[$hGPG]/faq.html]here[H/a].
25
26 The index is generated automatically, so there may be errors here. Not
27 all questions may be in the section they belong to. Suggestions about
28 how to improve the structure of this FAQ are welcome.
29
30 Please send additions and corrections to the maintainer. It would be
31 most convenient if you could provide the answer to be included here
32 as well. Your help is very much appreciated.
33
34 Please, don't send message like "This should be a FAQ - what's the answer?".
35 If it hasn't been asked before, it isn't a FAQ. In that case you could
36 search in the mailing list archive.
37
38 [H HR]
39 <C>
40 [H HR]
41
42
43 <S> GENERAL
44
45 <Q> What is GnuPG?
46
47     [H a href=[$hGPG]]GnuPG[H /a] stands for GNU Privacy Guard and
48     is GNU's tool for secure communication and data storage. It can be
49     used to encrypt data and to create digital signatures. It includes
50     an advanced key management facility and is compliant with the
51     proposed OpenPGP Internet standard as described in [H a href=http://www.gnupg.org/rfc2440.html]RFC 2440[H/a].
52     As such, it is aimed to be compatible with PGP from NAI, Inc.
53
54 <Q> Is GnuPG compatible with PGP?
55
56     In general, yes. GnuPG and newer PGP releases should be implementing
57     the OpenPGP standard. But there are some interoperability
58     problems. See question <Rcompat> for details.
59
60
61 <S> SOURCES of INFORMATION
62
63 <Q> Where can I find more information?
64
65     Here's a list of on-line resources:
66
67     [H UL] 
68     [H LI]The documentation page is located at [H a href=[$hGPG]/docs.html]<[$hGPG]/docs.html>[H/a].
69     Have a look at the HOWTOs and the GNU Privacy Handbook (GPH, available
70     in English, Spanish and Russian). The latter provides a detailed user's
71     guide to GnuPG. You'll also find a document about how to convert from
72     PGP 2.x to GnuPG.
73
74     [H LI]On [H a href=http://lists.gnupg.org]<http://lists.gnupg.org>[H/a] you'll find an online archive of the
75     GnuPG mailing lists. Most interesting should be gnupg-users for all
76     user-related issues and gnupg-devel if you want to get in touch with
77     the developers.
78
79     In addition, searchable archives can be found on MARC, e.g.: [H br]
80     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]
81     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]
82
83     [H B]PLEASE:[H/B]
84     Before posting to a list, read this FAQ and the available
85     documentation. In addition, search the list archive - maybe your
86     question has already been discussed. This way you help people focus
87     on topics that have not yet been resolved.
88
89     [H LI]The GnuPG source distribution contains a subdirectory:
90
91     [H PRE]
92      ./doc
93     [H /PRE]
94
95     where some additional documentation is located (mainly interesting
96     for hackers, not the casual user).
97     [H /UL]
98
99 <Q> Where do I get GnuPG?
100
101     You can download the GNU Privacy Guard from its primary FTP server
102     [H a href=ftp://ftp.gnupg.org/pub/gcrypt]ftp.gnupg.org[H /a] or from one of the mirrors:
103
104     [H a href=[$hGPG]/mirrors.html]
105      <[$hGPG]/mirror.html>
106     [H /a]
107
108     The current version is 1.0.4, please upgrade to this version as it
109     fixes a security bug regarding the verification of multiple signatures.
110
111
112 <S> INSTALLATION 
113
114 <Q> Which OSes does GnuPG run on?
115
116     It should run on most Unices as well as Windows 95 and Windows NT. A
117     list of OSes reported to be OK is presented at:
118
119     [H a href=http://www.gnupg.org/backend.html#supsys]
120      <http://www.gnupg.org/gnupg.html#supsys>
121     [H /a]
122
123 <Q> Which random gatherer should I use?
124
125     "Good" random numbers are crucial for the security of your encryption.
126     Different operating systems provide a variety of more or less quality
127     random data. Linux and *BSD provide kernel generated random data
128     through /dev/random - this should be the preferred choice on these
129     systems. Also Solaris users with the SUNWski package installed have
130     a /dev/random. In these cases, use the configure option:
131
132     [H pre]
133      --enable-static-rnd=linux
134     [H/pre]
135
136     In addition, there's also the kernel random device by Andi Maier
137     [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
138     own risk!
139
140     On other systems, the Entropy Gathering Daemon (EGD) is a good choice.
141     It is a perl-daemon that monitors system activity and hashes it into
142     random data. See the download page [H a href=http://www.gnupg.org/download.html]<http://www.gnupg.org/download.html>[H /a]
143     to obtain egd. Use:
144
145     [H pre]
146      --enable-static-rnd=egd
147     [H/pre]
148
149     here.
150
151     If the above options do not work, you can use the random number
152     generator "unix". This is [H B]very[H /B] slow and should be avoiced. The
153     random quality isn't very good so don't use it on sensitive data.
154
155 <Didea>
156 <Q> How do I include support for RSA and IDEA?
157
158     RSA is included as of GnuPG 1.0.3.
159
160     The official GnuPG distribution does not contain IDEA due to a
161     patent restriction. The patent does not expire before 2007 so don't
162     expect official support before then.
163
164     However, there is an unofficial module to include it even
165     in earlier versions of GnuPG. It's available from
166     [H a href=ftp://ftp.gnupg.org/pub/gcrypt/contrib/]<ftp://ftp.gnupg.org/pub/gcrypt/contrib/>[H /a]. Look for:
167
168     [H pre]
169      idea.c
170     [H /pre]
171
172     Compilation directives are in the headers of these files. Then add
173     the following line to your ~/.gnupg/options:
174
175     [H pre]
176      load-extension idea
177     [H /pre]
178
179
180 <S> USAGE
181
182 <Q> What is the recommended key size?
183
184     1024 bit for DSA signatures; even for plain ElGamal signatures
185     this is sufficient as the size of the hash is probably the weakest
186     link if the key size is larger than 1024 bits. Encryption keys may
187     have greater sizes, but you should then check the fingerprint of
188     this key:
189
190     [H pre]
191      gpg --fingerprint <user ID>
192     [H /pre]
193
194     As for the key algorithms, you should stick with the default (i.e.,
195     DSA signature and ElGamal encryption). A ElGamal signing key has the
196     following disadvantages: the signature is larger, it is hard to
197     create such a key useful for signatures which can withstand some
198     real world attacks, you don't get any extra security compared to
199     DSA, and there might be compatibility problems with certain PGP
200     versions. It has only been introduced because at the time it was
201     not clear whether there was a patent on DSA.
202
203 <Q> Why does it sometimes take so long to create keys?
204
205     The problem here is that we need a lot of random bytes and for that
206     we (on Linux the /dev/random device) must collect some random data.
207     It is really not easy to fill the Linux internal entropy buffer; I
208     talked to Ted Ts'o and he commented that the best way to fill the
209     buffer is to play with your keyboard. Good security has its price.
210     What I do is to hit several times on the shift, control, alternate,
211     and caps lock keys, because these keys do not produce output to the
212     screen. This way you get your keys really fast (it's the same thing
213     PGP2 does).
214
215     Another problem might be another program which eats up your random
216     bytes (a program (look at your daemons) that reads from /dev/random).
217
218 <Q> And it really takes long when I work on a remote system. Why?
219
220     Don't do this at all! You should never create keys or even use GnuPG
221     on a remote system because you normally have no physical control
222     over your secret key ring (which is in most cases vulnerable to
223     advanced dictionary attacks) - I strongly encourage everyone to only
224     create keys on a local computer (a disconnected laptop is probably
225     the best choice) and if you need it on your connected box (I know:
226     We all do this) be sure to have a strong password for your account
227     and for your secret key and that you can trust your system
228     administrator.
229
230     When I check GnuPG on a remote system via ssh (I have no Alpha here
231     ;-) I have the same problem. It takes a *very* long time to create
232     the keys, so I use a special option, --quick-random, to generate
233     insecure keys which are only good for some tests.
234
235 <Q> What is the difference between options and commands?
236
237     If you do a 'gpg --help', you will get two separate lists. The first
238     is a list of commands. The second is a list of options. Whenever you
239     run GPG, you [H B]must[H /B] pick exactly one command (with one exception,
240     see below). You [H B]may[H /B] pick one or more options. The command should,
241     just by convention, come at the end of the argument list, after all
242     the options. If the command takes a file (all the basic ones do),
243     the filename comes at the very end. So the basic way to run gpg is:
244
245     [H pre]
246      gpg [--option something] [--option2] [--option3 something] --command file
247     [H/pre]
248
249     Some options take arguments. For example, the --output option (which
250     can be abbreviated -o) is an option that takes a filename. The
251     option's argument must follow immediately after the option itself,
252     otherwise gpg doesn't know which option the argument is supposed to
253     go with. As an option, --output and its filename must come before
254     the command. The --recipient (-r) option takes a name or keyid to
255     encrypt the message to, which must come right after the -r argument.
256     The --encrypt (or -e) command comes after all the options followed
257     by the file you wish to encrypt. So use:
258
259     [H pre]
260      gpg -r alice -o secret.txt -e test.txt
261     [H/pre]
262
263     If you write the options out in full, it is easier to read:
264
265     [H pre]
266      gpg --recipient alice --output secret.txt --encrypt test.txt
267     [H/pre]
268
269     If you're saving it in a file called ".txt" then you'd probably
270     expect to see ASCII-armored text in there, so you need to add the
271     --armor (-a) option, which doesn't take any arguments:
272
273     [H pre]
274      gpg --armor --recipient alice --output secret.txt --encrypt test.txt
275     [H/pre]
276
277     If you imagine square brackets around the optional parts, it becomes
278     a bit clearer:
279
280     [H pre]
281      gpg [--armor] [--recipient alice] [--output secret.txt] --encrypt test.txt
282     [H/pre]
283
284     The optional parts can be rearranged any way you want:
285
286     [H pre]
287      gpg --output secret.txt --recipient alice --armor --encrypt test.txt
288     [H/pre]
289
290     If your filename begins with a hyphen (e.g. "-a.txt"), GnuPG assumes
291     this is an option and may complain. To avoid this you have either
292     to use "./-a.txt" or stop the option and command processing with two
293     hyphens: "-- -a.txt". [H B]The exception:[H /B] signing and encrypting at the
294     same time. Use:
295
296     [H pre]
297      gpg [--options] --sign --encrypt foo.txt
298     [H/pre]
299
300 <Q> I can't delete a user ID because it is already deleted on my public
301     keyring?
302
303     Because you can only select from the public key ring, there is no
304     direct way to do this. However it is not very complicated to do
305     anyway. Create a new user ID with exactly the same name and you
306     will see that there are now two identical user IDs on the secret
307     ring. Now select this user ID and delete it. Both user IDs will be
308     removed from the secret ring.
309
310 <Q> I can't delete the secret key because my public key disappeared?
311
312     To select a key a search is always done on the public keyring,
313     therefore it is not possible to select an secret key without
314     having the public key. Normally it shoud never happen that the
315     public key got lost but the secret key is still available. The
316     reality is different, so GnuPG implements a special way to deal
317     with it: Simply use the long keyid which can be obtained by using
318     the --with-colons options (it is the fifth field in the lines
319     beginning with "sec").
320
321 <Q> What are trust, validity and ownertrust?
322
323     "ownertrust" is used instead of "trust" to make clear that this is
324     the value you have assigned to a key to express how much you trust
325     the owner of this key to correctly sign (and so introduce) other
326     keys. "validity", or calculated trust, is a value which says how
327     much GnuPG thinks a key is valid (that it really belongs to the one
328     who claims to be the owner of the key).  For more see the chapter
329     "The Web of Trust" in the Manual.
330
331 <Q> How do I sign a patch file?
332
333     Use "gpg --clearsign --not-dash-escaped ...". The problem with
334     --clearsign is that all lines starting with a dash are quoted with
335     "- "; obviously diff produces many lines starting with a dash and
336     these are then quoted and that is not good for a patch ;-). To use a
337     patch file without removing the cleartext signature, the special
338     option --not-dash-escaped may be used to suppress generation of
339     these escape sequences. You should not mail such a patch because
340     spaces and line endings are also subject to the signature and a
341     mailer may not preserve these. If you want to mail a file you can
342     simply sign it using your MUA.
343
344 <Q> Where is the "encrypt-to-self" option?
345
346     Use "--encrypt-to your_keyid". You can use more than one of these
347     options. To temporarily override the use of this additional key,
348     you can use the option "--no-encrypt-to".
349
350 <Q> How can I get rid of the Version and Comment headers in armored
351     messages?
352
353     Use "--no-version --comment ''". Note that the left over blank line
354     is required by the protocol.
355
356 <Q> What does the "You are using the xxxx character set." mean?
357
358     This note is printed when UTF8 mapping has to be done. Make sure
359     that the displayed charset is the one you have activated on your
360     system. Since "iso-8859-1" is the charset most used, this is the
361     default. You can change the charset with the option "--charset".
362     It is important that your active character set matches the one
363     displayed - if not, restrict yourself to plain 7 bit ASCII and no
364     mapping has to be done.
365
366 <Q> How can a get list of key IDs used to encrypt a message?
367
368     [H pre]
369      gpg --batch --decrypt --list-only --status-fd 1 2>/dev/null | \
370      awk '/^\[GNUPG:\] ENC_TO / { print $3 }'
371     [H /pre]
372
373 <Q> I can't decrypt my symmetrical only (-c) encrypted message with
374     a new version of GnuPG.
375
376     There used to be a bug in GnuPG < 1.0.1 which happens only if 3DES
377     or Twofish has been used for symmetric only encryption (this has
378     never been the default). The bug has been fixed but to enable you
379     to decrypt old messages, you should run gpg with the option
380     "--emulate-3des-s2k-bug", decrypt the message and encrypt it again
381     without this option. The option will be removed in 1.1, so better
382     re-encrypt your message now.
383
384 <Q> How can I use GnuPG in an automated environment?
385
386     You should use the option --batch and don't use pass phrases as
387     there is usually no way to store it more secure than the secret
388     keyring itself. The suggested way to create the keys for the
389     automated environment is:
390
391     On a secure machine:
392     [H OL]
393     [H LI] If you want to do automatic signing, create a signing
394            subkey for your key (edit menu, choose "addkey" and the DSA).
395     [H LI] Make sure that you use a passphrase (needed by the current
396            implementation).
397     [H LI] gpg --export-secret-subkeys --no-comment foo >secring.auto
398     [H LI] Copy secring.auto and the public keyring to a test directory.
399     [H LI] Change to this directory.
400     [H LI] gpg --homedir . --edit foo and use "passwd" to remove the
401            passphrase from the subkeys.  You may also want to remove all
402            unused subkeys.
403     [H LI] Copy secring.auto to a floppy and carry it to the target box.
404     [H /OL]
405
406     On the target machine:
407     [H OL]
408     [H LI] Install secring.auto as secret keyring.
409     [H LI] Now you can start your new service. It is a good idea to
410            install some intrusion detection system so that you hopefully
411            get a notice of an successful intrusion, so that you in turn
412            can revoke all the subkeys installed on that machine and
413            install new subkeys.
414     [H /OL]
415
416 <Q> Which email-client can I use with GnuPG?
417
418     Using GnuPG to encrypt email is one of the most popular uses.
419     Several mail clients or mail user-agents (MUA) support GnuPG at
420     varying degrees. Simplifying a bit, there are two ways mail can be
421     encrypted with GnuPG: the "old style" ASCII armor, i.e. plain text
422     encryption, and RFC2015 style (previously PGP/MIME, now OpenPGP).
423     The latter has full MIME support. Some MUAs support only one of
424     them, so whichever you actually use depends on your needs as well
425     as the capabilities of your addressee.
426
427     The following list is probably not exhaustive:
428
429     OpenPGP: Mutt (Unix), Emacs/Mew, Becky2 (Windows, with plugin),
430              TkRat (Unix). There is effort for a Mozilla plugin and
431              Emacs/GNUS has support in the current CVS.
432
433     ASCII:   Emacs/{VM,GNUS}/MailCrypt, Mutt(Unix), Pine(Unix), and
434              probably many more.
435
436     Good overviews of OpenPGP-support can be found at 
437     [H a href=http://cryptorights.org/pgp-users/pgp-mail-clients.html]http://cryptorights.org/pgp-users/pgp-mail-clients.html[H /a]
438     and [H a href=http://www.geocities.com/openpgp/courrier_en.html]http://www.geocities.com/openpgp/courrier_en.html[H /a].
439
440 <Q> Can't we have a gpg library?
441
442     This has been frequently requested. However, the current viewpoint
443     of the GnuPG maintainers is that this would lead to several security
444     issues and will therefore not be implemented in the foreseeable
445     future. However, for some areas of application gpgme could do the
446     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].
447
448 <Q> I have successfully generated a revocation certificate, but I don't
449     understand how to send it to the key servers.
450
451     Most keyservers don't accept a 'bare' revocation certificate. You
452     have to import the certificate into gpg first:
453
454     [H pre]
455      gpg --import my-revocation.asc
456     [H /pre]
457
458     then send the revoked key to the keyservers:
459
460     [H pre]
461      gpg --keyserver certserver.pgp.com --send-keys mykeyid
462     [H /pre]
463
464     (or use a keyserver web interface for this).
465
466 <Q> How do I put my keyring in a different directory?
467
468     GnuPG keeps several files in a special homedir directory. These
469     include the options file, pubring.gpg, secring.gpg, trustdb.gpg,
470     and others. GnuPG will always create and use these files. On unices,
471     the homedir is usually ~/.gnupg; on Windows "C:\gnupg\".
472
473     If you want to put your keyrings somewhere else, use:
474
475     [H pre]
476      --homedir /my/path/
477     [H /pre]
478
479     to make GnuPG create all its files in that directory. Your keyring
480     will be "/my/path/pubring.gpg". This way you can store your secrets
481     on a floppy disk. Don't use "--keyring" as its purpose is to specify
482     additional keyring files.
483
484
485 <S> COMPATIBILITY ISSUES
486
487 <Dcompat>
488 <Q> How can I encrypt a message with GnuPG so that PGP is able to decrypt it?
489
490     It depends on the PGP version.
491
492     [H UL]
493     [H LI]PGP 2.x[H br]
494     You can't do that because PGP 2.x normally uses IDEA which is not
495     supported by GnuPG as it is patented (see <Ridea>), but if you have a
496     modified version of PGP you can try this:
497
498     [H pre]
499      gpg --rfc1991 --cipher-algo 3des ...
500     [H/pre]
501
502     Please don't pipe the data to encrypt to gpg but provide it using a
503     filename; otherwise, PGP 2 will not be able to handle it.
504
505     As for conventional encryption, you can't do this for PGP 2.
506
507     [H LI]PGP 5.x and higher[H br]
508     You need to provide two additional options:
509
510     [H pre]
511      --compress-algo 1 --cipher-algo cast5
512     [H/pre]
513
514     You may also use "3des" instead of "cast5", and "blowfish" does not
515     work with all versions of PGP 5. You may also want to put:
516
517     [H pre]
518      compress-algo 1
519     [H/pre]
520
521     into your ~/.gnupg/options file - this does not affect normal GnuPG
522     operation.
523
524     This applies to conventional encryption as well.
525     [H /UL]
526
527 <Q> How do I migrate from PGP 2.x to GnuPG?
528
529     PGP 2 uses the RSA and IDEA encryption algorithms. Whereas the RSA
530     patent has expired and RSA is included as of GnuPG 1.0.3, the IDEA
531     algorithm is still patented until 2007. Under certain conditions you
532     may use IDEA even today. In that case, you may refer to Question
533     <Ridea> about how to add IDEA support to GnuPG and read
534     [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.
535
536 <Q> (removed)
537
538     (empty)
539
540 <Q> Why is PGP 5.x not able to encrypt messages with some keys?
541
542     PGP, Inc. refuses to accept ElGamal keys of type 20 even for
543     encryption. They only support type 16 (which is identical at least
544     for decryption). To be more inter-operable, GnuPG (starting with
545     version 0.3.3) now also uses type 16 for the ElGamal subkey which is
546     created if the default key algorithm is chosen. You may add a type
547     16 ElGamal key to your public key, which is easy as your key
548     signatures are still valid.
549
550 <Q> Why is PGP 5.x not able to verify my messages?
551
552     PGP 5.x does not accept v4 signatures for data material but OpenPGP
553     requests generation of v4 signatures for all kind of data, that's why
554     GnuPG defaults to them. Use the option "--force-v3-sigs" to generate
555     v3 signatures for data.
556
557 <Q> How do I transfer owner trust values from PGP to GnuPG?
558
559     There is a script in the tools directory to help you. After you have
560     imported the PGP keyring you can give this command:
561
562     [H pre]
563      $ lspgpot pgpkeyring | gpg --import-ownertrust
564     [H /pre]
565
566     where pgpkeyring is the original keyring and not the GnuPG keyring
567     you might have created in the first step.
568
569 <Q> PGP does not like my secret key.
570
571     Older PGPs probably bail out on some private comment packets used by
572     GnuPG. These packets are fully in compliance with OpenPGP; however
573     PGP is not really OpenPGP aware. A workaround is to export the
574     secret keys with this command:
575
576     [H pre]
577      $ gpg --export-secret-keys --no-comment -a your-key-id
578     [H /pre]
579
580     Another possibility is this: by default, GnuPG encrypts your secret
581     key using the Blowfish symmetric algorithm. Older PGPs will only
582     understand 3DES, CAST5, or IDEA symmetric algorithms. Using the
583     following method you can re-encrypt your secret gpg key with a
584     different algo:
585
586     [H pre]
587      $ gpg --s2k-cipher-algo=CAST5 --s2k-digest-algo=SHA1 \
588            --compress-algo=1  --edit-key <username>
589     [H /pre]
590
591     Then use passwd to change the password (just change it to the same
592     thing, but it will encrypt the key with CAST5 this time).
593
594     Now you can export it and PGP should be able to handle it.
595
596     For PGP 6.x the following options work to export a key:
597
598     [H pre]
599      $ gpg --s2k-cipher-algo 3des --compress-algo 1 --rfc1991 \
600            --export-secret-keys <key-ID>
601     [H /pre]
602
603
604 <S> PROBLEMS and ERROR MESSAGES
605
606 <Q> Why do I get "gpg: Warning: using insecure memory!"
607
608     On many systems this program should be installed as setuid(root).
609     This is necessary to lock memory pages. Locking memory pages prevents
610     the operating system from writing them to disk and thereby keeping your
611     secret keys really secret. If you get no warning message about insecure
612     memory your operating system supports locking without being root. The
613     program drops root privileges as soon as locked memory is allocated.
614
615     On UnixWare 2.x and 7.x you should install GnuPG with the 'plock'
616     privilege to get the same effect:
617
618     [H pre]
619      filepriv -f plock /path/to/gpg
620     [H /pre]
621
622     If you can't or don't want to install GnuPG setuid(root), you can
623     use the option "--no-secmem-warning" or put:
624
625     [H pre]
626      no-secmem-warning
627     [H /pre]
628
629     in your ~/.gnupg/options file (this disables the warning).
630
631     On some systems (e.g., Windows) GnuPG does not lock memory pages
632     and older GnuPG versions (<=1.0.4) issue the warning:
633
634     [H pre]
635      gpg: Please note that you don't have secure memory
636     [H /pre]
637
638     This warning can't be switched off by the above option because it
639     was thought to be too serious an issue. However, it confused users
640     too much, so the warning was eventually removed.
641
642 <Q> Large File Support doesn't work ...
643
644     LFS is correctly working in post-1.0.4 CVS. If configure doesn't
645     detect it correctly, try a different (i.e., better) compiler. egcs
646     1.1.2 works fine, other gccs sometimes don't. BTW, several
647     compilation problems of GnuPG 1.0.3 and 1.0.4 on HP-UX and Solaris
648     were due to broken LFS support.
649
650 <Q> In the edit menu the trust values is not displayed correctly after
651     signing uids - why?
652
653     This happens because some information is stored immediately in
654     the trustdb, but the actual trust calculation can be done after the
655     save command. This is a "not easy to fix" design bug which will be
656     addressed in some future release.
657
658 <Q> What does "skipping pubkey 1: already loaded" mean?
659
660     As of GnuPG 1.0.3, the RSA algorithm is included. If you still have
661     a "load-extension rsa" in your options file, the above message
662     occurs. Just remove the load command from the options file.
663
664 <Q> GnuPG 1.0.4 doesn't create ~/.gnupg ...
665
666     That's a known bug, already fixed in newer versions.
667
668 <Q> An ElGamal signature does not verify anymore since version 1.0.2 ...
669
670     Use the option --emulate-md-encode-bug.
671
672 <Q> Old versions of GnuPG can't verify ElGamal signatures
673
674     Update to GnuPG 1.0.2 or newer.
675
676 <Q> When I use --clearsign, the plain text has sometimes extra dashes
677     in it - why?
678
679     This is called dash-escaped text and is required by OpenPGP.
680     It always happens when a line starts with a dash ("-") and is
681     needed to make the lines that structure signature and text
682     (i.e., "-----BEGIN PGP SIGNATURE-----") to be the only lines
683     that start with two dashes.
684
685     If you use GnuPG to process those messages, the extra dashes
686     are removed. Good mail clients remove those extra dashes when
687     displaying such a message.      
688
689 <Q> What is the thing with "can't handle multiple signatures"?
690
691     Due to different message formats GnuPG is not always able to split
692     a file with multiple signatures unambiguously into its parts. This
693     error message informs you that there is something wrong with the input.
694
695     The only way to have multiple signatures in a file is by using the
696     OpenPGP format with one-pass-signature packets (which is GnuPG's
697     default) or the cleartext signed format.
698
699 <Q> If I submit a key to a keyserver, nothing happens ...
700
701     You are most likely using GnuPG 1.0.2 or older on Windows. That's
702     feature isn't yet implemented, but it's a bug not to say it. Newer
703     versions issue a warning. Upgrade to 1.0.4 or newer.
704
705 <Q> I get "gpg: waiting for lock ..."
706
707     A previous gpg has most likely exited abnormally and left a lock
708     file. Go to ~/.gnupg and look for .*.lock files and remove them.
709
710 <Q> Older gpg's (e.g., 1.0) have problems with keys from newer gpgs ...
711
712     As of 1.0.3, keys generated with gpg are created with preferences to
713     TWOFISH (and AES since 1.0.4) and that also means that they have the
714     capability to use the new MDC encryption method. This will go into
715     OpenPGP soon and is also suppoted by PGP 7. This new method avoids
716     a (not so new) attack on all email encryption systems.
717
718     This in turn means that pre-1.0.3 gpg's have problems with newer
719     keys. Because of security fixes, you should keep your GnuPG
720     installation in a recent state anyway. As a workaround, you can
721     force gpg to use a previous default cipher algo by putting:
722
723     [H pre]
724      cipher-algo cast5
725     [H /pre]
726
727     into your options file.
728
729 <Q> With 1.0.4, I get "this cipher algorithm is deprecated ..."
730
731     If you just generated a new key and get this message while
732     encrypting, you've witnessed a bug in 1.0.4. It uses the new AES
733     cipher Rijndael that is incorrectly being referred as "deprecated".
734     Ignore this warning, more recent versions of gpg are corrected.
735
736 <Q> Some dates are displayed as ????-??-??, why?
737
738     Due to constraints in most libc implementations, dates beyond
739     2038-01-19 can't be displayed correctly. 64 bit OSes are not
740     affected by this problem. To avoid printing wrong dates, GnuPG
741     instead prints some question marks. To see the correct value, you
742     can use the options --with-colons and --fixed-list-mode.
743
744 <Q> I still have a problem. How do I report a bug?
745
746     Are you sure that it's not been mentioned somewhere on the mailing
747     lists? Did you have a look at the bug list (you'll find a link to
748     the list of reported bugs on the documentation page). If you're not
749     sure about it being a bug, you can send mail to the gnupg-devel
750     list. Otherwise, use the GUUG bug tracking system 
751     [H a href=http://bugs.guug.de/Reporting.html]http://bugs.guug.de/Reporting.html[H /a].
752
753 <Q> Why doesn't GnuPG support X509 certificates?
754
755     GnuPG, first and foremost, is an implementation of the OpenPGP
756     standard (RFC 2440), which is a competing infrastructure, different
757     from X509.
758
759     They are both public-key cryptosystems, but how the public keys are
760     actually handled is different.
761
762 <Q> Why do national characters in my user ID look funny?
763
764     According to OpenPGP, GnuPG encodes user ID strings (and other
765     things) using UTF-8. In this encoding of Unicode, most national
766     characters get encoded as two- or three-byte sequences. For
767     example, &aring; (0xE5 in ISO-8859-1) becomes &Atilde;&yen; (0xC3,
768     0xA5). This might also be the reason why keyservers can't find
769     your key.
770
771 <Q> I get 'sed' errors when running ./configure on Mac OS X ...
772
773     This will be fixed after GnuPG has been upgraded to autoconf-2.50.
774     Until then, find the line setting CDPATH in the configure script
775     and place a:
776
777     [H pre]
778      unset CDPATH
779     [H /pre]
780
781     statement below it.
782
783 <Q> Why does GnuPG 1.0.6 bail out on keyrings used with 1.0.7?
784
785     There is a small bug in 1.0.6 which didn't parse trust packets
786     correctly. You may want to apply this patch if you can't upgrade:
787
788     [H pre]
789      http://www.gnupg.org/developer/gpg-woody-fix.txt
790     [H /pre]
791
792
793 <S> ADVANCED TOPICS
794
795 <Q> How does this whole thing work?
796
797     To generate a secret/public keypair, run:
798
799     [H pre]
800      gpg --gen-key
801     [H/pre]
802
803     and choose the default values.
804
805     Data that is encrypted with a public key can only be decrypted by
806     the matching secret key. The secret key is protected by a password,
807     the public key is not.
808
809     So to send your friend a message, you would encrypt your message
810     with his public key, and he would only be able to decrypt it by
811     having the secret key and putting in the password to use his secret
812     key.
813
814     GnuPG is also useful for signing things. Things that are encrypted
815     with the secret key can be decrypted with the public key. To sign
816     something, a hash is taken of the data, and then the hash is in some
817     form encoded with the secret key. If someone has your public key, they
818     can verify that it is from you and that it hasn't changed by checking
819     the encoded form of the hash with the public key.
820
821     A keyring is just a large file that stores keys. You have a public
822     keyring where you store yours and your friend's public keys. You have
823     a secret keyring that you keep your secret key on, and should be very
824     careful with. Never ever give anyone else access to it and use a *good*
825     passphrase to protect the data in it.
826
827     You can 'conventionally' encrypt something by using the option 'gpg -c'.
828     It is encrypted using a passphrase, and does not use public and secret
829     keys. If the person you send the data to knows that passphrase, they
830     can decrypt it. This is usually most useful for encrypting things to
831     yourself, although you can encrypt things to your own public key in the
832     same way. It should be used for communication with partners you know
833     and where it is easy to exchange the passphrases (e.g. with your boy
834     friend or your wife). The advantage is that you can change the
835     passphrase from time to time and decrease the risk, that many old
836     messages may be decrypted by people who accidently got your passphrase.
837
838     You can add and copy keys to and from your keyring with the 'gpg
839     --import' and 'gpg --export' option. 'gpg --export-secret-keys' will
840     export secret keys. This is normally not useful, but you can generate
841     the key on one machine then move it to another machine.
842
843     Keys can be signed under the 'gpg --edit-key' option. When you sign a
844     key, you are saying that you are certain that the key belongs to the
845     person it says it comes from. You should be very sure that is really
846     that person: You should verify the key fingerprint with:
847
848     [H pre]
849      gpg --fingerprint user-id
850     [H/pre]
851
852     over the phone (if you really know the voice of the other person), at a
853     key signing party (which are often held at computer conferences), or at
854     a meeting of your local GNU/Linux User Group.
855
856     Hmm, what else. You may use the option "-o filename" to force output
857     to this filename (use "-" to force output to stdout). "-r" just lets
858     you specify the recipient (which public key you encrypt with) on the
859     command line instead of typing it interactively.
860
861     Oh yeah, this is important. By default all data is encrypted in some
862     weird binary format. If you want to have things appear in ASCII text
863     that is readable, just add the '-a' option. But the preferred method
864     is to use a MIME aware mail reader (Mutt, Pine and many more).
865
866     There is a small security glitch in the OpenPGP (and therefore GnuPG)
867     system; to avoid this you should always sign and encrypt a message
868     instead of only encrypting it.
869
870 <Q> Why are some signatures with an ELG-E key valid?
871
872     These are ElGamal keys generated by GnuPG in v3 (RFC 1991) packets.
873     The OpenPGP draft later changed the algorithm identifier for ElGamal
874     keys which are usable for signatures and encryption from 16 to 20.
875     GnuPG now uses 20 when it generates new ElGamal keys but still
876     accepts 16 (which is according to OpenPGP "encryption only") if this
877     key is in a v3 packet. GnuPG is the only program which had used
878     these v3 ElGamal keys - so this assumption is quite safe.
879
880 <Q> How does the whole trust thing work?
881
882     It works more or less like PGP. The difference is that the trust is
883     computed at the time it is needed. This is one of the reasons for
884     the trustdb which holds a list of valid key signatures. If you are
885     not running in batch mode you will be asked to assign a trust
886     parameter (ownertrust) to a key.
887
888     You can see the validity (calculated trust value) using this
889     command.
890
891     [H pre]
892      gpg --list-keys --with-colons
893     [H/pre] 
894
895     If the first field is "pub" or "uid", the second field shows you the
896     trust:
897
898     [H pre]
899      o = Unknown (this key is new to the system)
900      e = The key has expired
901      q = Undefined (no value assigned)
902      n = Don't trust this key at all
903      m = There is marginal trust in this key
904      f = The key is full trusted
905      u = The key is ultimately trusted; this is only used
906          for keys for which the secret key is also available.
907      r = The key has been revoked
908      d = The key has been disabled
909     [H/pre]
910
911     The value in the "pub" record is the best one of all "uid" records.
912     You can get a list of the assigned trust values (how much you trust
913     the owner to correctly sign another person's key) with:
914
915     [H pre]
916      gpg --list-ownertrust
917     [H/pre]
918
919     The first field is the fingerprint of the primary key, the second
920     field is the assigned value:
921
922     [H pre]
923      - = No Ownertrust value yet assigned.
924      n = Never trust this keyholder to correctly verify others signatures.
925      m = Have marginal trust in the keyholders capability to sign other
926          keys.
927      f = Assume that the key holder really knows how to sign keys.
928      u = No need to trust ourself because we have the secret key.
929     [H/pre]
930
931     Keep these values confidential because they express your opinions
932     about others. PGP stores this information with the keyring thus it
933     is not a good idea to publish a PGP keyring instead of exporting the
934     keyring. GnuPG stores the trust in the trustdb.gpg file so it is okay
935     to give a gpg keyring away (but we have a --export command too).
936
937 <Q> What kind of output is this: "key C26EE891.298, uid 09FB: ...."?
938
939     This is the internal representation of a user ID in the trustdb.
940     "C26EE891" is the keyid, "298" is the local ID (a record number in
941     the trustdb) and "09FB" is the last two bytes of a ripe-md-160 hash
942     of the user ID for this key.
943
944 <Q> How do I interpret some of the informational outputs?
945
946     While checking the validity of a key, GnuPG sometimes prints some
947     information which is prefixed with information about the checked
948     item.
949
950     [H pre]
951      "key 12345678.3456"
952     [H/pre]
953
954     This is about the key with key ID 12345678 and the internal number
955     3456, which is the record number of the so called directory record
956     in the trustdb.
957
958     [H pre]
959      "uid 12345678.3456/ACDE"
960     [H/pre]
961
962     This is about the user ID for the same key. To identify the user ID
963     the last two bytes of a ripe-md-160 over the user ID ring is printed.
964
965     [H pre]
966      "sig 12345678.3456/ACDE/9A8B7C6D"
967     [H/pre]
968
969     This is about the signature with key ID 9A8B7C6D for the above key
970     and user ID, if it is a signature which is direct on a key, the user
971     ID part is empty (..//..).
972
973 <Q> Are the header lines of a cleartext signature part of the signed
974     material?
975
976     No. For example you can add or remove "Comment:" lines. They have
977     a purpose like the mail header lines. However a "Hash:" line is
978     needed for OpenPGP signatures to tell the parser which hash
979     algorithm to use.
980
981 <Q> What is the list of preferred algorithms?
982
983     The list of preferred algorithms is a list of cipher, hash and
984     compression algorithms stored in the self-signature of a key during
985     key generation. When you encrypt a document, GnuPG uses this list
986     (which is then part of a public key) to determine which algorithms
987     to use. Basically it tells other people what algorithms the
988     recipient is able to handle and provides an order of preference.
989
990 <Q> How do I change the list of preferred algorithms?
991
992     In version 1.0.7 or later, you can use the edit menu and set the
993     new list of preference using the command "setpref"; the format of
994     this command resembles the output of the command "pref". The
995     preference is not changed immediately but the set preference will
996     be used when a new user ID is created. If you want to update the
997     preferences for existing user IDs, select those user IDs (or select
998     none to update all) and enter the command "updpref". Note that the
999     timestamp of the self-signature is increased by one second when
1000     running this command.
1001
1002
1003 <S> ACKNOWLEDGEMENTS
1004
1005     Many thanks to Nils Ellmenreich for maintaining this FAQ file for
1006     a long time, Werner Koch for the original FAQ file, and to all
1007     posters to gnupg-users and gnupg-devel. They all provided most
1008     of the answers.
1009
1010     Also thanks to Casper Dik for providing us with a script to generate
1011     this FAQ (he uses it for the excellent Solaris2 FAQ).
1012
1013 [H HR]
1014
1015 Copyright (C) 2000-2002 Free Software Foundation, Inc.,
1016 59 Temple Place - Suite 330, Boston, MA 02111, USA
1017
1018 Verbatim copying and distribution of this entire article is permitted in
1019 any medium, provided this notice is preserved.