Someone on Quora just asked: “Will Linux incorporate tcpcrypt?”. I posted a response over there:

I have been working on and off with tcpcrypt for about a year. I believe that if someone puts in the time to polish the Linux kernel implementation, it’d be a likely candidate for inclusion. Andrea Bittau (the lead tcpcrypt guy) told me he would like to work on the kernel implementation himself sometime in the future. Andrea, Mark Handley, and David Mazieres are also working on the Internet Draft.

For now, the userspace implementation works well (and supports Linux, Mac OS X, FreeBSD, and Windows). It has a library so that endpoints can see the tcpcrypt session ID (to perform their own authentication), at https://github.com/sorbo/tcpcrypt/blob/master/user/include/tcpcrypt/tcpcrypt.h, and I made an Apache module that passes the session ID to Web apps, at https://github.com/sqs/mod_tcpcrypt.

On the advantages of tcpcrypt over TLS:

If your system runs tcpcryptd, then existing applications will use tcpcrypt. If the destination host doesn’t support tcpcrypt, then the channel falls back to normal TCP with no communication round-trip overhead. If both sides support tcpcrypt, then the applications get encryption for free (no code changes and minimal overhead). Of course, this only protects against passive attackers; to protect against active attacks, the apps would have to be modified to authenticate using the tcpcrypt session ID. Still, it’s better than cleartext. This, I think, is the key benefit tcpcrypt has over TLS: it makes encrypted-by-default really simple to bring about.

See also the tcpcrypt Internet-Draft and the tcpcrypt Wikipedia page.