Transport-level encryption with Tcpcrypt

Thank you for your comments about tcpcrypt. I had written it off the first few times I saw it, because who needs crypto connections that "fail open" if a single TCP option gets stripped?

As it turns out, though, tcpcrypt does two very useful things:

1) tcpcrypt provides extremely low-overhead session key creation, more than an order of magnitude faster than SSL.

2) tcpcrypt provides non-secret, unique session identifiers that allow you to build authentication primitives at the application level. Among other things, you can use RSA to sign the session ID (turning tcpcrypt into a much faster SSL replacement) or perform mutual authentication using a client-only password and a corresponding hash on the server.

Essentially, tcpcrypt separates encryption from authentication, and provides the building blocks to do both well.

Even though tcpcrypt looks like junk at first glance, it's a _very_ slick protocol. But the authors really need to revamp their home page so that they stop getting written off as cranks who don't understand why "fail open" is a bad security policy.