Transport-level encryption with Tcpcrypt

Posted Aug 26, 2010 13:18 UTC (Thu) by Fowl (subscriber, #65667)
Parent article: Transport-level encryption with Tcpcrypt

I've thought that this kind of "opportunistic encryption" should be more pervasive for quite some time now.

I'm wondering how far off actual widespread implementation is - it should be relatively easy to get this into the (Linux) kernel, harder to get it on by default; but I'm left wondering if it'll ever make it into OSX or NT in our lifetimes...

Anyway, indepth articles on topics like this are why I hand over my hard earned student dollars to subscribe *hint* *hint*. =)

to post comments

Transport-level encryption with Tcpcrypt

Posted Aug 26, 2010 13:50 UTC (Thu) by Fowl (subscriber, #65667) [Link]

I really should've read the linked pdf before commenting: It seems that already have user space implementations for *nix, BSD and OSX. The integration mechanism looks interesting too.

This is very exciting for me however! Hopefully in the not too distant future, this will make it into mainline and large chunks of internet traffic will start become opaque with almost no one noticing! =)

So I suppose what I was really asking for is more of a political (urgh) view of the situation - what sort of chances this has for general consumption, etc.

Transport-level encryption with Tcpcrypt

Posted Aug 26, 2010 13:52 UTC (Thu) by jackb (guest, #41909) [Link] (2 responses)

Can't you already do opportunistic encryption with IPsec and DNS TXT keys?

Transport-level encryption with Tcpcrypt

Posted Aug 26, 2010 14:44 UTC (Thu) by djao (guest, #4263) [Link]

You can, but it's unbelievably difficult. To start with, opportunistic encryption is (to my knowledge) not yet a standard part of IPsec. It's a nonstandard extension offered by some implementations, not all of which are compatible. Also, installation and configuration of IPsec is much more intrusive and time-consuming than tcpcrypt. But the biggest problem is that the DNS TXT key needs to go in the reverse DNS zone file. I don't know a single residential ISP that allows customers to add something to their reverse DNS, and even among business ISPs this kind of thing is very rare. So, in practice, opportunistic encryption via IPsec is available only to a very few privileged users, which is not enough to support large-scale deployment or make any measurable difference in the percentage of internet traffic that undergoes encryption.

Transport-level encryption with Tcpcrypt

Posted Aug 26, 2010 17:33 UTC (Thu) by imitev (guest, #60045) [Link]

Even if every provider allowed messing with TXT records, the percentage of people configuring it would be ~0.
As a general rule if you need to configure something then say goodbye to mass usage. If you need to understand DNS TXT and ipsec (and its weird implementation interoperability issues), then say not only goodbye to mass usage, but also to a good amount of sysadmins.