[DOC] Overview refactoring

Signed-off-by: Sergey Matveev <stargrave@stargrave.org>

diff --git a/doc/govpn.texi b/doc/govpn.texi
index 8d365711980f65168bc3e3c9c642cfa299bcad3f..44aa54d474d11bad36893421f2a3fc1378b963e5 100644 (file)
--- a/doc/govpn.texi
+++ b/doc/govpn.texi
@@ -22,7 +22,8 @@ A copy of the license is included below.
 @top GoVPN
 
 This manual is for GoVPN -- simple secure free software virtual private
 @top GoVPN
 
 This manual is for GoVPN -- simple secure free software virtual private

-network (VPN) daemon, written entirely on Go programming language.
+network (VPN) daemon, aimed to be reviewable, secure, DPI-resistant,
+written entirely on Go.

 
 @menu
 * Overview::
 
 @menu
 * Overview::

diff --git a/doc/noise.texi b/doc/noise.texi
index 9bb27c6e514b279517b1f150e7a7500226571bb1..d37631051baec950ee8b74edf2b3ed8d10f1a0fa 100644 (file)
--- a/doc/noise.texi
+++ b/doc/noise.texi
@@ -1,12 +1,13 @@
 @node Noise
 @section Noise
 
 @node Noise
 @section Noise
 

-You may turn on @code{-noise} option, that forces to fill up all
-outgoing packets to their maximum (MTU) size. Without that option GoVPN
-provides confidentiality and authenticity of payload, but it's size
-leaks to the observer.
+So-called noise is used to hide underlying payload packets lengths.
+Without it GoVPN provides confidentiality and authenticity of messages,
+but not their timestamps of appearance and sizes.

 
 

-As it can be applied only to outgoing traffic, you should enable it on
-both sides in most cases.
+You may turn on @code{-noise} option, that forces to fill up all
+outgoing packets to their maximum (MTU) size. As it can be applied only
+to outgoing traffic, you should enable it on both sides in most cases.

 
 

-Pay attention that this can dramatically increase your traffic!
+Pay attention that this can dramatically increase your traffic! It is
+turned off by default.

diff --git a/doc/noncediff.texi b/doc/noncediff.texi
index 14afcb109e4177e73fb8a085f06f0e217faab614..7ce3aa25c8b42ae94a3d95702f383b50f6965635 100644 (file)
--- a/doc/noncediff.texi
+++ b/doc/noncediff.texi
@@ -14,3 +14,4 @@ In most cases there is no need in so strict nonce boundaries and
 allowable nonce differences. This is trade-off between highest security
 and possible performance degradation. For example @code{-noncediff 128}
 works rather well (no packet drops) with 1 Gbps link with two switches.
 allowable nonce differences. This is trade-off between highest security
 and possible performance degradation. For example @code{-noncediff 128}
 works rather well (no packet drops) with 1 Gbps link with two switches.

+By default no nonce differences are allowed (highest security).

diff --git a/doc/overview.texi b/doc/overview.texi
index 76fac71cd6a2ee55e0f0d6b452a23144591fe97c..406ab288fdef1ad8b6344080bb89445d202f0b27 100644 (file)
--- a/doc/overview.texi
+++ b/doc/overview.texi
@@ -1,35 +1,35 @@
 @node Overview
 @unnumbered Overview
 
 @node Overview
 @unnumbered Overview
 

-GoVPN is simple secure virtual private network daemon. It uses
+GoVPN is simple secure virtual private network daemon, written entirely
+on @url{http://golang.org/, Go programming language}.
+
+Reviewability, high 128-bit security margin and
+@url{https://en.wikipedia.org/wiki/Deep_packet_inspection, DPI}
+resistance in mind in free software solution are the main goals
+for that daemon.
+
+State off art cryptography technologies include:
+@url{http://cr.yp.to/snuffle.html, Salsa20} stream encryption,
+@url{http://143.53.36.235:8080/tea.htm, XTEA} block encryption,
+@url{http://cr.yp.to/mac.html, Poly1305} message authentication,

 @url{https://en.wikipedia.org/wiki/Encrypted_key_exchange, Diffie-Hellman Encrypted Key Exchange}
 @url{https://en.wikipedia.org/wiki/Encrypted_key_exchange, Diffie-Hellman Encrypted Key Exchange}

-(DH-EKE) for mutual zero-knowledge peers authentication and
-authenticated encrypted data transport. It is written entirely on
-@url{http://golang.org/, Go programming language}.
-
-All packets captured on network interface are encrypted, authenticated
-and sent to remote server, that writes them to his interface, and vice
-versa. Client and server use pre-shared authentication key (PSK) and
-128-bit identification key. There are heartbeat packets used to prevent
-session termination because of peers inactivity.
-
-Handshake is used to mutually authenticate peers, exchange common secret
-per-session encryption key and check UDP transport availability.
-
-Because of UDP and authentication overhead: each packet grows in size
-during transmission, so you have to lower you maximum transmission unit
-(MTU) on virtual network interface.
+(DH-EKE) powered by @url{http://cr.yp.to/ecdh.html, Curve25519}.
+Strong
+@url{https://en.wikipedia.org/wiki/Zero-knowledge_password_proof, zero-knowledge}
+mutual authentication with key exchange stage is invulnerable
+to man-in-the-middle attacks.
+@url{https://en.wikipedia.org/wiki/Forward_secrecy, Perfect forward secrecy}
+property guarantee that compromising of long-term authentication
+pre-shared key can not lead to previously captured traffic decrypting.
+Rehandshaking ensures session keys rotation. MAC authentication with
+one-time keys protects against
+@url{https://en.wikipedia.org/wiki/Replay_attack, replay attacks}.

 
 

-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 about payload (except it's size and time) from captured
-traffic, even if pre-shared key is compromised. Rehandshake is performed
-by client every 4 GiB of transfered data.
+Server can work with several clients simultaneously. Each client is
+@strong{identified} by 128-bit key, that does not leak during handshake
+and each client stays @strong{anonymous} for MiTM and DPI.

 
 

-Each client also has it's own identification key and server works with
-all of them independently. Identification key is not secret, but it is
-encrypted (obfuscated) during transmission.

 
 The only platform specific requirement is TAP network interface support.
 API to that kind of device is different, OS dependent and non portable.
 
 The only platform specific requirement is TAP network interface support.
 API to that kind of device is different, OS dependent and non portable.


@@ -50,22 +50,13 @@ network interfaces on top of UDP entirely
 @item IPv6 compatible
 @item Encrypted and authenticated payload transport
 @item Relatively fast handshake
 @item IPv6 compatible
 @item Encrypted and authenticated payload transport
 @item Relatively fast handshake

-@item
-@url{https://en.wikipedia.org/wiki/Replay_attack, Replay attack} protection
-@item
-@url{https://en.wikipedia.org/wiki/Forward_secrecy, Perfect forward secrecy}
-(if long-term pre-shared keys are compromised, no captured traffic can
-be decrypted anyway)
-@item
-Mutual two-side authentication (noone will send real network interface
-data unless the other side is authenticated)
-@item
-@url{https://en.wikipedia.org/wiki/Zero-knowledge_password_proof, Zero knowledge}
-authentication (pre-shared key is not transmitted in any form between
-the peers, not even it's hash value)
+@item Replay attack protection
+@item Perfect forward secrecy property
+@item Mutual two-side authentication
+@item Zero knowledge authentication

 @item Built-in rehandshake and heartbeat features
 @item Several simultaneous clients support
 @item Built-in rehandshake and heartbeat features
 @item Several simultaneous clients support

-@item Optional noise-appending for concealing underlying packet's length
+@item Hiding of payload packets length by noise appending

 @item Optional built-in HTTP-server for retrieving information about
 known connected peers in @url{http://json.org/, JSON} format
 @end itemize
 @item Optional built-in HTTP-server for retrieving information about
 known connected peers in @url{http://json.org/, JSON} format
 @end itemize