diff options
Diffstat (limited to 'doc/FAQ')
| -rw-r--r-- | doc/FAQ | 263 |
1 files changed, 263 insertions, 0 deletions
diff --git a/doc/FAQ b/doc/FAQ new file mode 100644 index 000000000..62003e2ec --- /dev/null +++ b/doc/FAQ @@ -0,0 +1,263 @@ + 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 usefull 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 usefull 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 chnage the passphrase from time + to time and decrease the risk, that many old messages may be decryptted 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 usefull, 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 + taht 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 methos is to use + a MIME aware mail reader (Mutt, Pine and many more). + + There is a small security glitch in the OpenPGP (and therefor 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 keyssize is larger + than 1024 bits. Encryption keys may have greater sizes, + but you should than check the fingerprint of this key. + + 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 my public key. + A: PGP Inc refuses to accept ElGamal keys of type 20 even for + encryption. They only supports type 16 (which are identical + at least for decryption). To be better interoperable, 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 choosen. You may add an type 16 ElGamal key to your public + key which is easy as your key signatures are still valid. + + Q: I can't delete a 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 so complicated + do to it anyway: Create a new user id with exactly the same name, + you will notice that there are two identical user ids on the + secret ring now. Now select this user id and delete it; both + user ids from the secret ring will be remoed. + + Q: How can I encrypt a message in way pgp 2.x is able to decrypt it later? + 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 ... + + 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 --no-comment myfile + + You may replace "3des" by "cast5"; "blowfish" does not work with + all versions of pgp5. You may also want to put + no-comment + compress-algo 1 + into your ~/.gnupg/options file - this does not affect the 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 commited 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, + capslock keys, as these keys do not produce any 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, your secret key and trust your Root. + + When I check gnupg on a remote system via ssh (I have no Alpha here ;-) + I have the same problem too: it takes *very* long 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. I have plans to use a cache for calculated + trust values to speed up calcualtion. + + You can see the calculated trust value using this command: + + gpgm --list-keys --with-colons + + If the first field is "pub", 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. + + You can get a list of the assigned ownertrust values (how far you trust + the owner to correctly sign another another ones key) + + gpgm --list-ownertrust + + The first field is the fingerprint of the primary key, the second one + the assigned value: + + - = No Ownertrust value yet assigned. + n = Never trust this keyholder to correctly verifiy 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. + + Please keep these values confidential, as they express some opiones of + you about others. PGP does store these information with the keyring, so + it is not a good idea to publish the keyring instead of exporting the + keyring - gnupg stores the trust in the trust-DB and therefor it is okay + to give the keyring away (but we have a --export command too). + + + Q: What is the differenc 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 which 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 --remote-user (-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 --remote-user 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 --remote-user alice --output secret.txt --encrypt test.txt + + If you imagine square brackets around the optional parts, it becomes a bit + clearer: + + gpg [--armor] [--remote-user alice] [--output secret.txt] --encrypt test.txt + + The optional parts can be rearranged any way you want: + + gpg --output secret.txt --remote-user 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 + + + +[That's it for now.)] |