-
-@c ==================================================================
-@node Security, The Protocol, The Connection, Technical information
-@section About tinc's encryption and other security-related issues.
-
-@cindex tinc
-@cindex Cabal
-tinc got its name from ``TINC,'' short for @emph{There Is No Cabal}; the
-alleged Cabal was/is an organization that was said to keep an eye on the
-entire Internet. As this is exactly what you @emph{don't} want, we named
-the tinc project after TINC.
-
-@cindex SVPN
-But in order to be ``immune'' to eavesdropping, you'll have to encrypt
-your data. Because tinc is a @emph{Secure} VPN (SVPN) daemon, it does
-exactly that: encrypt.
-
-This chapter is a mixture of ideas, reasoning and explanation, please
-don't take it too serious.
-
-@menu
-* Key Management::
-* Authentication::
-* Protection::
-@end menu
-
-
-@c ==================================================================
-@node Key Management, Authentication, Security, 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 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.
-
-@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, , 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.