-@menu
-* Key Types::
-* Key Management::
-* Authentication::
-* Protection::
-@end menu
-
-@c ==================================================================
-@node Key Types, Key Management, Security, Security
-@subsection Key Types
-@c FIXME: check if I'm not talking nonsense
-
-There are several types of encryption keys. Tinc uses two of them,
-symmetric private keypairs and public/private keypairs.
-
-Public/private keypairs are used in public key cryptography. It enables
-someone to send out a public key with which other people can encrypt their
-data. The encrypted data now can only be decrypted by the person who has
-the private key that matches the public key. So, a public key only allows
-@emph{other} people to send encrypted messages to you. This is very useful
-in setting up private communications channels. Just send out your public key
-and other people can talk to you in a secure way. But how can you know
-the other person is who he says he is?
-
-For authentication itself tinc uses symmetric private keypairs, referred
-to as a passphrase. The identity of each tinc daemon is defined by it's
-passphrase (like you can be identified by your social security number).
-Every tinc daemon that is allowed to connect to you has a copy of your
-passphrase (hence symmetrical).
-
-It would also be possible to use public/private keypairs for authentication,
-so that you could shout out your public key and don't need to keep it
-secret (like the passphrase you would have to send to someone else). Also,
-no one else has to know a private key from you.
-Both forms have their pros and cons, and at the moment tinc just uses passphrases
-(which are computationaly more efficient and perhaps in some way more
-secure).
-
-@c ==================================================================
-@node Key Management, Authentication, Key Types, Security
-@subsection Key Management
-@c FIXME change for the current protocol
-
-@cindex Diffie-Hellman
-You can't just send a private encryption key to your peer, because
-somebody else might already be listening to you. So you'll have to
-negotiate over a shared but secret key. One way to do this is by using
-the ``Diffie-Hellman key exchange'' protocol
-(@uref{http://www.rsa.com/rsalabs/faq/html/3-6-1.html}). The idea is as
-follows.
-
-You have two participants A and B that want to agree over a shared
-secret encryption key. Both parties have some large prime number p and a
-generator g. These numbers may be known to the outside world, and hence
-may be included in the source distribution.
-
-@cindex secret key
-Both parties then generate a secret key. A generates a, and computes g^a
-mod p. This is then sent to B; while B computes g^b mod p, and transmits
-this to A, b being generated by B. Both a and b must be smaller than
-p-1.
-
-Both parties then calculate g^ab mod p = k. k is the new, shared, but
-still secret key.
-
-To obtain a key k of a sufficient length (128 bits in our vpnd), p
-should be 2^129-1 or more.
-
-
-@c ==================================================================
-@node Authentication, Protection, Key Management, Security
-@subsection Authentication
-@c FIXME: recheck
-
-@cindex man-in-the-middle attack
-Because the Diffie-Hellman protocol is in itself vulnerable to the
-``man-in-the-middle attack,'' we should introduce an authentication
-system.
-
-We will let A transmit a passphrase that is also known to B encrypted
-with g^a, before A sends this to B. This way, B can check whether A is
-really A or just someone else.
-B will never receive the real passphrase though, because it was
-encrypted using public/private keypairs. This way there is no way an
-imposter could steal A's passphrase.
-
-@cindex passphrase
-@c ehrmz... but we only use 1024 bits passphrases ourselves? [guus]
-This passphrase should be 2304 bits for a symmetric encryption
-system. But since an asymmetric system is more secure, we could do with
-2048 bits. This only holds if the passphrase is very random.
-
-These passphrases could be stored in a file that is non-readable by
-anyone else but root; e.g. @file{/etc/tinc/passphrases} with UID 0
-and permissions mode 700.
-
-The only thing that needs to be taken care of is how A can securely send
-a copy of it's passphrase to B if B doesn't have it yet. This could be
-done via mail with PGP, but you should be really convinced of the
-identity of the person who owns the email address you are sending this to.
-Swapping floppy disks in real life might be the best way to do this!
-
-
-@c ==================================================================
-@node Protection, , Authentication, Security
-@subsection Protecting your data
-
-Now we have securely hidden our data. But a malicious cracker may still
-bother you by randomly altering the encrypted data he intercepts.
-
-@c FIXME what the hell is this all about? remove? IT