diff options
| -rw-r--r-- | ChangeLog | 7 | ||||
| -rw-r--r-- | NEWS | 7 | ||||
| -rw-r--r-- | THANKS | 4 | ||||
| -rw-r--r-- | TODO | 8 | ||||
| -rw-r--r-- | VERSION | 2 | ||||
| -rw-r--r-- | acinclude.m4 | 28 | ||||
| -rw-r--r-- | cipher/ChangeLog | 5 | ||||
| -rw-r--r-- | cipher/random.c | 5 | ||||
| -rw-r--r-- | cipher/rndunix.c | 5 | ||||
| -rw-r--r-- | configure.in | 13 | ||||
| -rw-r--r-- | doc/ChangeLog | 5 | ||||
| -rw-r--r-- | doc/FAQ | 1007 | ||||
| -rw-r--r-- | doc/Makefile.am | 17 | ||||
| -rw-r--r-- | doc/faq.raw | 646 | ||||
| -rw-r--r-- | g10/ChangeLog | 14 | ||||
| -rw-r--r-- | g10/g10.c | 16 | ||||
| -rw-r--r-- | g10/main.h | 2 | ||||
| -rw-r--r-- | g10/misc.c | 13 | ||||
| -rw-r--r-- | tools/ChangeLog | 4 | ||||
| -rwxr-xr-x | tools/ring-a-party | 3 | ||||
| -rw-r--r-- | util/ChangeLog | 5 | ||||
| -rw-r--r-- | util/miscutil.c | 8 |
22 files changed, 1416 insertions, 408 deletions
@@ -1,3 +1,10 @@ +Thu Sep 14 14:20:38 CEST 2000 Werner Koch <[email protected]> + + * 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 <[email protected]> * configure.in: Check for fstat64 and fopen64 @@ -19,7 +19,12 @@ Noteworthy changes in the current CVS branch STABLE-BRANCH-1-0 * RSA is supported. Key generation does not yet work but will come 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) ---------------------------------------------- @@ -26,11 +26,12 @@ Christian Recktenwald [email protected] Daniel Eisenbud [email protected] Daniel Koening [email protected] Daniel Resare [email protected] -Detlef Lannert [email protected] Dave Dykstra [email protected] +David Champion [email protected] David Ellement [email protected] David Hallinan [email protected] David Mathog [email protected] +Detlef Lannert [email protected] Dimitri [email protected] Dirk Lattermann [email protected] Ed Boraas [email protected] @@ -67,6 +68,7 @@ Jeff Long [email protected] Jens Bachem [email protected] Jeroen C. van Gelderen [email protected] J Horacio MG [email protected] +J. Michael Ashley [email protected] Joachim Backes [email protected] John A. Martin [email protected] Johnny Teve�en [email protected] @@ -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. * 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. + [ Solved by re-introducing --trusted-key ] * Use DSA keys with the test suite. @@ -21,6 +22,8 @@ * Replace Valid/Invalid by Known/Unknown? + * Fix the bug in the mips assembler code + Scheduled for 1.1 ----------------- * 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. * 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 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 may break some scripts. + * Get new assembler stuff from gmgp 3.1 + Nice to have ------------ @@ -1,3 +1 @@ 1.0.2c - - diff --git a/acinclude.m4 b/acinclude.m4 index 259a3703e..a8303671b 100644 --- a/acinclude.m4 +++ b/acinclude.m4 @@ -30,7 +30,7 @@ AC_DEFUN(GNUPG_CHECK_TYPEDEF, dnl GNUPG_CHECK_GNUMAKE dnl AC_DEFUN(GNUPG_CHECK_GNUMAKE, - [ + [ if ${MAKE-make} --version 2>/dev/null | grep '^GNU ' >/dev/null 2>&1; then : else @@ -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 same as AC_LINK_FILES, but collect the files to link in diff --git a/cipher/ChangeLog b/cipher/ChangeLog index 7616fe521..7b73fb6a1 100644 --- a/cipher/ChangeLog +++ b/cipher/ChangeLog @@ -1,3 +1,8 @@ +Thu Sep 14 14:20:38 CEST 2000 Werner Koch <[email protected]> + + * 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 <[email protected]> * rsa.c (secret): Speed up by using the CRT. For a 2k keys this diff --git a/cipher/random.c b/cipher/random.c index be23ddd3e..02fc2ba3a 100644 --- a/cipher/random.c +++ b/cipher/random.c @@ -594,8 +594,11 @@ fast_random_poll() #endif #else { 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(); + add_randomness( &buf, sizeof buf, 1 ); memset( &buf, 0, sizeof buf ); } diff --git a/cipher/rndunix.c b/cipher/rndunix.c index 905ce9333..7a3d76d87 100644 --- a/cipher/rndunix.c +++ b/cipher/rndunix.c @@ -242,6 +242,7 @@ static struct RI { { "/usr/ucb/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", "-A", SC(0.3), NULL, 0, 0, 0, 0 }, /*QNX*/ { "/usr/bin/ipcs", "-a", SC(0.5), NULL, 0, 0, 0, 1 }, { "/bin/ipcs", "-a", SC(0.5), NULL, 0, 0, 0, 0 }, /* Unreliable source, depends on system usage */ @@ -290,6 +291,10 @@ static struct RI { /* This is a complex and screwball program. Some systems have things * like rX_dmn, x = integer, for RAID systems, but the statistics are * 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 /* The following aren't enabled since they're somewhat slow and not very * unpredictable, however they give an indication of the sort of sources diff --git a/configure.in b/configure.in index 2c8bfd362..9d23be5e9 100644 --- a/configure.in +++ b/configure.in @@ -159,7 +159,7 @@ AC_PROG_INSTALL AC_PROG_AWK 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) - +GNUPG_CHECK_FAQPROG MPI_OPT_FLAGS="" @@ -257,13 +257,13 @@ case "${target}" in *-openbsd*) NAME_OF_DEV_RANDOM="/dev/srandom" 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*) NAME_OF_DEV_RANDOM="/dev/random" 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*) @@ -275,7 +275,12 @@ case "${target}" in *) NAME_OF_DEV_RANDOM="/dev/random" NAME_OF_DEV_URANDOM="/dev/urandom" - DYNLINK_MOD_CFLAGS="-shared $CFLAGS_PIC" + # -shared is a gcc-ism. Find pic flags from GNUPG_CHECK_PIC. + if test -n "$GCC" ; then + DYNLINK_MOD_CFLAGS="-shared $CFLAGS_PIC" + else + DYNLINK_MOD_CFLAGS="$CFLAGS_PIC" + fi ;; esac AC_DEFINE_UNQUOTED(NAME_OF_DEV_RANDOM, "$NAME_OF_DEV_RANDOM") diff --git a/doc/ChangeLog b/doc/ChangeLog index ccff3b943..e708aeae3 100644 --- a/doc/ChangeLog +++ b/doc/ChangeLog @@ -1,3 +1,8 @@ +Thu Sep 14 14:20:38 CEST 2000 Werner Koch <[email protected]> + + * faq.raw: New. + * Makefile.am: Support to build FAQs + Wed Jul 12 13:32:06 CEST 2000 Werner Koch <wk@> * gpg.sgml: Add a note about the availability of the GPH. @@ -1,413 +1,660 @@ - 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, ... +GNUPG FREQUENTLY ASKED QUESTIONS + +Version: 0.1 +Last-Modified: Sep 14, 2000 +Maintained-by: Nils Ellmenreich <nils 'at' infosun.fmi.uni-passau.de> + +This is the GnuPG FAQ. The latest HTML version is available + here. <http://www.gnupg.org> + +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. + + + + 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? - Q: How does this whole thing work? - A: To generate a secret/public keypair, run + 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? - gpg --gen-key + 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. - and choose the default values. + 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? - 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. + 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? - 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. + 8. ACKNOWLEDGEMENTS - 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. +1. GENERAL - 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. +1.1) What is GnuPG? - 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. + 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. - 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 +1.2) Is GnuPG compatible with PGP? - gpg --fingerprint user-id + 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. - 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. +2. SOURCES OF INFORMATION - 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. +2.1) Where can I find more information? - 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). + Here's a list of on-line resources: - 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. + <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. - Q: What is the recommended key size? - A: 1024 bit for DSA signatures; even for plain ElGamal + *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 - 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, but you should than check the fingerprint of this key: "gpg --fingerprint --fingerprint <user ID>". - Q: Why are some signatures with an ELG-E key valid? - 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 +4.2) 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). + +4.3) 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. + +4.4) 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 *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 + + 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 + + gpg -r alice -o secret.txt -e test.txt + + If you write the options out in full, it is easier to read + + 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 ASCII-armored text in there, so you need to add the + --armor (-a) option, which doesn't take any arguments. + + gpg --armor --recipient alice --output secret.txt --encrypt test.txt + + If you imagine square brackets around the optional parts, it becomes + a bit clearer: + + gpg [--armor] [--recipient alice] [--output secret.txt] --encrypt test.txt + + The optional parts can be rearranged any way you want. + + 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 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". + + *The exception:* signing and encrypting at the same time. Use + gpg [--options] --sign --encrypt foo.txt + + +4.5) 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. + +4.6) 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. + +4.7) 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. + +4.8) 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". + +4.9) 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. + +4.10) 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. + +4.11) How can a get list of key IDs used to encrypt a message? + + gpg --batch --decrypt --list-only --status-fd 1 2>/dev/null + \ | awk '/^\[GNUPG:\] ENC_TO / { print $3 }' + +4.12) 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. + +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 + keyring itself. The suggested way to create the keys for the + automated environment is: + + On a secure machine: + 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) gpg --export-secret-subkeys --no-comment foo + >secring.auto Copy secring.auto and the public keyring to a + test directory. Cd to this directory. gpg --homedir + . --edit foo and use "passwd" to remove the pass-phrase from the + subkeys. You may also want to remove all unused subkeys. + copy secring.auto to a floppy and carry it to the target box + On the target machine: Install secring.auto as secret + keyring. 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. + + + +5. COMPATIBILITY ISSUES + + +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. - Q: Why is PGP 5.x not able to encrypt messages with some keys? - 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. - 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? - 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 ;-) - 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. +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 - Q: How does the whole trust thing work? - 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. + 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. - You can see the validity (calculated trust value) using this command. + Also thanks to Casper Dik for providing me with a script to generate + this FAQ (he uses it for the excellent Solaris2 FAQ). - 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). - - - 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 - - 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 - - gpg -r alice -o secret.txt -e test.txt - - If you write the options out in full, it is easier to read - - 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 - ASCII-armored text in there, so you need to add the --armor (-a) option, - which doesn't take any arguments. - - gpg --armor --recipient alice --output secret.txt --encrypt test.txt - - If you imagine square brackets around the optional parts, it becomes a bit - clearer: - - gpg [--armor] [--recipient alice] [--output secret.txt] --encrypt test.txt - - The optional parts can be rearranged any way you want. - - 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 - 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". - - ** the exception: signing and encrypting at the same time. Use - - gpg [--options] --sign --encrypt foo.txt - - - Q: What kind of output is this: "key C26EE891.298, uid 09FB: ...."? - A: 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: What is 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? - A: 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 (..//..). - - - Q: How do I sign a patch file? - A: 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? - A: 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? - A: 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? - A: 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 do I transfer owner trust values from PGP to GnuPG? - 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 - material? - 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? - 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: 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? - A: You should use the option --batch and don't use passphrases 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: - 1. If you want to do automatic signing, create a signing subkey - for your key (edit menu, choose "addkey" and the DSA). - 2. Make sure that you use a passphrase (Needed by the current - implementation) - 3. gpg --export-secret-subkeys --no-comment foo >secring.auto - 4. Copy secring.auto and the public keyring to a test directory. - 5. Cd to this directory. - 6. gpg --homedir . --edit foo - and use "passwd" to remove the passphrase from the subkeys. - You may also want to remove all unused subkeys. - 7. copy secring.auto to a floppy and carry it to the - target box - On the target machine: - 8. Install secring.auto as secret keyring. - 9. 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. - - 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 - A: Update to GnuPG 1.0.2 +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. diff --git a/doc/Makefile.am b/doc/Makefile.am index 44a92d2f9..ab5d1294a 100644 --- a/doc/Makefile.am +++ b/doc/Makefile.am @@ -1,9 +1,12 @@ ## 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 +pkgdata_DATA = FAQ faq.html + %.1 : %.sgml if HAVE_DOCBOOK_TO_MAN @@ -15,6 +18,12 @@ else endif +FAQ : faq.raw + $(FAQPROG) -f $< $@ || $(FAQPROG) -f $< $@ + +faq.html : faq.raw + $(FAQPROG) -h -f $< $@ 2>&1 || $(FAQPROG) -h -f $< $@ + %.dvi: %.sgml db2dvi $< @@ -29,3 +38,9 @@ dist-hook: @if test `wc -c < gpg.1` -lt 200; then \ echo 'ERROR: dummy man page'; false; fi + + + + + + diff --git a/doc/faq.raw b/doc/faq.raw new file mode 100644 index 000000000..307284b6a --- /dev/null +++ b/doc/faq.raw @@ -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. diff --git a/g10/ChangeLog b/g10/ChangeLog index 4dd7ad675..b82b7d9f9 100644 --- a/g10/ChangeLog +++ b/g10/ChangeLog @@ -1,3 +1,17 @@ +Thu Sep 14 14:20:38 CEST 2000 Werner Koch <[email protected]> + + * 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 <[email protected]> * keyedit.c (keyedit_menu): Allow to use "debug" on the secret key. @@ -580,6 +580,7 @@ main( int argc, char **argv ) char **orig_argv; const char *fname; char *username; + int may_coredump; STRLIST sl, remusr= NULL, locusr=NULL; STRLIST nrings=NULL, sec_nrings=NULL; armor_filter_context_t afx; @@ -613,7 +614,7 @@ main( int argc, char **argv ) */ log_set_name("gpg"); secure_random_alloc(); /* put random number into secure memory */ - disable_core_dumps(); + may_coredump = disable_core_dumps(); init_signals(); create_dotlock(NULL); /* register locking cleanup */ i18n_init(); @@ -624,8 +625,8 @@ main( int argc, char **argv ) opt.def_digest_algo = 0; opt.def_compress_algo = 2; opt.s2k_mode = 3; /* iterated+salted */ - opt.s2k_digest_algo = DIGEST_ALGO_RMD160; - opt.s2k_cipher_algo = CIPHER_ALGO_BLOWFISH; + opt.s2k_digest_algo = DIGEST_ALGO_SHA1; + opt.s2k_cipher_algo = CIPHER_ALGO_CAST5; opt.completes_needed = 1; opt.marginals_needed = 3; 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 oOutput: opt.outfile = pargs.r.ret_str; 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 oInteractive: opt.interactive = 1; break; case oVerbose: g10_opt_verbose++; @@ -853,7 +854,7 @@ main( int argc, char **argv ) opt.def_cipher_algo = 0; opt.def_digest_algo = 0; opt.def_compress_algo = 1; - opt.s2k_mode = 3; /* iterated+salted */ + opt.s2k_mode = 3; /* iterated+salted */ opt.s2k_digest_algo = DIGEST_ALGO_SHA1; opt.s2k_cipher_algo = CIPHER_ALGO_CAST5; break; @@ -964,6 +965,11 @@ main( int argc, char **argv ) log_info("used in a production environment or with production keys!\n"); } #endif + + if( may_coredump && !opt.quiet ) + log_info(_("WARNING: program may create a core file!\n")); + + if (opt.no_literal) { log_info(_("NOTE: %s is not for normal use!\n"), "--no-literal"); if (opt.textmode) diff --git a/g10/main.h b/g10/main.h index 54e68db18..13178c735 100644 --- a/g10/main.h +++ b/g10/main.h @@ -54,7 +54,7 @@ char *make_radix64_string( const byte *data, size_t len ); /*-- misc.c --*/ void trap_unaligned(void); -void disable_core_dumps(void); +int disable_core_dumps(void); u16 checksum_u16( unsigned n ); u16 checksum( byte *p, unsigned n ); u16 checksum_mpi( MPI a ); diff --git a/g10/misc.c b/g10/misc.c index 1e4f4916d..9669af574 100644 --- a/g10/misc.c +++ b/g10/misc.c @@ -79,22 +79,23 @@ trap_unaligned(void) #endif -void +int disable_core_dumps() { - #ifndef HAVE_DOSISH_SYSTEM + #ifdef HAVE_DOSISH_SYSTEM + return 0; + #else #ifdef HAVE_SETRLIMIT struct rlimit limit; limit.rlim_cur = 0; limit.rlim_max = 0; if( !setrlimit( RLIMIT_CORE, &limit ) ) - return; - if( errno != EINVAL ) + return 0; + if( errno != EINVAL && errno != ENOSYS ) log_fatal(_("can't disable core dumps: %s\n"), strerror(errno) ); #endif - if( !opt.quiet ) - log_info(_("WARNING: program may create a core file!\n")); + return 1; #endif } diff --git a/tools/ChangeLog b/tools/ChangeLog index dbd879b43..2050b4e90 100644 --- a/tools/ChangeLog +++ b/tools/ChangeLog @@ -1,3 +1,7 @@ +Thu Sep 14 14:20:38 CEST 2000 Werner Koch <[email protected]> + + * ring-a-party: Flush the last key. + Wed Jul 5 13:28:45 CEST 2000 Werner Koch <wk@> * mail-signed-keys: New. diff --git a/tools/ring-a-party b/tools/ring-a-party index 561b51336..26c055622 100755 --- a/tools/ring-a-party +++ b/tools/ring-a-party @@ -31,6 +31,9 @@ BEGIN { FS=":" page = 0; now = strftime("%b %d %H:%M %Y"); } +END { + if (any) myflush(); +} $1 == "pub" { if( any ) myflush(); uidcount = 0; diff --git a/util/ChangeLog b/util/ChangeLog index 42c77bfe9..8be8f3fb8 100644 --- a/util/ChangeLog +++ b/util/ChangeLog @@ -1,3 +1,8 @@ +Thu Sep 14 14:20:38 CEST 2000 Werner Koch <[email protected]> + + * 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 <[email protected]> * iobuf.c: Use fopen64 insead of fopen when available. diff --git a/util/miscutil.c b/util/miscutil.c index 0b87f1b84..ed2915ef1 100644 --- a/util/miscutil.c +++ b/util/miscutil.c @@ -310,16 +310,16 @@ answer_is_yes_no_quit( const char *s ) char *short_no = _("nN"); char *short_quit = _("qQ"); - if( !stricmp(s, long_yes ) ) - return 1; if( !stricmp(s, long_no ) ) return 0; + if( !stricmp(s, long_yes ) ) + return 1; if( !stricmp(s, long_quit ) ) return -1; - if( strchr( short_yes, *s ) && !s[1] ) - return 1; if( strchr( short_no, *s ) && !s[1] ) return 0; + if( strchr( short_yes, *s ) && !s[1] ) + return 1; if( strchr( short_quit, *s ) && !s[1] ) return -1; if( !stricmp(s, "yes" ) ) |