1 This is the security documentation for tinc, a Virtual Private Network daemon.
3 Copyright 2000 Guus Sliepen <guus@sliepen.warande.net>,
4 2000 Ivo Timmmermans <itimmermans@bigfoot.com>
6 Permission is granted to make and distribute verbatim copies of
7 this documentation provided the copyright notice and this
8 permission notice are preserved on all copies.
10 Permission is granted to copy and distribute modified versions of
11 this documentation under the conditions for verbatim copying,
12 provided that the entire resulting derived work is distributed
13 under the terms of a permission notice identical to this one.
15 $Id: SECURITY,v 1.1.2.1 2000/09/17 19:57:39 guus Exp $
21 Authentication in tinc will be done in a way that is very similar to the way
22 the SSH (Secure SHell) authentication protocol works. It is based on public
25 Every tinc host has it's own public/private key pair. Suppose there are two
26 tinc hosts, A and B. If A and B trust each other, they store a copy of
27 eachothers public key (in the same way passphrases were stored in versions
28 of tinc <= 1.0pre2). They know these public keys beforehand, and the origin
29 of the public keys has to be known for sure.
31 To make sure that when a connection is made from A to B that B knows A is
32 really who he claims to be, B encrypts a totally random string of bytes with
33 A's public key. B also calculates the hash value from the unencrypted random
34 string. B then sends the encrypted string to A. A then has to decrypt the
35 string, calculate the hash value from that string and send it back to B. Since
36 only he who possesses A's private key can decrypt this string, only he can send
37 back the correct hash value. So, if B receives the same hash value he
38 calculated himself, he knows for sure A is A.
40 Both SSH and tinc use RSA for the public key cryptography. SSH uses MD5 as a
41 secure hash algorithm, tinc uses SHA1. The reason for our choice of SHA1 is
42 the fact that SHA1 is 160 bits instead of 128 (MD5), which makes brute force
43 attacks harder. Also, the OpenSSL documentation recommends SHA1.
48 The rest of the meta connection in tinc will be encrypted with a symmetric
49 block cipher, since RSA is not really suited for this. When a connection is
50 made, both sides have to agree on a key for this block cipher. To make sure
51 that this key exchange is also done securely, and no man-in-the-middle attack
52 is possible, RSA would be the best choice for exchanging keys.
54 Instead of doing RSA encryption again, tinc will use a part of the random
55 string that was exchanged during the authentication phase as the key for the
56 symmetric cipher. Some symmetric ciphers require a random initialisation vector
57 for improved security. This vector can be taken from the random string as well.
59 Is this secure? I (Guus Sliepen) think at this moment that it is:
61 - Since the random string cannot be decrypted by anyone eavesdropping or
62 playing man-in-the-middle, the symmetric key cannot be known by sniffing.
63 - The unencrypted returned hash value is supposed to be cryptographically
64 secure. Furthermore, it can only at most give a way 160 bits of information
65 from the complete random string which is longer than the key for the
66 symmetric cipher, so very few bits will actualy contain information about
67 the symmetric cipher key alone, if any.
68 - If the RSA encryption is cracked, the rest of the communications can be
70 - If the symmetric cipher encryption is cracked without using the information
71 from the encrypted random strings or the hash values, this still won't give
72 the full plaintext for the random string, so it won't facilitate a known-
73 plaintext attack on the RSA encryption.
74 - RSA and symmetric ciphers are fundamentally different. It is very unlikely
75 that the overlap of both will create any interference that will facilitate
76 an easier-than-brute-force attack.
78 Other options for key exchange could be:
80 * A second exchange of RSA encrypted random strings.
81 This is equal to the former scheme just without knowing the hash value of
82 the unecrypted random string.
84 * Diffie-Hellman with RSA signing.
85 This should be very secure, but there are a lot of pitholes with using both
86 encryption with public keys and private keys together with the same keypair.
88 * Diffie-Hellman with passphrases.
89 This is what tinc <= 1.0pre2 used to do. Passphrases are secret, exchanging
90 them must be done with great care, nobody may eavesdrop. Exchanging public
91 keys on the other hand is much safer, everybody may eavesdrop, just as long
92 as you are sure that the public key itself belongs to the right owner.
projects / tinc / blob