-@node Encryption, Key Management, Security, Security
-@subsection Encryption
-
-Encryption algorithms come in lots of flavors, most of which are not
-safe enough to use on the Internet, if at all. Algorithms that we've
-considered using are: RSA, blowfish, twofish and IDEA.
-
-@itemize @bullet
-@item
-@cindex RSA
-@emph{RSA} is patented. A fee must be paid if you use it, so it can't
-be used in an Open Source program.
-
-@item
-@cindex blowfish
-@emph{blowfish} was the standard encryption method at least up to version
-0.2.23, but as Dekan pointed out, it may not be all that secure. It is
-also patented, but it may be used freely.
-
-@item
-@cindex twofish
-@emph{twofish} should be better, but i've not seen a useable
-ready-to-use implementation somewhere out of the US. I'll remember this
-as a future encryption method.
-
-@item
-@cindex IDEA
-@emph{IDEA} is patented, and free for non-commercial use. It is going to
-be the standard encryption method.
-
-@end itemize
-
-You may choose any of the last three encryption methods in tinc. Please
-note, however, that ALL computers on your VPN must currenttly use the
-same. This should (among other things) be more flexible, tinc could for
-instance load a new encryption library the minute it is needed.
-
-
-@c ==================================================================
-@node Key Management, Authentification, Encryption, Security
-@subsection Key Management
-@c FIXME: recheck
-
-@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.
-
-These private keys are generated upon startup, and they are not changed
-while the connection exists. A possible feature in the future is to
-dynamically change the keys, every hour for example.
-
-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 Authentification, Protection, Key Management, Security
-@subsection Authentification
-@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 authentification
-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.
-
-@cindex passphrase
-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/vpn/passphrases}.
-
-The only thing that needs to be taken care of is how A announces its
-passphrase to B.
-
-
-@c ==================================================================
-@node Protection, , Authentification, 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 ==================================================================
-@node The Protocol, , Security, Technical information
-@section Detailed protocol specifications
-
-
-
-@menu
-* Data protocol::
-* Meta protocol::
-@end menu
-
-@c ==================================================================
-@node Data protocol, Meta protocol, The Protocol, The Protocol
-@subsection The data protocol
-
-The data that is sent through the UDP connection is formatted as follows:
-
-@example
-
- bytes | Contents
-----------------------
- 0-1 | The length of this packet, including all leading fields
- 2-5 | The destination IP address
- 6-... | The encrypted data
-
-@end example
-
-The method that was used to encrypt the data should be made known via
-the meta-protocol, during early identification stages.
-
-
-@c ==================================================================
-@node Meta protocol, , Data protocol, The Protocol
-@subsection The Meta protocol
-
-This protocol consists of separate packets of enformation, that are
-generally formatted thusly:
-
-@example
-
- bytes | Contents
-----------------------
- 0 | The request ID
- 1-... | (Optional: arguments)
-
-@end example
-
-What follows is a listing of possible request IDs.