@node Encless
@subsection Encryptionless mode

Some jurisdictions can force user to reveal his encryption keys. However
they can not ask for authentication (signing) keys. So you are safe to
use authentication algorithms, but not the encryption ones. Moreover
some countries forbids usage of encryption (but again not the
authentication).

GoVPN provides special encryptionless mode of operation. In this mode it
replaces Salsa20 function used for confidentiality with rather
well-known @url{http://people.csail.mit.edu/rivest/chaffing-980701.txt,
Chaffing-and-Winnowing} (CnW) technology. This is rather traffic and
resource hungry algorithm, so we use it after
@url{http://theory.lcs.mit.edu/~cis/pubs/rivest/fusion.ps,
All-Or-Nothing-Transformation} (based on
@url{http://cseweb.ucsd.edu/~mihir/papers/oaep.html, Optimal Asymmetric
Encryption Padding}) on the data. It is confidentiality preserving
encoding.

AONT is just a keyless encoding of the data. CnW uses only
authentication function. Handshake additionally uses Diffie-Hellman and
signature algorithms. No encryption and steganography involved.

In this mode each outgoing packet became larger on 4128 bytes and
@ref{Noise, noise} is forcefully enabled. So this is rather resource
hungry mode!

@strong{Beware}: by default packet serial numbers are still processed
through the XTEA encryption. It is not required for confidentiality and
security, but for randomizing some parts of the traffic to make it
indistinguishable from the noise, for making it more DPI-proof. It
safely can be disabled, turned off or maybe its keys even can be
revealed without security and forward secrecy loss.

See @code{src/govpn/chaffing} and @code{src/govpn/aont} packages for
details of AONT and chaffing operations.