~ubuntu-branches/ubuntu/precise/gnupg2/precise-proposed

« back to all changes in this revision

Viewing changes to doc/faq.raw

  • Committer: Bazaar Package Importer
  • Author(s): Matthias Urlichs
  • Date: 2006-01-24 04:31:42 UTC
  • mfrom: (1.1.2 upstream)
  • Revision ID: james.westby@ubuntu.com-20060124043142-pbg192or6qxv3yk2
Tags: 1.9.20-1
* New Upstream version. Closes:#306890,#344530
  * Closes:#320490: gpg-protect-tool fails to decrypt PKCS-12 files 
* Depend on libopensc2-dev, not -1-. Closes:#348106

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
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.