-This new scheme has several improvements, both in efficiency and security.
-
-First of all, the server sends exactly the same kind of messages over the wire
-as the client. The previous versions of tinc first authenticated the client,
-and then the server. This scheme even allows both sides to send their messages
-simultaneously, there is no need to wait for the other to send something first.
-This means that any calculations that need to be done upon sending or receiving
-a message can also be done in parallel. This is especially important when doing
-RSA encryption/decryption. Given that these calculations are the main part of
-the CPU time spent for the authentication, speed is improved by a factor 2.
-
-Second, only one RSA encrypted message is sent instead of two. This reduces the
-amount of information attackers can see (and thus use for a cryptographic
-attack). It also improves speed by a factor two, making the total speedup a
-factor 4.
-
-Third, and most important:
-The symmetric cipher keys are exchanged first, the challenge is done
-afterwards. In the previous authentication scheme, because a man-in-the-middle
-could pass the challenge/chal_reply phase (by just copying the messages between
-the two real tinc daemons), but no information was exchanged that was really
-needed to read the rest of the messages, the challenge/chal_reply phase was of
-no real use. The man-in-the-middle was only stopped by the fact that only after
-the ACK messages were encrypted with the symmetric cipher. Potentially, it
-could even send it's own symmetric key to the server (if it knew the server's
-public key) and read some of the metadata the server would send it (it was
-impossible for the mitm to read actual network packets though). The new scheme
-however prevents this.
-
-This new scheme makes sure that first of all, symmetric keys are exchanged. The
-rest of the messages are then encrypted with the symmetric cipher. Then, each
-side can only read received messages if they have their private key. The
-challenge is there to let the other side know that the private key is really
-known, because a challenge reply can only be sent back if the challenge is
-decrypted correctly, and that can only be done with knowledge of the private
-key.
-
-Fourth: the first thing that is sent via the symmetric cipher encrypted
-connection is a totally random string, so that there is no known plaintext (for
-an attacker) in the beginning of the encrypted stream.
+This legacy authentication protocol has several weaknesses, pointed out by security export Peter Gutmann.
+First, data is encrypted with RSA without padding.
+Padding schemes are designed to prevent attacks when the size of the plaintext is not equal to the size of the RSA key.
+Tinc always encrypts random nonces that have the same size as the RSA key, so we do not believe this leads to a break of the security.
+There might be timing or other side-channel attacks against RSA encryption and decryption, tinc does not employ any protection against those.
+Furthermore, both sides send identical messages to each other, there is no distinction between server and client,
+which could make a MITM attack easier.
+However, no exploit is known in which a third party who is not already trusted by other nodes in the VPN could gain access.
+Finally, the RSA keys are used to directly encrypt the session keys, which means that if the RSA keys are compromised, it is possible to decrypt all previous VPN traffic.
+In other words, the legacy protocol does not provide perfect forward secrecy.
+
+@c ==================================================================
+@node Simple Peer-to-Peer Security
+@subsection Simple Peer-to-Peer Security
+@cindex SPTPS
+
+The SPTPS protocol is designed to address the weaknesses in the legacy protocol.
+SPTPS is based on TLS 1.2, but has been simplified: there is no support for exchanging public keys, and there is no cipher suite negotiation.
+Instead, SPTPS always uses a very strong cipher suite:
+peers authenticate each other using 521 bits ECC keys,
+Diffie-Hellman using ephemeral 521 bits ECC keys is used to provide perfect forward secrecy (PFS),
+AES-256-CTR is used for encryption, and HMAC-SHA-256 for message authentication.
+
+Similar to TLS, messages are split up in records.
+A complete logical record contains the following information:
+
+@itemize
+@item uint32_t seqno (network byte order)
+@item uint16_t length (network byte order)
+@item uint8_t type
+@item opaque data[length]
+@item opaque hmac[HMAC_SIZE] (HMAC over all preceding fields)
+@end itemize
+
+Depending on whether SPTPS records are sent via TCP or UDP, either the seqno or the length field is omitted on the wire
+(but they are still included in the calculation of the HMAC);
+for TCP packets are guaranteed to arrive in-order so we can infer the seqno, but packets can be split or merged, so we still need the length field to determine the boundaries between records;
+for UDP packets we know that there is exactly one record per packet, and we know the length of a packet, but packets can be dropped, duplicated and/or reordered, so we need to include the seqno.
+
+The type field is used to distinguish between application records or handshake records.
+Types 0 to 127 are application records, type 128 is a handshake record, and types 129 to 255 are reserved.
+
+Before the initial handshake, no fields are encrypted, and the HMAC field is not present.
+After the authentication handshake, the length (if present), type and data fields are encrypted, and the HMAC field is present.
+For UDP packets, the seqno field is not encrypted, as it is used to determine the value of the counter used for encryption.
+
+The authentication consists of an exchange of Key EXchange, SIGnature and ACKnowledge messages, transmitted using type 128 records.
+
+Overview:
+
+@example
+Initiator Responder
+---------------------
+KEX ->
+ <- KEX
+SIG ->
+ <- SIG
+
+...encrypt and HMAC using session keys from now on...
+
+App ->
+ <- App
+...
+ ...
+
+...key renegotiation starts here...
+
+KEX ->
+ <- KEX
+SIG ->
+ <- SIG
+ACK ->
+ <- ACK
+
+...encrypt and HMAC using new session keys from now on...
+
+App ->
+ <- App
+...
+ ...
+---------------------
+@end example
+
+Note that the responder does not need to wait before it receives the first KEX message,
+it can immediately send its own once it has accepted an incoming connection.
+
+Key EXchange message:
+
+@itemize
+@item uint8_t kex_version (always 0 in this version of SPTPS)
+@item opaque nonce[32] (random number)
+@item opaque ecdh_key[ECDH_SIZE]
+@end itemize
+
+SIGnature message:
+
+@itemize
+@item opaque ecdsa_signature[ECDSA_SIZE]
+@end itemize
+
+ACKnowledge message:
+
+@itemize
+@item empty (only sent after key renegotiation)
+@end itemize
+
+Remarks:
+
+@itemize
+@item At the start, both peers generate a random nonce and an Elliptic Curve public key and send it to the other in the KEX message.
+@item After receiving the other's KEX message, both KEX messages are concatenated (see below),
+ and the result is signed using ECDSA.
+ The result is sent to the other.
+@item After receiving the other's SIG message, the signature is verified.
+ If it is correct, the shared secret is calculated from the public keys exchanged in the KEX message using the Elliptic Curve Diffie-Helman algorithm.
+@item The shared secret key is expanded using a PRF.
+ Both nonces and the application specific label are also used as input for the PRF.
+@item An ACK message is sent only when doing key renegotiation, and is sent using the old encryption keys.
+@item The expanded key is used to key the encryption and HMAC algorithms.
+@end itemize
+
+The signature is calculated over this string:
+
+@itemize
+@item uint8_t initiator (0 = local peer, 1 = remote peer is initiator)
+@item opaque remote_kex_message[1 + 32 + ECDH_SIZE]
+@item opaque local_kex_message[1 + 32 + ECDH_SIZE]
+@item opaque label[label_length]
+@end itemize
+
+The PRF is calculated as follows:
+
+@itemize
+@item A HMAC using SHA512 is used, the shared secret is used as the key.
+@item For each block of 64 bytes, a HMAC is calculated. For block n: hmac[n] =
+ HMAC_SHA512(hmac[n - 1] + seed)
+@item For the first block (n = 1), hmac[0] is given by HMAC_SHA512(zeroes + seed),
+ where zeroes is a block of 64 zero bytes.
+@end itemize