Support SLIP encapsulation as a tunnelling mechanism.
[tripe] / doc / tripe.8
index 262b234..bcfdcbb 100644 (file)
@@ -148,6 +148,11 @@ version number to standard output and exits with status 0.
 .B "\-u, \-\-usage"
 Writes a brief usage summary to standard output and exits with status 0.
 .TP
+.B "\-\-tunnel"
+Writes a string to standard output describing the configured tunnelling
+method and exits with status 0.  This is intended for the use of the
+start-up script, so that it can check that it will actually work.
+.TP
 .B "\-D, \-\-daemon"
 Dissociates from its terminal and starts running in the background after
 completing the initialization procedure described above.  If running as
@@ -409,6 +414,97 @@ server to talk to
 .hP 7.
 Congratulations.  The two servers will exchange keys and begin sending
 packets almost immediately.  You've set up a virtual private network.
+.SS "Using elliptic curve keys"
+The
+.B tripe
+server can use elliptic curve Diffie-Hellman for key exchange, rather
+than traditional integer Diffie-Hellman.  Given current public
+knowledge, elliptic curves can provide similar or better security to
+systems based on integer discrete log problems, faster, and with less
+transmitted data.  It's a matter of controversy whether this will
+continue to be the case.  The author uses elliptic curves.
+.PP
+The server works out which it
+should be doing based on the key type, which is either
+.B tripe\-dh
+for standard Diffie-Hellman, or
+.B tripe\-ec
+for elliptic curves.  To create elliptic curve keys, say something like
+.VS
+key add \-aec\-param \-Cnist-p192 \-eforever \e
+       \-tparam tripe\-ec\-param
+.VE
+to construct a parameters key, using your preferred elliptic curve in
+the
+.B \-C
+option (see
+.BR key (1)
+for details); and create the private keys by
+.VS
+key add \-aec \-pparam \-talice \e
+       \-e"now + 1 year" tripe\-ec
+.VE
+Now start
+.B tripe
+with the
+.B \-ttripe\-ec
+option, and all should be well.
+.SS "Using other symmetric algorithms"
+The default symmetric algorithms
+.B tripe
+uses are Blowfish (by Schneier) for symmetric encryption, and RIPEMD-160
+(by Dobbertin, Bosselaers and Preneel) for hashing and as a MAC (in HMAC
+mode, designed by Bellare, Canetti and Krawczyk).  These can all be
+overridden by setting attributes on your private key, as follows.
+.TP
+.B cipher
+Names the symmetric encryption scheme to use.  The default is
+.BR blowfish\-cbc .
+.TP
+.B hash
+Names the hash function to use.  The default is
+.BR rmd160 .
+.TP
+.B mac
+Names the message authentication code to use.  The name of the MAC may
+be followed by a
+.RB ` / '
+and the desired tag length in bits.  The default is
+.IB hash \-hmac
+at half the underlying hash function's output length.
+.TP
+.B mgf
+A `mask-generation function', used in the key-exchange.  The default is
+.IB hash \-mgf
+and there's no good reason to change it.
+.SS "Using SLIP interfaces"
+Though not for the faint of heart, it is possible to get
+.B tripe
+to read and write network packets to a pair of file descriptors using
+SLIP encapsulation.  No fancy header compression of any kind is
+supported.  The intended use is that you allocate a pty pair, set the
+slave's line discipline to SLIP, and hand the
+.B tripe
+server the master end, though in fact any old file descriptors will do.
+.PP
+The SLIP descriptors must be set up and running before the daemon is
+started, and you must inform it about the SLIP descriptors it's meant to
+use in an environment variable
+.BR TRIPE_SLIPIF ,
+whose value must be a colon-separated list of items of the form
+.IR infd [ \c
+.BI , outfd \c
+.RB ] \c
+.BI = \c
+.IR ifname .
+If the
+.I outfd
+is omitted, the same file descriptor is used for input and output.
+.PP
+The output file descriptor should not block unless it really needs to:
+the
+.B tripe
+daemon assumes that it won't, and will get wait for it to accept output.
 .SS "About the name"
 The program's name is
 .BR tripe ,