From 2863134a4113b7805a662f45a21a1be0ae9606cb Mon Sep 17 00:00:00 2001 From: Guus Sliepen Date: Sun, 17 Sep 2000 19:57:39 +0000 Subject: [PATCH] Added document about the used cryptographic algorithms and the reasons behind them. Feel very free to comment on this! --- doc/SECURITY | 92 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 92 insertions(+) create mode 100644 doc/SECURITY diff --git a/doc/SECURITY b/doc/SECURITY new file mode 100644 index 00000000..a885b46d --- /dev/null +++ b/doc/SECURITY @@ -0,0 +1,92 @@ +This is the security documentation for tinc, a Virtual Private Network daemon. + + Copyright 2000 Guus Sliepen , + 2000 Ivo Timmmermans + + Permission is granted to make and distribute verbatim copies of + this documentation provided the copyright notice and this + permission notice are preserved on all copies. + + Permission is granted to copy and distribute modified versions of + this documentation under the conditions for verbatim copying, + provided that the entire resulting derived work is distributed + under the terms of a permission notice identical to this one. + + $Id: SECURITY,v 1.1.2.1 2000/09/17 19:57:39 guus Exp $ + + +1. Authentication +------------------ + +Authentication in tinc will be done in a way that is very similar to the way +the SSH (Secure SHell) authentication protocol works. It is based on public +key cryptography. + +Every tinc host has it's own public/private key pair. Suppose there are two +tinc hosts, A and B. If A and B trust each other, they store a copy of +eachothers public key (in the same way passphrases were stored in versions +of tinc <= 1.0pre2). They know these public keys beforehand, and the origin +of the public keys has to be known for sure. + +To make sure that when a connection is made from A to B that B knows A is +really who he claims to be, B encrypts a totally random string of bytes with +A's public key. B also calculates the hash value from the unencrypted random +string. B then sends the encrypted string to A. A then has to decrypt the +string, calculate the hash value from that string and send it back to B. Since +only he who possesses A's private key can decrypt this string, only he can send +back the correct hash value. So, if B receives the same hash value he +calculated himself, he knows for sure A is A. + +Both SSH and tinc use RSA for the public key cryptography. SSH uses MD5 as a +secure hash algorithm, tinc uses SHA1. The reason for our choice of SHA1 is +the fact that SHA1 is 160 bits instead of 128 (MD5), which makes brute force +attacks harder. Also, the OpenSSL documentation recommends SHA1. + +2. Key exchange +---------------- + +The rest of the meta connection in tinc will be encrypted with a symmetric +block cipher, since RSA is not really suited for this. When a connection is +made, both sides have to agree on a key for this block cipher. To make sure +that this key exchange is also done securely, and no man-in-the-middle attack +is possible, RSA would be the best choice for exchanging keys. + +Instead of doing RSA encryption again, tinc will use a part of the random +string that was exchanged during the authentication phase as the key for the +symmetric cipher. Some symmetric ciphers require a random initialisation vector +for improved security. This vector can be taken from the random string as well. + +Is this secure? I (Guus Sliepen) think at this moment that it is: + +- Since the random string cannot be decrypted by anyone eavesdropping or + playing man-in-the-middle, the symmetric key cannot be known by sniffing. +- The unencrypted returned hash value is supposed to be cryptographically + secure. Furthermore, it can only at most give a way 160 bits of information + from the complete random string which is longer than the key for the + symmetric cipher, so very few bits will actualy contain information about + the symmetric cipher key alone, if any. +- If the RSA encryption is cracked, the rest of the communications can be + decrypted anyway. +- If the symmetric cipher encryption is cracked without using the information + from the encrypted random strings or the hash values, this still won't give + the full plaintext for the random string, so it won't facilitate a known- + plaintext attack on the RSA encryption. +- RSA and symmetric ciphers are fundamentally different. It is very unlikely + that the overlap of both will create any interference that will facilitate + an easier-than-brute-force attack. + +Other options for key exchange could be: + +* A second exchange of RSA encrypted random strings. + This is equal to the former scheme just without knowing the hash value of + the unecrypted random string. + +* Diffie-Hellman with RSA signing. + This should be very secure, but there are a lot of pitholes with using both + encryption with public keys and private keys together with the same keypair. + +* Diffie-Hellman with passphrases. + This is what tinc <= 1.0pre2 used to do. Passphrases are secret, exchanging + them must be done with great care, nobody may eavesdrop. Exchanging public + keys on the other hand is much safer, everybody may eavesdrop, just as long + as you are sure that the public key itself belongs to the right owner. -- 2.20.1