For my second semester of Junior independent work, I thought I'd do something a little different than what I'd done previously. Namely, working with Professor Michael Gordin in Princeton's outstanding History of Science department, I decided to do a more historical and in-dept look into the current state of encryption on the Internet. This has been a topic that has interested me for a long time - why is internet security so hard? It seems like, with so many smart people and big companies working with the same goals, someone would have figured it out by now. It turns out that the answer to 'why is internet security so difficult' is, not suprisingly, rather long and complicated. My research, which involved looking at everything from OSI technical documents, the original RFCs for the now ubiquitous TCP/IP and IPSec, focused in particular on the distinct absence of widespread implementation of encryption at the link level of the Internet (that is, the level in the network stack that TCP/IP fulfills).

From what I could tell, there is a fairly obvious and clear place for widespread encryption in the network stack - the kind of place you'd put your encryption/decryption mechanism if you wanted to enable secure connections by default, without the application itself needing to worry about the details and verifying public keys, etc. There was also a moment of opportunity, in the early '70s, when TCP/IP was being developed (primarily by Vint Cerf and Robert Khan at Stanford), which would have been perfect for the idea of low-level encryption to take hold and gain widespread adoptation. Unfortunately, the window was missed; instead, we now have a hodge-podge of application-level security solutions, with so many different implementations of the security protocols that finding new bugs becomes a never-ending arms race with malicious programmers.

It was a great way to try something a little different in terms of independent work, and Professor Gordin was a great advisor who was willing to listen to my rambling monologues without complaint while I refined my ideas and overal thesis. Learning to read and understand RFCs was a great experience as well, and since I was doing this research along side taking a Networks class (which also required reading RFCs, for the purpose of implementing some lower-level protocols in C yourself) the timing worked out well. The paper itself can be obtained here, and the poster I designed to present my project to the CS department at Princeton can be found here.