diff options
Diffstat (limited to 'doc/FAQ')
| -rw-r--r-- | doc/FAQ | 352 |
1 files changed, 0 insertions, 352 deletions
diff --git a/doc/FAQ b/doc/FAQ deleted file mode 100644 index 788b85751..000000000 --- a/doc/FAQ +++ /dev/null @@ -1,352 +0,0 @@ - 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? - A: 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. - - - Q: What is the recommended key size? - A: 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 - 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 - 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; - other wise, 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 it's 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. - - - 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. - - 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). - - - 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 signater 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 modern signatures, to tell the parser which - hash algorithm to use. - - |