+
+Security statement
+------------------
+
+In August 2000, we discovered the existence of a security hole in all versions
+of tinc up to and including 1.0pre2. This had to do with the way we exchanged
+keys. Since then, we have been working on a new authentication scheme to make
+tinc as secure as possible. The current version uses the OpenSSL library and
+uses strong authentication with RSA keys.
+
+On the 29th of December 2001, Jerome Etienne posted a security analysis of tinc
+1.0pre4. Due to a lack of sequence numbers and a message authentication code
+for each packet, an attacker could possibly disrupt certain network services or
+launch a denial of service attack by replaying intercepted packets. The current
+version adds sequence numbers and message authentication codes to prevent such
+attacks.
+
+On September the 15th of 2003, Peter Gutmann contacted us and showed us a
+writeup describing various security issues in several VPN daemons. He showed
+that tinc lacks perfect forward security, the connection authentication could
+be done more properly, that the sequence number we use as an IV is not the best
+practice and that the default length of the HMAC for packets is too short in
+his opinion. We do not know of a way to exploit these weaknesses, but these
+issues are being addressed in the tinc 1.1 branch.
+
+The Sweet32 attack affects versions of tinc prior to 1.0.30.
+
+On September 6th, 2018, Michael Yonly contacted us and provided
+proof-of-concept code that allowed a remote attacker to create an
+authenticated, one-way connection with a node, and also that there was a
+possibility for a man-in-the-middle to force UDP packets from a node to be sent
+in plaintext. The first issue was trivial to exploit on tinc versions prior to
+1.0.30, but the changes in 1.0.30 to mitigate the Sweet32 attack made this
+weakness much harder to exploit. These issues have been fixed in tinc 1.0.35.
+The new protocol in the tinc 1.1 branch is not susceptible to these issues.
+
+Cryptography is a hard thing to get right. We cannot make any
+guarantees. Time, review and feedback are the only things that can
+prove the security of any cryptographic product. If you wish to review
+tinc or give us feedback, you are strongly encouraged to do so.
+
+
+Compatibility
+-------------
+
+Version 1.0.35 is compatible with 1.0pre8, 1.0 and later, but not with older
+versions of tinc. Note that since version 1.0.30, tinc requires all nodes in
+the VPN to be compiled with a version of LibreSSL or OpenSSL that supports the
+AES256 and SHA256 algorithms.
+
+
+Requirements
+------------
+
+The OpenSSL library is used for all cryptographic functions. You can find it at
+https://www.openssl.org/. You will need version 1.0.1 or later with support for
+AES256 and SHA256 enabled. If this library is not installed on your system, the
+configure script will fail. The manual in doc/tinc.texi contains more detailed
+information on how to install this library. Alternatively, you may also use the
+LibreSSL library.
+
+The zlib library is used for optional compression. You can
+find it at https://zlib.net/. Because of a possible exploit in
+earlier versions we recommend that you download version 1.1.4 or later.
+
+The LZO library is also used for optional compression. You can
+find it at https://www.oberhumer.com/opensource/lzo/.
+
+In order to compile tinc, you will need a C99 compliant compiler.
+
+
+Features
+--------