]> Cypherpunks.ru repositories - govpn.git/blobdiff - README
Obfuscate/randomize message nonces
[govpn.git] / README
diff --git a/README b/README
index c529c3e67bbd359db466d789612da520658e8949..dfef9cbda7c98c12f5d9931a350b2ab87eca9cf5 100644 (file)
--- a/README
+++ b/README
@@ -2,10 +2,25 @@
                                  =====
 SYNOPSIS
 
-govpn is simple high-performance secure virtual private network daemon.
+govpn is simple secure virtual private network daemon.
 It uses DH-EKE for mutual zero-knowledge authentication and
 authenticated encrypted transport. It runs under GNU/Linux and FreeBSD.
 
+FEATURES
+
+* GNU/Linux and FreeBSD support
+* IPv6 compatible
+* Encrypted and authenticated transport
+* Relatively fast handshake
+* Replay attack protection
+* Perfect forward secrecy (if long-term pre-shared keys are compromised,
+  no captured traffic can be decrypted anyway)
+* Mutual two-side authentication (noone will send real network interface
+  data unless the other side is authenticated)
+* Zero knowledge authentication (pre-shared key is not transmitted in
+  any form between the peers, not even it's hash value)
+* Built-in rehandshake and heartbeat features
+
 DESCRIPTION
 
 All packets captured on network interface are encrypted, authenticated
@@ -22,28 +37,17 @@ Because of UDP and authentication overhead: each packet grows in size
 during transmission, so you have to lower you maximum transmission unit
 (MTU) on network interface.
 
-High security and high performance are the goals for that daemon. It
-uses fast cryptography algorithms with 128bit security margin, strong
-mutual zero-knowledge authentication and perfect-forward secrecy
-property. An attacker can not know anything from captured traffic, even
-if pre-shared key is compromised.
+High security is the goal for that daemon. It uses fast cryptography
+algorithms with 128bit security margin, strong mutual zero-knowledge
+authentication and perfect-forward secrecy property. An attacker can not
+know anything from captured traffic, even if pre-shared key is
+compromised. Rehandshake is performed by client every 4 GiB of
+transfered data.
 
 Also you can provide up and down scripts that will be executed after
 either connection is initiated (up-script in background), or is went
 down. The first argument for them is an interface name.
 
-COMPARISON TO OpenVPN
-
-* Faster handshake
-* Perfect-forward secrecy (if long-term pre-shared keys are compromised,
-  no captured traffic can be decrypted anyway)
-* Mutual two-side authentication (noone will send real network interface
-  data unless the other side is authenticated)
-* Zero-knowledge authentication (pre-shared key is not transmitted in
-  any form between the peers, not even it's hash value)
-* Higher performance in some cases
-* Fully IPv6 compatible
-
 CONSOLE OUTPUT LEGEND
 
 B -- bad or timeouted UDP packet (maybe network is inactive)
@@ -118,6 +122,7 @@ cases you have to rehandshake again.
 
 TECHNICAL INTERNALS
 
+Nonce encryption: XTEA
 Encryption: Salsa20
 Message authentication: Poly1305
 Password authenticated key agreement: Curve25519 based DH-EKE
@@ -127,12 +132,24 @@ Handshake overhead: 4 UDP (2 from client, 2 from server) packets,
 
                            Transport protocol
 
-    SERIAL + ENC(KEY, SERIAL, DATA) + AUTH(SERIAL + ENC_DATA)
+    ENCn(SERIAL) + ENC(KEY, ENCn(SERIAL), DATA) + AUTH(ENCn(SERIAL) + ENC_DATA)
+
+Each transport message is indistinguishable from pseudo random noise.
+
+SERIAL is an encrypted message serial number. Odds are reserved for
+client(→server) messages, evens for server(→client) messages.
+
+ENCn is XTEA block cipher algorithm used here as PRP (pseudo random
+permutation) to randomize, obfuscate SERIAL. Plaintext SERIAL state is
+kept in peers internal state, but encrypted before transmission. XTEA is
+compact and fast enough. Salsa20 is PRF function and requires much more
+code to create PRP from it. XTEA's encryption key is the first 128-bit
+of Salsa20's output with established common key and zero nonce (message
+nonces start from 1).
 
-where SERIAL is message serial number. Odds are reserved for
-client->server, evens are for server->client. SERIAL is used as a nonce
-for DATA encryption: encryption key is different during each handshake,
-so (key, nonce) pair is always used once.
+Encrypted SERIAL is used as a nonce for DATA encryption: encryption key
+is different during each handshake, so (key, nonce) pair is always used
+only once.
 
 We generate Salsa20's output using this key and nonce for each message:
 * first 256 bits are used as a one-time key for Poly1305 authentication