windoze version works again

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.)]