=====
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.
+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
and sent to remote server, that writes them to his interface, and vice
versa. Client and server use pre-shared authentication key (PSK).
Because of stateless UDP nature, after some timeout of inactivity peers
-forget about each other and have to retry handshake process again. As a
-rule, there are enough time-to-time traffic in ordinary Ethernet
-networks to heartbeat connection.
+forget about each other and have to retry handshake process again,
+therefore background heartbeat process will be ran.
Handshake is used to mutually authenticate peers, exchange common secret
per-session encryption key and checks UDP transport availability.
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.
-
-COMPARISON TO OpenVPN
+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.
-* Higher performance
-* 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)
-* Fast handshake
+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.
CONSOLE OUTPUT LEGEND
MTU for the link is 1476, however it does not take in account TAP's
Ethernet frame header length, that in my case is 14 bytes long (1476 - 14).
- gateway% ip addr add 192.168.0.1/24 dev wlan0
- gateway% tunctl -t tap10
- gateway% ip link set mtu 1462 dev tap10
- gateway% ip addr add 172.16.0.1/24 dev tap10
- gateway% ip link set up dev tap10
- gateway% govpn -key KEY -iface tap10 -bind 192.168.0.1:1194
-
- pc% ip addr add 192.168.0.2/24 dev wlan0
- pc% tunctl -t tap10
- pc% ip link set mtu 1462 dev tap10
- pc% ip addr add 172.16.0.2/24 dev tap10
- pc% ip link set up dev tap10
- pc% ip route add default via 172.16.0.1
- pc% while :; do govpn -key KEY -iface tap10 -remote 192.168.0.1:1194; done
+ common% umask 066
+ common% echo MYLONG64HEXKEY > key.txt
+
+GNU/Linux IPv4 client-server example:
+
+ server% ip addr add 192.168.0.1/24 dev wlan0
+ server% tunctl -t tap10
+ server% ip link set mtu 1462 dev tap10
+ server% ip addr add 172.16.0.1/24 dev tap10
+ server% ip link set up dev tap10
+ server% govpn -key key.txt -iface tap10 -bind 192.168.0.1:1194
+
+ client% ip addr add 192.168.0.2/24 dev wlan0
+ client% tunctl -t tap10
+ client% ip link set mtu 1462 dev tap10
+ client% ip addr add 172.16.0.2/24 dev tap10
+ client% ip link set up dev tap10
+ client% ip route add default via 172.16.0.1
+ client% while :; do govpn -key key.txt -iface tap10 -remote 192.168.0.1:1194; done
+
+FreeBSD IPv6 client-server example:
+
+ server% ifconfig em0 inet6 fe80::1/64
+ server% ifconfig tap10 create
+ server% ifconfig tap10 inet6 fc00::1/96 mtu 1462 up
+ server% govpn -key key.txt -face tap10 -bind fe80::1%em0
+
+ client% ifconfig me0 inet6 -ifdisabled auto_linklocal
+ client% ifconfig tap10
+ client% ifconfig tap10 inet6 fc00::2/96 mtu 1462 up
+ client% route -6 add default fc00::1
+ client% while :; do govpn -key key.txt -iface tap10 -remote [fe80::1%me0]:1194; done
+
+Example up-script:
+
+ client% cat > up.sh <<EOF
+ #!/bin/sh
+ dhclient $1
+ rtsol $1
+ EOF
+ client% chmod +x up.sh
+ client% govpn -key key.txt -iface tap10 -remote [fe80::1%me0]:1194 -up ./up.sh
If client won't finish handshake during -timeout, then it will exit.
If no packets are received from remote side during timeout, then daemon
-will stop sending packets to the client and client will exit. In every
+will stop sending packets to the client and client will exit. In all
cases you have to rehandshake again.
TECHNICAL INTERNALS
+Nonce encryption: XTEA
Encryption: Salsa20
Message authentication: Poly1305
Password authenticated key agreement: Curve25519 based DH-EKE
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