mirror of
git://git.gnupg.org/gnupg.git
synced 2024-09-21 15:01:41 +02:00
See ChangeLog: Thu Sep 14 14:20:38 CEST 2000 Werner Koch
This commit is contained in:
Werner Koch
parent
8f6b40ff1c
commit
0b9d3e2f81
@ -1,3 +1,10 @@
|
|||||||
|
Thu Sep 14 14:20:38 CEST 2000 Werner Koch <wk@openit.de>
|
||||||
|
|
||||||
|
* acinclude.m4 (GNUPG_CHECK_FAQPROG): New.
|
||||||
|
* configure.in: Test for this.
|
||||||
|
|
||||||
|
* configure.in (DYNLINK_MOD_CFLAGS): Fix by David Champion.
|
||||||
|
|
||||||
Wed Sep 6 17:55:47 CEST 2000 Werner Koch <wk@openit.de>
|
Wed Sep 6 17:55:47 CEST 2000 Werner Koch <wk@openit.de>
|
||||||
|
|
||||||
* configure.in: Check for fstat64 and fopen64
|
* configure.in: Check for fstat64 and fopen64
|
||||||
|
|||||||
5
NEWS
5
NEWS
@ -20,6 +20,11 @@ Noteworthy changes in the current CVS branch STABLE-BRANCH-1-0
|
|||||||
* RSA is supported. Key generation does not yet work but will come
|
* RSA is supported. Key generation does not yet work but will come
|
||||||
soon.
|
soon.
|
||||||
|
|
||||||
|
* CAST5 and SHA-1 are now the default algorithms to protect the key
|
||||||
|
and for symmetric-only encryption. This should solve a couple
|
||||||
|
of compatibility problems because the old algorithms are optional
|
||||||
|
according to RFC2440
|
||||||
|
|
||||||
|
|
||||||
Noteworthy changes in version 1.0.2 (2000-07-12)
|
Noteworthy changes in version 1.0.2 (2000-07-12)
|
||||||
----------------------------------------------
|
----------------------------------------------
|
||||||
|
|||||||
4
THANKS
4
THANKS
@ -26,11 +26,12 @@ Christian Recktenwald chris@citecs.de
|
|||||||
Daniel Eisenbud eisenbud@cs.swarthmore.edu
|
Daniel Eisenbud eisenbud@cs.swarthmore.edu
|
||||||
Daniel Koening dan@mail.isis.de
|
Daniel Koening dan@mail.isis.de
|
||||||
Daniel Resare daniel@resare.com
|
Daniel Resare daniel@resare.com
|
||||||
Detlef Lannert lannert@lannert.rz.uni-duesseldorf.de
|
|
||||||
Dave Dykstra dwd@bell-labs.com
|
Dave Dykstra dwd@bell-labs.com
|
||||||
|
David Champion dgc@uchicago.edu
|
||||||
David Ellement ellement@sdd.hp.com
|
David Ellement ellement@sdd.hp.com
|
||||||
David Hallinan hallinan@rtd.com
|
David Hallinan hallinan@rtd.com
|
||||||
David Mathog MATHOG@seqaxp.bio.caltech.edu
|
David Mathog MATHOG@seqaxp.bio.caltech.edu
|
||||||
|
Detlef Lannert lannert@lannert.rz.uni-duesseldorf.de
|
||||||
Dimitri dmitri@advantrix.com
|
Dimitri dmitri@advantrix.com
|
||||||
Dirk Lattermann dlatt@t-online.de
|
Dirk Lattermann dlatt@t-online.de
|
||||||
Ed Boraas ecxjo@esperanto.org
|
Ed Boraas ecxjo@esperanto.org
|
||||||
@ -67,6 +68,7 @@ Jeff Long long@kestrel.cc.ukans.edu
|
|||||||
Jens Bachem bachem@rrz.uni-koeln.de
|
Jens Bachem bachem@rrz.uni-koeln.de
|
||||||
Jeroen C. van Gelderen jeroen@vangelderen.org
|
Jeroen C. van Gelderen jeroen@vangelderen.org
|
||||||
J Horacio MG homega@ciberia.es
|
J Horacio MG homega@ciberia.es
|
||||||
|
J. Michael Ashley jashley@acm.org
|
||||||
Joachim Backes backes@rhrk.uni-kl.de
|
Joachim Backes backes@rhrk.uni-kl.de
|
||||||
John A. Martin jam@jamux.com
|
John A. Martin jam@jamux.com
|
||||||
Johnny Teveßen j.tevessen@gmx.de
|
Johnny Teveßen j.tevessen@gmx.de
|
||||||
|
|||||||
8
TODO
8
TODO
@ -1,10 +1,11 @@
|
|||||||
|
|
||||||
* Think more whether the setting to ultimately trusted is a good idea.!!
|
* add a way to set expiration time for key signatures.
|
||||||
|
|
||||||
* add some minor things vor VMS.
|
* add some minor things vor VMS.
|
||||||
|
|
||||||
* Don't get the ultimately trusted keys from the secring but store
|
* Don't get the ultimately trusted keys from the secring but store
|
||||||
it permanently in the trustdb. This way we don't need a secring at all.
|
it permanently in the trustdb. This way we don't need a secring at all.
|
||||||
|
[ Solved by re-introducing --trusted-key ]
|
||||||
|
|
||||||
* Use DSA keys with the test suite.
|
* Use DSA keys with the test suite.
|
||||||
|
|
||||||
@ -21,6 +22,8 @@
|
|||||||
|
|
||||||
* Replace Valid/Invalid by Known/Unknown?
|
* Replace Valid/Invalid by Known/Unknown?
|
||||||
|
|
||||||
|
* Fix the bug in the mips assembler code
|
||||||
|
|
||||||
Scheduled for 1.1
|
Scheduled for 1.1
|
||||||
-----------------
|
-----------------
|
||||||
* export by user-IDs does only export the first matching name which leads
|
* export by user-IDs does only export the first matching name which leads
|
||||||
@ -42,6 +45,7 @@ Scheduled for 1.1
|
|||||||
* Skip RO keyrings when importing a key.
|
* Skip RO keyrings when importing a key.
|
||||||
|
|
||||||
* Use the newest encryption key if only the main key has been given.
|
* Use the newest encryption key if only the main key has been given.
|
||||||
|
[already in the gpg 1.1 codebase]
|
||||||
|
|
||||||
* replace the keyserver stuff either by a call to a specialized
|
* replace the keyserver stuff either by a call to a specialized
|
||||||
utility and SOCKSify this utility.
|
utility and SOCKSify this utility.
|
||||||
@ -52,6 +56,8 @@ Scheduled for 1.1
|
|||||||
* Delay the read of the passphrase-fd after a NEED_PASSPHRASE. But this
|
* Delay the read of the passphrase-fd after a NEED_PASSPHRASE. But this
|
||||||
may break some scripts.
|
may break some scripts.
|
||||||
|
|
||||||
|
* Get new assembler stuff from gmgp 3.1
|
||||||
|
|
||||||
|
|
||||||
Nice to have
|
Nice to have
|
||||||
------------
|
------------
|
||||||
|
|||||||
26
acinclude.m4
26
acinclude.m4
@ -45,6 +45,32 @@ AC_DEFUN(GNUPG_CHECK_GNUMAKE,
|
|||||||
])
|
])
|
||||||
|
|
||||||
|
|
||||||
|
dnl GNUPG_CHECK_FAQPROG
|
||||||
|
dnl
|
||||||
|
AC_DEFUN(GNUPG_CHECK_FAQPROG,
|
||||||
|
[ AC_MSG_CHECKING(for faqprog.pl)
|
||||||
|
if faqprog.pl -V 2>/dev/null | grep '^faqprog.pl ' >/dev/null 2>&1; then
|
||||||
|
working_faqprog=yes
|
||||||
|
FAQPROG="faqprog.pl"
|
||||||
|
else
|
||||||
|
working_faqprog=no
|
||||||
|
FAQPROG=": "
|
||||||
|
fi
|
||||||
|
AC_MSG_RESULT($working_faqprog)
|
||||||
|
AC_SUBST(FAQPROG)
|
||||||
|
AM_CONDITIONAL(WORKING_FAQPROG, test "$working_faqprog" = "yes" )
|
||||||
|
|
||||||
|
if test $working_faqprog = no; then
|
||||||
|
AC_MSG_WARN([[
|
||||||
|
***
|
||||||
|
*** It seems that the faqprog.pl program is not installed.
|
||||||
|
*** Unless you do not change the source of the FAQs it is not required.
|
||||||
|
*** The working version of this utility should be available at:
|
||||||
|
*** ftp://ftp.gnupg.org/pub/gcrypt/contrib/faqprog.pl
|
||||||
|
***]])
|
||||||
|
fi
|
||||||
|
])
|
||||||
|
|
||||||
|
|
||||||
dnl GNUPG_LINK_FILES( SRC, DEST )
|
dnl GNUPG_LINK_FILES( SRC, DEST )
|
||||||
dnl same as AC_LINK_FILES, but collect the files to link in
|
dnl same as AC_LINK_FILES, but collect the files to link in
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
Thu Sep 14 14:20:38 CEST 2000 Werner Koch <wk@openit.de>
|
||||||
|
|
||||||
|
* random.c (fast_random_poll): Check ENOSYS for getrusage.
|
||||||
|
* rndunix.c: Add 2 sources for QNX. By Sam Roberts.
|
||||||
|
|
||||||
Wed Sep 13 18:12:34 CEST 2000 Werner Koch <wk@openit.de>
|
Wed Sep 13 18:12:34 CEST 2000 Werner Koch <wk@openit.de>
|
||||||
|
|
||||||
* rsa.c (secret): Speed up by using the CRT. For a 2k keys this
|
* rsa.c (secret): Speed up by using the CRT. For a 2k keys this
|
||||||
|
|||||||
@ -594,8 +594,11 @@ fast_random_poll()
|
|||||||
#endif
|
#endif
|
||||||
#else
|
#else
|
||||||
{ struct rusage buf;
|
{ struct rusage buf;
|
||||||
if( getrusage( RUSAGE_SELF, &buf ) )
|
/* QNX/Neutrino does return ENOSYS - so we just ignore it and
|
||||||
|
* add whatever is in buf */
|
||||||
|
if( getrusage( RUSAGE_SELF, &buf ) && errno != ENOSYS )
|
||||||
BUG();
|
BUG();
|
||||||
|
|
||||||
add_randomness( &buf, sizeof buf, 1 );
|
add_randomness( &buf, sizeof buf, 1 );
|
||||||
memset( &buf, 0, sizeof buf );
|
memset( &buf, 0, sizeof buf );
|
||||||
}
|
}
|
||||||
|
|||||||
@ -242,6 +242,7 @@ static struct RI {
|
|||||||
{ "/usr/ucb/ps", "aux", SC(0.3), NULL, 0, 0, 0, 1 },
|
{ "/usr/ucb/ps", "aux", SC(0.3), NULL, 0, 0, 0, 1 },
|
||||||
{ "/usr/bin/ps", "aux", SC(0.3), NULL, 0, 0, 0, 1 },
|
{ "/usr/bin/ps", "aux", SC(0.3), NULL, 0, 0, 0, 1 },
|
||||||
{ "/bin/ps", "aux", SC(0.3), NULL, 0, 0, 0, 0 },
|
{ "/bin/ps", "aux", SC(0.3), NULL, 0, 0, 0, 0 },
|
||||||
|
{ "/bin/ps", "-A", SC(0.3), NULL, 0, 0, 0, 0 }, /*QNX*/
|
||||||
{ "/usr/bin/ipcs", "-a", SC(0.5), NULL, 0, 0, 0, 1 },
|
{ "/usr/bin/ipcs", "-a", SC(0.5), NULL, 0, 0, 0, 1 },
|
||||||
{ "/bin/ipcs", "-a", SC(0.5), NULL, 0, 0, 0, 0 },
|
{ "/bin/ipcs", "-a", SC(0.5), NULL, 0, 0, 0, 0 },
|
||||||
/* Unreliable source, depends on system usage */
|
/* Unreliable source, depends on system usage */
|
||||||
@ -290,6 +291,10 @@ static struct RI {
|
|||||||
/* This is a complex and screwball program. Some systems have things
|
/* This is a complex and screwball program. Some systems have things
|
||||||
* like rX_dmn, x = integer, for RAID systems, but the statistics are
|
* like rX_dmn, x = integer, for RAID systems, but the statistics are
|
||||||
* pretty dodgy */
|
* pretty dodgy */
|
||||||
|
#ifdef __QNXNTO__
|
||||||
|
{ "/bin/pidin", "-F%A%B%c%d%E%I%J%K%m%M%n%N%p%P%S%s%T", SC(0.3),
|
||||||
|
NULL, 0, 0, 0, 0 },
|
||||||
|
#endif
|
||||||
#if 0
|
#if 0
|
||||||
/* The following aren't enabled since they're somewhat slow and not very
|
/* The following aren't enabled since they're somewhat slow and not very
|
||||||
* unpredictable, however they give an indication of the sort of sources
|
* unpredictable, however they give an indication of the sort of sources
|
||||||
|
|||||||
11
configure.in
11
configure.in
@ -159,7 +159,7 @@ AC_PROG_INSTALL
|
|||||||
AC_PROG_AWK
|
AC_PROG_AWK
|
||||||
AC_CHECK_PROG(DOCBOOK_TO_MAN, docbook-to-man, yes, no)
|
AC_CHECK_PROG(DOCBOOK_TO_MAN, docbook-to-man, yes, no)
|
||||||
AM_CONDITIONAL(HAVE_DOCBOOK_TO_MAN, test "$ac_cv_prog_DOCBOOK_TO_MAN" = yes)
|
AM_CONDITIONAL(HAVE_DOCBOOK_TO_MAN, test "$ac_cv_prog_DOCBOOK_TO_MAN" = yes)
|
||||||
|
GNUPG_CHECK_FAQPROG
|
||||||
|
|
||||||
MPI_OPT_FLAGS=""
|
MPI_OPT_FLAGS=""
|
||||||
|
|
||||||
@ -257,13 +257,13 @@ case "${target}" in
|
|||||||
*-openbsd*)
|
*-openbsd*)
|
||||||
NAME_OF_DEV_RANDOM="/dev/srandom"
|
NAME_OF_DEV_RANDOM="/dev/srandom"
|
||||||
NAME_OF_DEV_URANDOM="/dev/urandom"
|
NAME_OF_DEV_URANDOM="/dev/urandom"
|
||||||
DYNLINK_MOD_CFLAGS="-shared -rdynamic -fpic -Wl,-Bshareable -Wl,-x"
|
DYNLINK_MOD_CFLAGS="-shared -rdynamic $CFLAGS_PIC -Wl,-Bshareable -Wl,-x"
|
||||||
;;
|
;;
|
||||||
|
|
||||||
*-netbsd*)
|
*-netbsd*)
|
||||||
NAME_OF_DEV_RANDOM="/dev/random"
|
NAME_OF_DEV_RANDOM="/dev/random"
|
||||||
NAME_OF_DEV_URANDOM="/dev/urandom"
|
NAME_OF_DEV_URANDOM="/dev/urandom"
|
||||||
DYNLINK_MOD_CFLAGS="-shared -rdynamic -fpic -Wl,-Bshareable -Wl,-x"
|
DYNLINK_MOD_CFLAGS="-shared -rdynamic $CFLAGS_PIC -Wl,-Bshareable -Wl,-x"
|
||||||
;;
|
;;
|
||||||
|
|
||||||
*-solaris*)
|
*-solaris*)
|
||||||
@ -275,7 +275,12 @@ case "${target}" in
|
|||||||
*)
|
*)
|
||||||
NAME_OF_DEV_RANDOM="/dev/random"
|
NAME_OF_DEV_RANDOM="/dev/random"
|
||||||
NAME_OF_DEV_URANDOM="/dev/urandom"
|
NAME_OF_DEV_URANDOM="/dev/urandom"
|
||||||
|
# -shared is a gcc-ism. Find pic flags from GNUPG_CHECK_PIC.
|
||||||
|
if test -n "$GCC" ; then
|
||||||
DYNLINK_MOD_CFLAGS="-shared $CFLAGS_PIC"
|
DYNLINK_MOD_CFLAGS="-shared $CFLAGS_PIC"
|
||||||
|
else
|
||||||
|
DYNLINK_MOD_CFLAGS="$CFLAGS_PIC"
|
||||||
|
fi
|
||||||
;;
|
;;
|
||||||
esac
|
esac
|
||||||
AC_DEFINE_UNQUOTED(NAME_OF_DEV_RANDOM, "$NAME_OF_DEV_RANDOM")
|
AC_DEFINE_UNQUOTED(NAME_OF_DEV_RANDOM, "$NAME_OF_DEV_RANDOM")
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
Thu Sep 14 14:20:38 CEST 2000 Werner Koch <wk@openit.de>
|
||||||
|
|
||||||
|
* faq.raw: New.
|
||||||
|
* Makefile.am: Support to build FAQs
|
||||||
|
|
||||||
Wed Jul 12 13:32:06 CEST 2000 Werner Koch <wk@>
|
Wed Jul 12 13:32:06 CEST 2000 Werner Koch <wk@>
|
||||||
|
|
||||||
* gpg.sgml: Add a note about the availability of the GPH.
|
* gpg.sgml: Add a note about the availability of the GPH.
|
||||||
|
|||||||
929
doc/FAQ
929
doc/FAQ
@ -1,240 +1,245 @@
|
|||||||
GNU Privacy Guard -- Frequently Asked Questions
|
|
||||||
=================================================
|
|
||||||
|
|
||||||
This FAQ is partly compiled from messages of the developers mailing list.
|
|
||||||
|
|
||||||
Many thanks to Kirk Fort, Brian Warner, ...
|
|
||||||
|
|
||||||
|
|
||||||
Q: How does this whole thing work?
|
GNUPG FREQUENTLY ASKED QUESTIONS
|
||||||
A: To generate a secret/public keypair, run
|
|
||||||
|
|
||||||
gpg --gen-key
|
Version: 0.1
|
||||||
|
Last-Modified: Sep 14, 2000
|
||||||
|
Maintained-by: Nils Ellmenreich <nils 'at' infosun.fmi.uni-passau.de>
|
||||||
|
|
||||||
and choose the default values.
|
This is the GnuPG FAQ. The latest HTML version is available
|
||||||
|
here. <http://www.gnupg.org>
|
||||||
|
|
||||||
Data that is encrypted with a public key can only be decrypted by the
|
The index is generated automatically, so there may be errors here. Not
|
||||||
matching secret key. The secret key is protected by a password, the
|
all questions may be in the section they belong to. Suggestions about
|
||||||
public key is not.
|
how to improve the structure of this FAQ are welcome.
|
||||||
|
|
||||||
So to send your friend a message, you would encrypt your message with his
|
Please send additions and corrections to the maintainer. Don't send
|
||||||
public key, and he would only be able to decrypt it by having the secret
|
message like "This should be a FAQ - what's the answer?". If it hasn't
|
||||||
key and putting in the password to use his secret key.
|
been asked before, it isn't a FAQ. Otherwise, please provide the answer
|
||||||
|
to be included here.
|
||||||
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
|
|
||||||
|
|
||||||
gpg --fingerprint user-id
|
|
||||||
|
|
||||||
over phone (if you really know the voice of the other person) or at
|
|
||||||
a key signing party (which are often held at computer conferences)
|
|
||||||
or at a meeting of your local GNU/Linux User Group.
|
|
||||||
|
|
||||||
Hmm, what else. You may use the option "-o filename" to force output
|
|
||||||
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: What is the recommended key size?
|
|
||||||
A: 1024 bit for DSA signatures; even for plain ElGamal
|
1. GENERAL
|
||||||
|
1.1) What is GnuPG?
|
||||||
|
1.2) Is GnuPG compatible with PGP?
|
||||||
|
|
||||||
|
2. SOURCES OF INFORMATION
|
||||||
|
2.1) Where can I find more information?
|
||||||
|
2.2) Where do I get GnuPG?
|
||||||
|
|
||||||
|
3. INSTALLATION
|
||||||
|
3.1) Which OSes does GnuPG run on?
|
||||||
|
3.2) Which random gatherer should I use?
|
||||||
|
3.3) How do I include support for RSA and IDEA?
|
||||||
|
|
||||||
|
4. USAGE
|
||||||
|
4.1) What is the recommended key size?
|
||||||
|
4.2) Why does it sometimes take so long to create keys?
|
||||||
|
4.3) And it really takes long when I work on a remote system. Why?
|
||||||
|
4.4) What is the difference between options and commands?
|
||||||
|
4.5) I can't delete an user id because it is already deleted on my public
|
||||||
|
keying?
|
||||||
|
4.6) What are trust, validity and ownertrust?
|
||||||
|
4.7) How do I sign a patch file?
|
||||||
|
4.8) Where is the "encrypt-to-self" option?
|
||||||
|
4.9) How can I get rid of the Version and Comment headers in armored
|
||||||
|
messages?
|
||||||
|
4.10) What does the "You are using the xxxx character set." mean?
|
||||||
|
4.11) How can a get list of key IDs used to encrypt a message?
|
||||||
|
4.12) I can't decrypt my symmetrical only (-c) encrypted message with
|
||||||
|
a new version of GnuPG.
|
||||||
|
4.13) How can I used GnuPG in an automated environment?
|
||||||
|
|
||||||
|
5. COMPATIBILITY ISSUES
|
||||||
|
5.1) How can I encrypt a message so that pgp 2.x is able to decrypt it?
|
||||||
|
5.2) How can I conventional encrypt a message, so that PGP can decrypt
|
||||||
|
it?
|
||||||
|
5.3) Why is PGP 5.x not able to encrypt messages with some keys?
|
||||||
|
5.4) Why is PGP 5.x not able to verify my messages?
|
||||||
|
5.5) How do I transfer owner trust values from PGP to GnuPG?
|
||||||
|
5.6) PGP 5.x, 6.x do not like my secret key.
|
||||||
|
|
||||||
|
6. PROBLEMS and ERROR MESSAGES
|
||||||
|
6.1) Why do I get "gpg: Warning: using insecure memory!"
|
||||||
|
6.2) In the edit menu the trust values is not displayed correctly after
|
||||||
|
signing uids - why?
|
||||||
|
6.3) An ElGamal signature does not verify anymore since version 1.0.2 ...
|
||||||
|
6.4) Old versions of GnuPG can't verify ElGamal signatures
|
||||||
|
6.5) When I use --clearsign, the plain text has sometimes extra dashes
|
||||||
|
in it - why?
|
||||||
|
|
||||||
|
7. ADVANCED TOPICS
|
||||||
|
7.1) How does this whole thing work?
|
||||||
|
7.2) Why are some signatures with an ELG-E key valid?
|
||||||
|
7.3) How does the whole trust thing work?
|
||||||
|
7.4) What kind of output is this: "key C26EE891.298, uid 09FB: ...."?
|
||||||
|
7.5) How do I interpret some of the informational outputs?
|
||||||
|
7.6) Are the header lines of a cleartext signature part of the signed
|
||||||
|
material?
|
||||||
|
|
||||||
|
8. ACKNOWLEDGEMENTS
|
||||||
|
|
||||||
|
|
||||||
|
1. GENERAL
|
||||||
|
|
||||||
|
1.1) What is GnuPG?
|
||||||
|
|
||||||
|
GnuPG stands for GNU Privacy Guard and <http://www.gnupg.org>
|
||||||
|
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
|
||||||
|
RFC 2440. As <http://www.gnupg.org/rfc2440.html>
|
||||||
|
such, it is aimed to be compatible with PGP from NAI Inc.
|
||||||
|
|
||||||
|
1.2) 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 5.1ff. for details.
|
||||||
|
|
||||||
|
2. SOURCES OF INFORMATION
|
||||||
|
|
||||||
|
2.1) Where can I find more information?
|
||||||
|
|
||||||
|
Here's a list of on-line resources:
|
||||||
|
|
||||||
|
<http://www.gnupg.org/docs.html> 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.
|
||||||
|
|
||||||
|
On <http://lists.gnupg.org>
|
||||||
|
you'll find a searchable online archive of the GnuPG mailing lists.
|
||||||
|
|
||||||
|
*PLEASE:*
|
||||||
|
Before posting to a list, read this FAQ and the available
|
||||||
|
documentation. This way you help people focus on topics that have
|
||||||
|
not yet been resolved.
|
||||||
|
|
||||||
|
2.2) Where do I get GnuPG?
|
||||||
|
|
||||||
|
You can download the GNU Privacy Guard from it's primary FTP server
|
||||||
|
ftp.gnupg.org or from
|
||||||
|
one of the mirrors: <http://www.gnupg.org/mirror.html>
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
3. INSTALLATION
|
||||||
|
|
||||||
|
3.1) 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
|
||||||
|
http://www.gnupg.org/gnupg.html#supsys .
|
||||||
|
|
||||||
|
3.2) 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 --enable-static-rnd=linux.
|
||||||
|
|
||||||
|
On other systems, the Entropy Gathering Daemon (EGD) is a good
|
||||||
|
choice. It is a perl-daemon that monitors system activity nad hashes
|
||||||
|
it into random data. See the download page <http://www.gnupg.org/download.html>
|
||||||
|
how to obtain egd. Use --enable-static-rnd=egd here.
|
||||||
|
|
||||||
|
If the above options do not work, you can use the random number
|
||||||
|
generator "unix". This is *very* slow and should be
|
||||||
|
avoided. The random quality isn't very good so don't use it on
|
||||||
|
sensitive data.
|
||||||
|
|
||||||
|
3.3) How do I include support for RSA and IDEA?
|
||||||
|
|
||||||
|
The official GnuPG distribution (as of 1.0.2) does not contain
|
||||||
|
either of them due to patents restriction. The RSA patent expires
|
||||||
|
Sept 20, 2000. A new GnuPG release is then scheduled to include
|
||||||
|
it. The IDEA patent does not expire before 2007 so don't expect
|
||||||
|
official support before then.
|
||||||
|
|
||||||
|
However, there are unofficial modules to include both of them even
|
||||||
|
in earlier version of GnuPG. They're available from
|
||||||
|
<ftp://ftp.gnupg.org/pub/gcrypt/contrib/>
|
||||||
|
<ftp://ftp.gnupg.org/pub/gcrypt/contrib/>. Look for idea.c
|
||||||
|
and rsa.c. Compilation directives are in the headers
|
||||||
|
of these files. Then add the following lines to your ~/.gnupg/options:
|
||||||
|
load-extension idea
|
||||||
|
load-extension rsa
|
||||||
|
|
||||||
|
These extensions are not available for the Windows version of GnuPG.
|
||||||
|
|
||||||
|
|
||||||
|
4. USAGE
|
||||||
|
|
||||||
|
4.1) 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
|
signatures this is sufficient as the size of the hash
|
||||||
is probably the weakest link if the keysize is larger
|
is probably the weakest link if the key size is larger
|
||||||
than 1024 bits. Encryption keys may have greater sizes,
|
than 1024 bits. Encryption keys may have greater sizes,
|
||||||
but you should than check the fingerprint of this key:
|
but you should than check the fingerprint of this key:
|
||||||
"gpg --fingerprint --fingerprint <user ID>".
|
"gpg --fingerprint --fingerprint <user ID>".
|
||||||
|
|
||||||
Q: Why are some signatures with an ELG-E key valid?
|
4.2) Why does it sometimes take so long to create keys?
|
||||||
A: 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: Why is PGP 5.x not able to encrypt messages with some keys?
|
The problem here is that we need a lot of random bytes and for that
|
||||||
A: 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?
|
|
||||||
A: PGP 5.x does not accept V4 signatures for data material but
|
|
||||||
OpenPGP requires generation of V4 signatures for all kind of
|
|
||||||
data. Use the option "--force-v3-sigs" to generate V3 signatures
|
|
||||||
for data.
|
|
||||||
|
|
||||||
Q: I can't delete an user id because it is already deleted on my
|
|
||||||
public keyring?
|
|
||||||
A: 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: How can I encrypt a message so that pgp 2.x is able to decrypt it?
|
|
||||||
A: You can't do that because pgp 2.x normally uses IDEA which is not
|
|
||||||
supported by GnuPG because it is patented, but if you have a modified
|
|
||||||
version of PGP you can try this:
|
|
||||||
|
|
||||||
gpg --rfc1991 --cipher-algo 3des ...
|
|
||||||
|
|
||||||
Please don't pipe the data to encrypt to gpg but give it as a filename;
|
|
||||||
otherwise, pgp 2 will not be able to handle it.
|
|
||||||
|
|
||||||
Q: How can I conventional encrypt a message, so that PGP can decrypt it?
|
|
||||||
A: You can't do this for PGP 2. For PGP 5 you should use this:
|
|
||||||
|
|
||||||
gpg -c --cipher-algo 3des --compress-algo 1 myfile
|
|
||||||
|
|
||||||
You may replace "3des" by "cast5". "blowfish" does not work with
|
|
||||||
all versions of pgp5. You may also want to put
|
|
||||||
compress-algo 1
|
|
||||||
into your ~/.gnupg/options file - this does not affect normal
|
|
||||||
gnupg operation.
|
|
||||||
|
|
||||||
|
|
||||||
Q: Why does it sometimes take so long to create keys?
|
|
||||||
A: The problem here is that we need a lot of random bytes and for that
|
|
||||||
we (on Linux the /dev/random device) must collect some random data.
|
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
|
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
|
talked to Ted Ts'o and he commented that the best way to fill the
|
||||||
is to play with your keyboard. Good security has its price. What I do
|
buffer is to play with your keyboard. Good security has its price.
|
||||||
is to hit several times on the shift, control, alternate, and capslock
|
What I do is to hit several times on the shift, control, alternate,
|
||||||
keys, because these keys do not produce output to the screen. This way
|
and capslock keys, because these keys do not produce output to the
|
||||||
you get your keys really fast (it's the same thing pgp2 does).
|
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
|
Another problem might be another program which eats up your random
|
||||||
(a program (look at your daemons) that reads from /dev/[u]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?
|
4.3) And it really takes long when I work on a remote system. Why?
|
||||||
A: 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 keyring (which is in most cases vulnerable to advanced
|
|
||||||
dictionary attacks) - I strongly encourage everyone to only create keys
|
|
||||||
on a local computer (a disconnected laptop is probably the best choice)
|
|
||||||
and if you need it on your connected box (I know: We all do this) be
|
|
||||||
sure to have a strong password for your account and for your secret key
|
|
||||||
and that you can trust your system administrator.
|
|
||||||
|
|
||||||
When I check GnuPG on a remote system via ssh (I have no Alpha here ;-)
|
Don't do this at all! You should never create keys or even use GnuPG
|
||||||
I have the same problem. It takes a *very* long time to create the
|
on a remote system because you normally have no physical control
|
||||||
keys, so I use a special option, --quick-random, to generate insecure
|
over your secret key ring (which is in most cases vulnerable to
|
||||||
keys which are only good for some tests.
|
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: How does the whole trust thing work?
|
4.4) What is the difference between options and commands?
|
||||||
A: It works more or less like PGP. The difference is that the trust is
|
|
||||||
computed at the time it is needed. This is one of the reasons for the
|
|
||||||
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.
|
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
|
||||||
gpg --list-keys --with-colons
|
run GPG, you *must* pick exactly one command (with one
|
||||||
|
exception, see below). You *may* pick one or more options.
|
||||||
If the first field is "pub" or "uid", the second field shows you the trust:
|
The command should, just by convention, come at the end of the
|
||||||
|
argument list, after all the options. If the command takes a file
|
||||||
o = Unknown (this key is new to the system)
|
(all the basic ones do), the filename comes at the very end. So the
|
||||||
e = The key has expired
|
basic way to run gpg is:
|
||||||
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
|
|
||||||
|
|
||||||
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)
|
|
||||||
|
|
||||||
gpg --list-ownertrust
|
|
||||||
|
|
||||||
The first field is the fingerprint of the primary key, the second field
|
|
||||||
is the assigned value:
|
|
||||||
|
|
||||||
- = 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.
|
|
||||||
|
|
||||||
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 is the difference between options and commands?
|
|
||||||
A: If you do a "gpg --help", you will get two separate lists. The first is
|
|
||||||
a list of commands. The second is a list of options. Whenever you run GPG,
|
|
||||||
you *must* pick exactly one command (**with one exception, see below). You
|
|
||||||
*may* pick one or more options. The command should, just by convention,
|
|
||||||
come at the end of the argument list, after all the options. If the
|
|
||||||
command takes a file (all the basic ones do), the filename comes at the
|
|
||||||
very end. So the basic way to run gpg is:
|
|
||||||
|
|
||||||
gpg [--option something] [--option2] [--option3 something] --command file
|
gpg [--option something] [--option2] [--option3 something] --command file
|
||||||
|
|
||||||
Some options take arguments, for example the --output option (which can be
|
Some options take arguments, for example the --output option (which
|
||||||
abbreviated -o) is an option that takes a filename. The option's argument
|
can be abbreviated -o) is an option that takes a filename. The
|
||||||
must follow immediately after the option itself, otherwise gpg doesn't know
|
option's argument must follow immediately after the option itself,
|
||||||
which option the argument is supposed to go with. As an option, --output and
|
otherwise gpg doesn't know which option the argument is supposed to
|
||||||
its filename must come before the command. The --recipient (-r) option takes
|
go with. As an option, --output and its filename must come before
|
||||||
a name or keyid to encrypt the message to, which must come right after the -r
|
the command. The --recipient (-r) option takes a name or keyid to
|
||||||
argument. The --encrypt (or -e) command comes after all the options followed
|
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
|
by the file you wish to encrypt. So use
|
||||||
|
|
||||||
gpg -r alice -o secret.txt -e test.txt
|
gpg -r alice -o secret.txt -e test.txt
|
||||||
@ -243,14 +248,14 @@
|
|||||||
|
|
||||||
gpg --recipient alice --output secret.txt --encrypt test.txt
|
gpg --recipient alice --output secret.txt --encrypt test.txt
|
||||||
|
|
||||||
If you're saving it in a file called ".txt" then you'd probably expect to see
|
If you're saving it in a file called ".txt" then you'd probably
|
||||||
ASCII-armored text in there, so you need to add the --armor (-a) option,
|
expect to see ASCII-armored text in there, so you need to add the
|
||||||
which doesn't take any arguments.
|
--armor (-a) option, which doesn't take any arguments.
|
||||||
|
|
||||||
gpg --armor --recipient alice --output secret.txt --encrypt test.txt
|
gpg --armor --recipient alice --output secret.txt --encrypt test.txt
|
||||||
|
|
||||||
If you imagine square brackets around the optional parts, it becomes a bit
|
If you imagine square brackets around the optional parts, it becomes
|
||||||
clearer:
|
a bit clearer:
|
||||||
|
|
||||||
gpg [--armor] [--recipient alice] [--output secret.txt] --encrypt test.txt
|
gpg [--armor] [--recipient alice] [--output secret.txt] --encrypt test.txt
|
||||||
|
|
||||||
@ -258,156 +263,398 @@
|
|||||||
|
|
||||||
gpg --output secret.txt --recipient alice --armor --encrypt test.txt
|
gpg --output secret.txt --recipient alice --armor --encrypt test.txt
|
||||||
|
|
||||||
If your filename begins with a hyphen (e.g. "-a.txt"), gnupg assumes this is
|
If your filename begins with a hyphen (e.g. "-a.txt"), gnupg assumes
|
||||||
an option and may complain. To avoid this you have either to use
|
this is an option and may complain. To avoid this you have either
|
||||||
"./-a.txt" or stop the option and command processing with two hyphens:
|
to use "./-a.txt" or stop the option and command processing with two
|
||||||
"-- -a.txt".
|
hyphens: "-- -a.txt".
|
||||||
|
|
||||||
** the exception: signing and encrypting at the same time. Use
|
|
||||||
|
|
||||||
|
*The exception:* signing and encrypting at the same time. Use
|
||||||
gpg [--options] --sign --encrypt foo.txt
|
gpg [--options] --sign --encrypt foo.txt
|
||||||
|
|
||||||
|
|
||||||
Q: What kind of output is this: "key C26EE891.298, uid 09FB: ...."?
|
4.5) I can't delete an user id because it is already deleted on my public
|
||||||
A: This is the internal representation of an user id in the trustdb.
|
keying?
|
||||||
"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.
|
|
||||||
|
|
||||||
|
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: What is trust, validity and ownertrust?
|
4.6) What are trust, validity and ownertrust?
|
||||||
A: "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 interpret some of the informational outputs?
|
"ownertrust" is used instead of "trust" to make clear that this is
|
||||||
A: While checking the validity of a key, GnuPG sometimes prints
|
the value you have assigned to a key to express how much you trust
|
||||||
some information which is prefixed with information about
|
the owner of this key to correctly sign (and so introduce) other
|
||||||
the checked item.
|
keys. "validity", or calculated trust, is a value which says how
|
||||||
"key 12345678.3456"
|
much GnuPG thinks a key is valid (that it really belongs to the one
|
||||||
This is about the key with key ID 12345678 and the internal
|
who claims to be the owner of the key). For more see the chapter
|
||||||
number 3456, which is the record number of the so called
|
"The Web of Trust" in the Manual.
|
||||||
directory record in the trustdb.
|
|
||||||
"uid 12345678.3456/ACDE"
|
|
||||||
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.
|
|
||||||
"sig 12345678.3456/ACDE/9A8B7C6D"
|
|
||||||
This is about the signature with key ID 9A8B7C6D for the
|
|
||||||
above key and user ID, if it is a signature which is direct
|
|
||||||
on a key, the user ID part is empty (..//..).
|
|
||||||
|
|
||||||
|
4.7) How do I sign a patch file?
|
||||||
|
|
||||||
Q: How do I sign a patch file?
|
Use "gpg --clearsign --not-dash-escaped ...". The problem with
|
||||||
A: Use "gpg --clearsign --not-dash-escaped ...".
|
--clearsign is that all lines starting with a dash are quoted with
|
||||||
The problem with --clearsign is that all lines starting with a dash are
|
"- "; obviously diff produces many of lines starting with a dash and
|
||||||
quoted with "- "; obviously diff produces many of lines starting with a
|
these are then quoted and that is not good for patch ;-). To use a
|
||||||
dash and these are then quoted and that is not good for patch ;-). To
|
patch file without removing the cleartext signature, the special
|
||||||
use a patch file without removing the cleartext signature, the special
|
option --not-dash-escaped may be used to suppress generation of
|
||||||
option --not-dash-escaped may be used to suppress generation of these
|
these escape sequences. You should not mail such a patch because
|
||||||
escape sequences. You should not mail such a patch because spaces and
|
spaces and line endings are also subject to the signature and a
|
||||||
line endings are also subject to the signature and a mailer may not
|
mailer may not preserve these. If you want to mail a file you can
|
||||||
preserve these. If you want to mail a file you can simply sign it
|
simply sign it using your MUA.
|
||||||
using your MUA.
|
|
||||||
|
|
||||||
|
4.8) Where is the "encrypt-to-self" option?
|
||||||
|
|
||||||
Q: Where is the "encrypt-to-self" option?
|
Use "--encrypt-to your_keyid". You can use more than one of these
|
||||||
A: Use "--encrypt-to your_keyid". You can use more than one
|
options. To temporary override the use of this additional keys, you
|
||||||
of these options. To temporary override the use of this additional
|
can use the option "--no-encrypt-to".
|
||||||
keys, you can use the option "--no-encrypt-to".
|
|
||||||
|
|
||||||
|
4.9) How can I get rid of the Version and Comment headers in armored
|
||||||
|
messages?
|
||||||
|
|
||||||
Q: How can I get rid of the Version and Comment headers in
|
Use "--no-version --comment ''". Note that the left over blank line
|
||||||
armored messages?
|
|
||||||
A: Use "--no-version --comment ''". Note that the left over blank line
|
|
||||||
is required by the protocol.
|
is required by the protocol.
|
||||||
|
|
||||||
|
4.10) What does the "You are using the xxxx character set." mean?
|
||||||
|
|
||||||
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
|
||||||
A: This note is printed when UTF8 mapping has to be done. Make sure that
|
that the displayed charset is the one you have activated on your
|
||||||
the displayed charset is the one you have activated on your system
|
system "iso-8859-1" is the most used one, so this is the default.
|
||||||
"iso-8859-1" is the most used one, so this is the default. You can
|
You can change the charset with the option "--charset". It is
|
||||||
change the charset with the option "--charset". It is important that
|
important that you active character set matches the one displayed -
|
||||||
you active character set matches the one displayed - if not, restrict
|
if not, restrict yourself to plain 7 bit ASCII and no mapping has to
|
||||||
yourself to plain 7 bit ASCII and no mapping has to be done.
|
be done.
|
||||||
|
|
||||||
Q: How do I transfer owner trust values from PGP to GnuPG?
|
4.11) How can a get list of key IDs used to encrypt a message?
|
||||||
A: There is a script in the tools directory to help you:
|
|
||||||
After you have imported the PGP keyring you can give this command:
|
|
||||||
$ lspgpot pgpkeyring | gpg --import-ownertrust
|
|
||||||
where pgpkeyring is the original keyring and not the GnuPG one you
|
|
||||||
might have created in the first step.
|
|
||||||
|
|
||||||
Q: Are the headerlines of a cleartext signature part of the signed
|
gpg --batch --decrypt --list-only --status-fd 1 2>/dev/null
|
||||||
material?
|
\ | awk '/^\[GNUPG:\] ENC_TO / { print $3 }'
|
||||||
A: 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 OpenPGG signatures to tell the parser which
|
|
||||||
hash algorithm to use.
|
|
||||||
|
|
||||||
Q: How can a get list of key IDs used to encrypt a message?
|
4.12) I can't decrypt my symmetrical only (-c) encrypted message with
|
||||||
A: gpg --batch --decrypt --list-only --status-fd 1 2>/dev/null \
|
|
||||||
| awk '/^\[GNUPG:\] ENC_TO / { print $3 }'
|
|
||||||
|
|
||||||
|
|
||||||
Q: PGP 5.x, 6.x does not like my secret key.
|
|
||||||
A: PGP probably bails 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:
|
|
||||||
|
|
||||||
gpg --export-secret-keys --no-comment -a your-key-id
|
|
||||||
|
|
||||||
Q: I can't decrypt my symmetrical only (-c) encrypted message with
|
|
||||||
a new version of GnuPG.
|
a new version of GnuPG.
|
||||||
A: 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 used GnuPG in an automated environment?
|
There used to be a bug in GnuPG < 1.0.1 which happens only if 3DES
|
||||||
A: You should use the option --batch and don't use passphrases as
|
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.
|
||||||
|
|
||||||
|
4.13) How can I used 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
|
there is usually no way to store it more secure than the secret
|
||||||
keyring itself. The suggested way to create the keys for the
|
keyring itself. The suggested way to create the keys for the
|
||||||
automated environment is:
|
automated environment is:
|
||||||
|
|
||||||
On a secure machine:
|
On a secure machine:
|
||||||
1. If you want to do automatic signing, create a signing subkey
|
If you want to do automatic signing, create a signing
|
||||||
for your key (edit menu, choose "addkey" and the DSA).
|
subkey for your key (edit menu, choose "addkey" and the DSA). [H
|
||||||
2. Make sure that you use a passphrase (Needed by the current
|
LI] Make sure that you use a passphrase (Needed by the current
|
||||||
implementation)
|
implementation) gpg --export-secret-subkeys --no-comment foo
|
||||||
3. gpg --export-secret-subkeys --no-comment foo >secring.auto
|
>secring.auto Copy secring.auto and the public keyring to a
|
||||||
4. Copy secring.auto and the public keyring to a test directory.
|
test directory. Cd to this directory. gpg --homedir
|
||||||
5. Cd to this directory.
|
. --edit foo and use "passwd" to remove the pass-phrase from the
|
||||||
6. gpg --homedir . --edit foo
|
subkeys. You may also want to remove all unused subkeys.
|
||||||
and use "passwd" to remove the passphrase from the subkeys.
|
copy secring.auto to a floppy and carry it to the target box
|
||||||
You may also want to remove all unused subkeys.
|
On the target machine: Install secring.auto as secret
|
||||||
7. copy secring.auto to a floppy and carry it to the
|
keyring. Now you can start your new service. It is a good
|
||||||
target box
|
idea to install some intrusion detection system so that you
|
||||||
On the target machine:
|
hopefully get a notice of an successful intrusion, so that you in
|
||||||
8. Install secring.auto as secret keyring.
|
turn can revoke all the subkeys installed on that machine and
|
||||||
9. Now you can start your new service. It is a good idea to
|
install new subkeys.
|
||||||
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.
|
|
||||||
|
|
||||||
Q: In the edit menu the trust values is not displayed correctly after
|
|
||||||
signing uids - why?
|
|
||||||
A: 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 GnuPG 1.1
|
|
||||||
|
|
||||||
Q: An Elgamal signature does not verify anymore since version 1.0.2
|
|
||||||
A: Use the option --emulate-md-encode-bug.
|
|
||||||
|
|
||||||
Q: Old versions of GnuPG can't verify ElGamal signatures
|
5. COMPATIBILITY ISSUES
|
||||||
A: Update to GnuPG 1.0.2
|
|
||||||
|
|
||||||
|
|
||||||
|
5.1) How can I encrypt a message so that pgp 2.x is able to decrypt it?
|
||||||
|
|
||||||
|
You can't do that because pgp 2.x normally uses IDEA which is not
|
||||||
|
supported by GnuPG because it is patented, but if you have a
|
||||||
|
modified version of PGP you can try this:
|
||||||
|
|
||||||
|
gpg --rfc1991 --cipher-algo 3des ...
|
||||||
|
|
||||||
|
Please don't pipe the data to encrypt to gpg but give it as a
|
||||||
|
filename; otherwise, pgp 2 will not be able to handle it.
|
||||||
|
|
||||||
|
5.2) How can I conventional encrypt a message, so that PGP can decrypt
|
||||||
|
it?
|
||||||
|
|
||||||
|
You can't do this for PGP 2. For PGP 5 you should use this:
|
||||||
|
|
||||||
|
gpg -c --cipher-algo 3des --compress-algo 1 myfile
|
||||||
|
|
||||||
|
You may replace "3des" by "cast5". "blowfish" does not work with all
|
||||||
|
versions of pgp5. You may also want to put compress-algo 1
|
||||||
|
into your ~/.gnupg/options file - this does not affect
|
||||||
|
normal gnupg operation.
|
||||||
|
|
||||||
|
|
||||||
|
5.3) 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.
|
||||||
|
|
||||||
|
5.4) Why is PGP 5.x not able to verify my messages?
|
||||||
|
|
||||||
|
PGP 5.x does not accept V4 signatures for data material but OpenPGP
|
||||||
|
requires generation of V4 signatures for all kind of data. Use the
|
||||||
|
option "--force-v3-sigs" to generate V3 signatures for data.
|
||||||
|
|
||||||
|
5.5) 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:
|
||||||
|
|
||||||
|
$ lspgpot pgpkeyring | gpg --import-ownertrust
|
||||||
|
|
||||||
|
where pgpkeyring is the original keyring and not the GnuPG one you
|
||||||
|
might have created in the first step.
|
||||||
|
|
||||||
|
5.6) PGP 5.x, 6.x do not like my secret key.
|
||||||
|
|
||||||
|
PGP probably bails 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:
|
||||||
|
gpg --export-secret-keys --no-comment -a your-key-id
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
6. PROBLEMS and ERROR MESSAGES
|
||||||
|
|
||||||
|
6.1) 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 memory pages
|
||||||
|
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.
|
||||||
|
|
||||||
|
If you can't or don't want to install GnuPG setuid(root), you can
|
||||||
|
use the option "--no-secmem-warning" or put
|
||||||
|
no-secmem-warning in your ~/.gnupg/options file.
|
||||||
|
|
||||||
|
6.2) 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.
|
||||||
|
|
||||||
|
6.3) An ElGamal signature does not verify anymore since version 1.0.2 ...
|
||||||
|
|
||||||
|
Use the option --emulate-md-encode-bug.
|
||||||
|
|
||||||
|
6.4) Old versions of GnuPG can't verify ElGamal signatures
|
||||||
|
|
||||||
|
Update to GnuPG 1.0.2 or newer.
|
||||||
|
|
||||||
|
|
||||||
|
6.5) 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 distinguish those lines from the thos lines which make up such
|
||||||
|
a clearsigned message.
|
||||||
|
|
||||||
|
If you use GnuPG to process those emessage, the extra dashes are removed.
|
||||||
|
Good mail clients remove those extra dashes when displaying such a
|
||||||
|
message.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
7. ADVANCED TOPICS
|
||||||
|
|
||||||
|
7.1) How does this whole thing work?
|
||||||
|
|
||||||
|
To generate a secret/public keypair, run gpg --gen-key
|
||||||
|
and choose the default values.
|
||||||
|
|
||||||
|
Data that is encrypted with a public key can only be decrypted by
|
||||||
|
the matching secret key. The secret key is protected by a password,
|
||||||
|
the public key is not.
|
||||||
|
|
||||||
|
So to send your friend a message, you would encrypt your message
|
||||||
|
with his public key, and he would only be able to decrypt it by
|
||||||
|
having the secret key and putting in the password to use his secret
|
||||||
|
key.
|
||||||
|
|
||||||
|
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
|
||||||
|
gpg --fingerprint user-id
|
||||||
|
over phone (if you really know the voice of the other person) or at a
|
||||||
|
key signing party (which are often held at computer conferences) or at
|
||||||
|
a meeting of your local GNU/Linux User Group.
|
||||||
|
|
||||||
|
Hmm, what else. You may use the option "-o filename" to force output
|
||||||
|
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.
|
||||||
|
|
||||||
|
|
||||||
|
7.2) 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.
|
||||||
|
|
||||||
|
|
||||||
|
7.3) 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.
|
||||||
|
gpg --list-keys --with-colons
|
||||||
|
|
||||||
|
If the first field is "pub" or "uid", the second field shows you the
|
||||||
|
trust:
|
||||||
|
|
||||||
|
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
|
||||||
|
|
||||||
|
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)
|
||||||
|
|
||||||
|
gpg --list-ownertrust The first field is the
|
||||||
|
fingerprint of the primary key, the second field is the assigned
|
||||||
|
value:
|
||||||
|
|
||||||
|
- = 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.
|
||||||
|
|
||||||
|
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).
|
||||||
|
|
||||||
|
7.4) What kind of output is this: "key C26EE891.298, uid 09FB: ...."?
|
||||||
|
|
||||||
|
This is the internal representation of an 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.
|
||||||
|
|
||||||
|
7.5) 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. "key 12345678.3456" This is about the key
|
||||||
|
with key ID 12345678 and the internal number 3456, which is the
|
||||||
|
record number of the so called directory record in the trustdb.
|
||||||
|
"uid 12345678.3456/ACDE" 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. "sig
|
||||||
|
12345678.3456/ACDE/9A8B7C6D" This is about the signature
|
||||||
|
with key ID 9A8B7C6D for the above key and user ID, if it is a
|
||||||
|
signature which is direct on a key, the user ID part is empty
|
||||||
|
(..//..).
|
||||||
|
|
||||||
|
7.6) 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.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
8. ACKNOWLEDGEMENTS
|
||||||
|
|
||||||
|
Many thanks to Werner Koch for the original FAQ file and to all
|
||||||
|
posters to gnupg-users and gnupg-devel. They all provided most of
|
||||||
|
the answers.
|
||||||
|
|
||||||
|
Also thanks to Casper Dik for providing me with a script to generate
|
||||||
|
this FAQ (he uses it for the excellent Solaris2 FAQ).
|
||||||
|
|
||||||
|
|
||||||
|
Copyright (C) 2000 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.
|
||||||
|
|||||||
@ -1,9 +1,12 @@
|
|||||||
## Process this file with automake to create Makefile.in
|
## Process this file with automake to create Makefile.in
|
||||||
|
|
||||||
EXTRA_DIST = DETAILS gpg.sgml gpg.1 FAQ HACKING OpenPGP README.W32
|
EXTRA_DIST = DETAILS gpg.sgml gpg.1 faq.raw \
|
||||||
|
HACKING OpenPGP README.W32
|
||||||
|
|
||||||
man_MANS = gpg.1
|
man_MANS = gpg.1
|
||||||
|
|
||||||
|
pkgdata_DATA = FAQ faq.html
|
||||||
|
|
||||||
|
|
||||||
%.1 : %.sgml
|
%.1 : %.sgml
|
||||||
if HAVE_DOCBOOK_TO_MAN
|
if HAVE_DOCBOOK_TO_MAN
|
||||||
@ -15,6 +18,12 @@ else
|
|||||||
endif
|
endif
|
||||||
|
|
||||||
|
|
||||||
|
FAQ : faq.raw
|
||||||
|
$(FAQPROG) -f $< $@ || $(FAQPROG) -f $< $@
|
||||||
|
|
||||||
|
faq.html : faq.raw
|
||||||
|
$(FAQPROG) -h -f $< $@ 2>&1 || $(FAQPROG) -h -f $< $@
|
||||||
|
|
||||||
%.dvi: %.sgml
|
%.dvi: %.sgml
|
||||||
db2dvi $<
|
db2dvi $<
|
||||||
|
|
||||||
@ -29,3 +38,9 @@ dist-hook:
|
|||||||
@if test `wc -c < gpg.1` -lt 200; then \
|
@if test `wc -c < gpg.1` -lt 200; then \
|
||||||
echo 'ERROR: dummy man page'; false; fi
|
echo 'ERROR: dummy man page'; false; fi
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|||||||
646
doc/faq.raw
Normal file
646
doc/faq.raw
Normal file
@ -0,0 +1,646 @@
|
|||||||
|
[$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=Nils Ellmenreich <nils 'at' infosun.fmi.uni-passau.de>]
|
||||||
|
[$WINS=.wins.uva.nl/pub/solaris]
|
||||||
|
[$ftpWINS=ftp://ftp.wins.uva.nl/pub/solaris]
|
||||||
|
[$hWINS=http://www.wins.uva.nl/]
|
||||||
|
[$fhWINS=http://www.wins.uva.nl/pub/solaris/solaris2]
|
||||||
|
[$hGPG=http://www.gnupg.org]
|
||||||
|
|
||||||
|
|
||||||
|
[H H1]GNUPG FREQUENTLY ASKED QUESTIONS[H /H1]
|
||||||
|
|
||||||
|
[H pre]
|
||||||
|
Version: 0.1
|
||||||
|
Last-Modified: Sep 14, 2000
|
||||||
|
Maintained-by: [$maintainer]
|
||||||
|
[H/pre]
|
||||||
|
|
||||||
|
This is the GnuPG FAQ. The latest HTML version is available
|
||||||
|
[H a href=[$hGPG]] 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. 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. Otherwise, please provide the answer
|
||||||
|
to be included here.
|
||||||
|
|
||||||
|
[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 a searchable online archive of the GnuPG mailing lists.
|
||||||
|
|
||||||
|
[H B]PLEASE:[H/B]
|
||||||
|
Before posting to a list, read this FAQ and the available
|
||||||
|
documentation. This way you help people focus on topics that have
|
||||||
|
not yet been resolved.
|
||||||
|
[H /UL]
|
||||||
|
|
||||||
|
<Q> Where do I get GnuPG?
|
||||||
|
|
||||||
|
You can download the GNU Privacy Guard from it's 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]
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
<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/gnupg.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].
|
||||||
|
|
||||||
|
On other systems, the Entropy Gathering Daemon (EGD) is a good
|
||||||
|
choice. It is a perl-daemon that monitors system activity nad 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.
|
||||||
|
|
||||||
|
<Q> How do I include support for RSA and IDEA?
|
||||||
|
|
||||||
|
The official GnuPG distribution (as of 1.0.2) does not contain
|
||||||
|
either of them due to patents restriction. The RSA patent expires
|
||||||
|
Sept 20, 2000. A new GnuPG release is then scheduled to include
|
||||||
|
it. The IDEA patent does not expire before 2007 so don't expect
|
||||||
|
official support before then.
|
||||||
|
|
||||||
|
However, there are unofficial modules to include both of them even
|
||||||
|
in earlier version of GnuPG. They're 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]
|
||||||
|
and [H pre]rsa.c[H /pre]. Compilation directives are in the headers
|
||||||
|
of these files. Then add the following lines to your ~/.gnupg/options:
|
||||||
|
[H pre]
|
||||||
|
load-extension idea
|
||||||
|
load-extension rsa
|
||||||
|
[H /pre]
|
||||||
|
|
||||||
|
These extensions are not available for the Windows version of GnuPG.
|
||||||
|
|
||||||
|
|
||||||
|
<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 than check the fingerprint of this key:
|
||||||
|
"gpg --fingerprint --fingerprint <user ID>".
|
||||||
|
|
||||||
|
<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 capslock keys, because these keys do not produce output to the
|
||||||
|
screen. This way you get your keys really fast (it's the same thing
|
||||||
|
pgp2 does).
|
||||||
|
|
||||||
|
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 an user id because it is already deleted on my public
|
||||||
|
keying?
|
||||||
|
|
||||||
|
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> 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 used 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]
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
<S> COMPATIBILITY ISSUES
|
||||||
|
|
||||||
|
<Dcompat>
|
||||||
|
|
||||||
|
<Q> How can I encrypt a message so that pgp 2.x is able to decrypt it?
|
||||||
|
|
||||||
|
You can't do that because pgp 2.x normally uses IDEA which is not
|
||||||
|
supported by GnuPG because it is patented, 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 give it as a
|
||||||
|
filename; otherwise, pgp 2 will not be able to handle it.
|
||||||
|
|
||||||
|
<Q> How can I conventional encrypt a message, so that PGP can decrypt
|
||||||
|
it?
|
||||||
|
|
||||||
|
You can't do this for PGP 2. For PGP 5 you should use this:
|
||||||
|
|
||||||
|
[H pre]
|
||||||
|
gpg -c --cipher-algo 3des --compress-algo 1 myfile
|
||||||
|
[H/pre]
|
||||||
|
|
||||||
|
You may replace "3des" by "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.
|
||||||
|
|
||||||
|
|
||||||
|
<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
|
||||||
|
requires generation of V4 signatures for all kind of data. 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 5.x, 6.x do not like my secret key.
|
||||||
|
|
||||||
|
PGP probably bails 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]
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
<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 memory pages
|
||||||
|
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.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
<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> 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 distinguish those lines from the thos lines which make up such
|
||||||
|
a clearsigned message.
|
||||||
|
|
||||||
|
If you use GnuPG to process those emessage, the extra dashes are removed.
|
||||||
|
Good mail clients remove those extra dashes when displaying such a
|
||||||
|
message.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
<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 an 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.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
<S> ACKNOWLEDGEMENTS
|
||||||
|
|
||||||
|
Many thanks to Werner Koch for the original FAQ file and to all
|
||||||
|
posters to gnupg-users and gnupg-devel. They all provided most of
|
||||||
|
the answers.
|
||||||
|
|
||||||
|
Also thanks to Casper Dik for providing me with a script to generate
|
||||||
|
this FAQ (he uses it for the excellent Solaris2 FAQ).
|
||||||
|
|
||||||
|
[H HR]
|
||||||
|
|
||||||
|
Copyright (C) 2000 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.
|
||||||
@ -1,3 +1,17 @@
|
|||||||
|
Thu Sep 14 14:20:38 CEST 2000 Werner Koch <wk@openit.de>
|
||||||
|
|
||||||
|
* g10.c (main): Default S2K algorithms are now SHA1 and CAST5 - this
|
||||||
|
should solve a lot of compatibility problems with other OpenPGP
|
||||||
|
apps because those algorithms are SHOULD and not optional. The old
|
||||||
|
way to force it was by using the --openpgp option whith the drawback
|
||||||
|
that this would disable a couple of workarounds for PGP.
|
||||||
|
|
||||||
|
* g10.c (main): Don't set --quite along with --no-tty. By Frank Tobin.
|
||||||
|
|
||||||
|
* misc.c (disable_core_dump): Don't display a warning here but a return
|
||||||
|
a status value and ...
|
||||||
|
* g10.c (main): ...print warnining here. Suggested by Sam Roberts.
|
||||||
|
|
||||||
Wed Sep 13 18:12:34 CEST 2000 Werner Koch <wk@openit.de>
|
Wed Sep 13 18:12:34 CEST 2000 Werner Koch <wk@openit.de>
|
||||||
|
|
||||||
* keyedit.c (keyedit_menu): Allow to use "debug" on the secret key.
|
* keyedit.c (keyedit_menu): Allow to use "debug" on the secret key.
|
||||||
|
|||||||
14
g10/g10.c
14
g10/g10.c
@ -580,6 +580,7 @@ main( int argc, char **argv )
|
|||||||
char **orig_argv;
|
char **orig_argv;
|
||||||
const char *fname;
|
const char *fname;
|
||||||
char *username;
|
char *username;
|
||||||
|
int may_coredump;
|
||||||
STRLIST sl, remusr= NULL, locusr=NULL;
|
STRLIST sl, remusr= NULL, locusr=NULL;
|
||||||
STRLIST nrings=NULL, sec_nrings=NULL;
|
STRLIST nrings=NULL, sec_nrings=NULL;
|
||||||
armor_filter_context_t afx;
|
armor_filter_context_t afx;
|
||||||
@ -613,7 +614,7 @@ main( int argc, char **argv )
|
|||||||
*/
|
*/
|
||||||
log_set_name("gpg");
|
log_set_name("gpg");
|
||||||
secure_random_alloc(); /* put random number into secure memory */
|
secure_random_alloc(); /* put random number into secure memory */
|
||||||
disable_core_dumps();
|
may_coredump = disable_core_dumps();
|
||||||
init_signals();
|
init_signals();
|
||||||
create_dotlock(NULL); /* register locking cleanup */
|
create_dotlock(NULL); /* register locking cleanup */
|
||||||
i18n_init();
|
i18n_init();
|
||||||
@ -624,8 +625,8 @@ main( int argc, char **argv )
|
|||||||
opt.def_digest_algo = 0;
|
opt.def_digest_algo = 0;
|
||||||
opt.def_compress_algo = 2;
|
opt.def_compress_algo = 2;
|
||||||
opt.s2k_mode = 3; /* iterated+salted */
|
opt.s2k_mode = 3; /* iterated+salted */
|
||||||
opt.s2k_digest_algo = DIGEST_ALGO_RMD160;
|
opt.s2k_digest_algo = DIGEST_ALGO_SHA1;
|
||||||
opt.s2k_cipher_algo = CIPHER_ALGO_BLOWFISH;
|
opt.s2k_cipher_algo = CIPHER_ALGO_CAST5;
|
||||||
opt.completes_needed = 1;
|
opt.completes_needed = 1;
|
||||||
opt.marginals_needed = 3;
|
opt.marginals_needed = 3;
|
||||||
opt.max_cert_depth = 5;
|
opt.max_cert_depth = 5;
|
||||||
@ -767,7 +768,7 @@ main( int argc, char **argv )
|
|||||||
case oArmor: opt.armor = 1; opt.no_armor=0; break;
|
case oArmor: opt.armor = 1; opt.no_armor=0; break;
|
||||||
case oOutput: opt.outfile = pargs.r.ret_str; break;
|
case oOutput: opt.outfile = pargs.r.ret_str; break;
|
||||||
case oQuiet: opt.quiet = 1; break;
|
case oQuiet: opt.quiet = 1; break;
|
||||||
case oNoTTY: opt.quiet = 1; tty_no_terminal(1); break;
|
case oNoTTY: tty_no_terminal(1); break;
|
||||||
case oDryRun: opt.dry_run = 1; break;
|
case oDryRun: opt.dry_run = 1; break;
|
||||||
case oInteractive: opt.interactive = 1; break;
|
case oInteractive: opt.interactive = 1; break;
|
||||||
case oVerbose: g10_opt_verbose++;
|
case oVerbose: g10_opt_verbose++;
|
||||||
@ -964,6 +965,11 @@ main( int argc, char **argv )
|
|||||||
log_info("used in a production environment or with production keys!\n");
|
log_info("used in a production environment or with production keys!\n");
|
||||||
}
|
}
|
||||||
#endif
|
#endif
|
||||||
|
|
||||||
|
if( may_coredump && !opt.quiet )
|
||||||
|
log_info(_("WARNING: program may create a core file!\n"));
|
||||||
|
|
||||||
|
|
||||||
if (opt.no_literal) {
|
if (opt.no_literal) {
|
||||||
log_info(_("NOTE: %s is not for normal use!\n"), "--no-literal");
|
log_info(_("NOTE: %s is not for normal use!\n"), "--no-literal");
|
||||||
if (opt.textmode)
|
if (opt.textmode)
|
||||||
|
|||||||
@ -54,7 +54,7 @@ char *make_radix64_string( const byte *data, size_t len );
|
|||||||
|
|
||||||
/*-- misc.c --*/
|
/*-- misc.c --*/
|
||||||
void trap_unaligned(void);
|
void trap_unaligned(void);
|
||||||
void disable_core_dumps(void);
|
int disable_core_dumps(void);
|
||||||
u16 checksum_u16( unsigned n );
|
u16 checksum_u16( unsigned n );
|
||||||
u16 checksum( byte *p, unsigned n );
|
u16 checksum( byte *p, unsigned n );
|
||||||
u16 checksum_mpi( MPI a );
|
u16 checksum_mpi( MPI a );
|
||||||
|
|||||||
13
g10/misc.c
13
g10/misc.c
@ -79,22 +79,23 @@ trap_unaligned(void)
|
|||||||
#endif
|
#endif
|
||||||
|
|
||||||
|
|
||||||
void
|
int
|
||||||
disable_core_dumps()
|
disable_core_dumps()
|
||||||
{
|
{
|
||||||
#ifndef HAVE_DOSISH_SYSTEM
|
#ifdef HAVE_DOSISH_SYSTEM
|
||||||
|
return 0;
|
||||||
|
#else
|
||||||
#ifdef HAVE_SETRLIMIT
|
#ifdef HAVE_SETRLIMIT
|
||||||
struct rlimit limit;
|
struct rlimit limit;
|
||||||
|
|
||||||
limit.rlim_cur = 0;
|
limit.rlim_cur = 0;
|
||||||
limit.rlim_max = 0;
|
limit.rlim_max = 0;
|
||||||
if( !setrlimit( RLIMIT_CORE, &limit ) )
|
if( !setrlimit( RLIMIT_CORE, &limit ) )
|
||||||
return;
|
return 0;
|
||||||
if( errno != EINVAL )
|
if( errno != EINVAL && errno != ENOSYS )
|
||||||
log_fatal(_("can't disable core dumps: %s\n"), strerror(errno) );
|
log_fatal(_("can't disable core dumps: %s\n"), strerror(errno) );
|
||||||
#endif
|
#endif
|
||||||
if( !opt.quiet )
|
return 1;
|
||||||
log_info(_("WARNING: program may create a core file!\n"));
|
|
||||||
#endif
|
#endif
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|||||||
@ -1,3 +1,7 @@
|
|||||||
|
Thu Sep 14 14:20:38 CEST 2000 Werner Koch <wk@openit.de>
|
||||||
|
|
||||||
|
* ring-a-party: Flush the last key.
|
||||||
|
|
||||||
Wed Jul 5 13:28:45 CEST 2000 Werner Koch <wk@>
|
Wed Jul 5 13:28:45 CEST 2000 Werner Koch <wk@>
|
||||||
|
|
||||||
* mail-signed-keys: New.
|
* mail-signed-keys: New.
|
||||||
|
|||||||
@ -31,6 +31,9 @@ BEGIN { FS=":"
|
|||||||
page = 0;
|
page = 0;
|
||||||
now = strftime("%b %d %H:%M %Y");
|
now = strftime("%b %d %H:%M %Y");
|
||||||
}
|
}
|
||||||
|
END {
|
||||||
|
if (any) myflush();
|
||||||
|
}
|
||||||
$1 == "pub" {
|
$1 == "pub" {
|
||||||
if( any ) myflush();
|
if( any ) myflush();
|
||||||
uidcount = 0;
|
uidcount = 0;
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
Thu Sep 14 14:20:38 CEST 2000 Werner Koch <wk@openit.de>
|
||||||
|
|
||||||
|
* miscutil.c (answer_is_yes_no_quit): Swapped order of yes/no test
|
||||||
|
so that no is returned for an empty input. By David Champion.
|
||||||
|
|
||||||
Wed Sep 6 17:55:47 CEST 2000 Werner Koch <wk@openit.de>
|
Wed Sep 6 17:55:47 CEST 2000 Werner Koch <wk@openit.de>
|
||||||
|
|
||||||
* iobuf.c: Use fopen64 insead of fopen when available.
|
* iobuf.c: Use fopen64 insead of fopen when available.
|
||||||
|
|||||||
@ -310,16 +310,16 @@ answer_is_yes_no_quit( const char *s )
|
|||||||
char *short_no = _("nN");
|
char *short_no = _("nN");
|
||||||
char *short_quit = _("qQ");
|
char *short_quit = _("qQ");
|
||||||
|
|
||||||
if( !stricmp(s, long_yes ) )
|
|
||||||
return 1;
|
|
||||||
if( !stricmp(s, long_no ) )
|
if( !stricmp(s, long_no ) )
|
||||||
return 0;
|
return 0;
|
||||||
|
if( !stricmp(s, long_yes ) )
|
||||||
|
return 1;
|
||||||
if( !stricmp(s, long_quit ) )
|
if( !stricmp(s, long_quit ) )
|
||||||
return -1;
|
return -1;
|
||||||
if( strchr( short_yes, *s ) && !s[1] )
|
|
||||||
return 1;
|
|
||||||
if( strchr( short_no, *s ) && !s[1] )
|
if( strchr( short_no, *s ) && !s[1] )
|
||||||
return 0;
|
return 0;
|
||||||
|
if( strchr( short_yes, *s ) && !s[1] )
|
||||||
|
return 1;
|
||||||
if( strchr( short_quit, *s ) && !s[1] )
|
if( strchr( short_quit, *s ) && !s[1] )
|
||||||
return -1;
|
return -1;
|
||||||
if( !stricmp(s, "yes" ) )
|
if( !stricmp(s, "yes" ) )
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user