Tcpcrypt is a protocol that attempts to encrypt (almost) all of your network traffic. Unlike other security mechanisms, Tcpcrypt works out of the box: it requires no configuration, no changes to applications, and your network connections will continue to work even if the remote end does not support Tcpcrypt, in which case connections will gracefully fall back to standard clear-text TCP. Install Tcpcrypt and you'll feel no difference in your every day user experience, but yet your traffic will be more secure and you'll have made life much harder for hackers.

So why is now the right time to turn on encryption? Here are some reasons:

How Tcpcrypt works

Tcpcrypt is opportunistic encryption. If the other end speaks Tcpcrypt, then your traffic will be encrypted; otherwise it will be in clear text. Thus, Tcpcrypt alone provides no guarantees—it is best effort. If, however, a Tcpcrypt connection is successful and any attackers that exist are passive, then Tcpcrypt guarantees privacy.

Network attackers come in two varieties: passive and active (man-in-the-middle). Passive attacks are much simpler to execute because they just require listening on the network. Active attacks are much harder as they require listening and modifying network traffic, often requiring very precise timing that can make some attacks impractical.

By default Tcpcrypt is vulnerable to active attacks—an attacker can, for example, modify a server's response to say that Tcpcrypt is not supported (when in fact it is) so that all subsequent traffic will be clear text and can thus be eavesdropped on.

Tcpcrypt, however, is powerful enough to stop active attacks, too, if the application using it performs authentication. For example, if you log in to online banking using a password and the connection is over Tcpcrypt, it is possible to use that shared secret between you and the bank (i.e., the password) to authenticate that you are actually speaking to the bank and not some active (man-in-the-middle) attacker. The attacker cannot spoof authentication as it lacks the password. Thus, by default, Tcpcrypt will try its best to protect your traffic. Applications requiring stricter guarantees can get them by authenticating a Tcpcrypt session.

How Tcpcrypt is different

Some of us already encrypt some network traffic using SSL (e.g., HTTPS) or VPNs. Those solutions are inadequate for ubiquitous encryption. For example, almost all solutions rely on a PKI to stop man-in-the-middle attacks, which for ubiquitous deployment would mean that all Internet users would have to get verified by a CA like Verisign and have to spend money to buy a certificate. Tcpcrypt abstracts away authentication, allowing any mechanism to be used, whether PKI, passwords, or something else.

Next, Tcpcrypt can be incrementally deployed: it has a mechanism for probing support and can gracefully fall back to TCP. It also requires no configuration (try that with a VPN!) and has no NAT issues. Finally, Tcpcrypt has very high performance (up to 25x faster than SSL), making it feasible for high volume servers to enable encryption on all connections. While weaker by default, Tcpcrypt is more realistic for universal deployment.

We can easily make the bar much higher for attackers, so let's do it. How much longer are we going to stay clear-text by default?

Download Tcpcrypt