Over the last week we've closely watched the disclosures about the alleged NSA PRISM program. At CloudFlare, we have never been approached to participate in PRISM or any other similar program. We do, from time to time, receive subpoenas and court orders. A human being on our team reviews each of these requests manually. When we determine that a request is too broad, we push back to limit the scope of the request. Whenever possible, we disclose to all affected customers the fact that we have received a subpoena or court order and allow them an opportunity to challenge it before we respond.

One of the ways we limit the scope of orders we receive is by limiting the data we store. I have written before about how CloudFlare limits what we log and purge most log data within a few hours. For example, we cannot disclose the visitors to a particular website on CloudFlare because we do not currently store that data.

To date, CloudFlare has never received an order from the Foreign Intelligence Surveillance Act (FISA) court. Moreover, we believe that due process requires court review of executive orders. As a policy, we challenge any orders that have not been reviewed and approved by a court. As part of these challenges, we always request the right to disclose at least the fact that we received such an order, but we are not always granted that request.

While we understand the need for secrecy in some investigations, we are troubled when laws limit our ability to acknowledge that we have even received certain kinds of requests. CloudFlare fully supports the calls for transparency today by other web companies like Google, Microsoft, and Facebook. At a minimum, we request the law be updated to allow companies to disclose the number of FISA orders and National Security Letters (NSLs) they have received. We believe this is a modest request which does not harm the integrity of legitimate investigations while allowing for an informed public debate over the use of these measures.

As we set policy, one of our guiding principles is that we should neither make the job of law enforcement easier, nor should we make it harder, than it would have been if CloudFlare did not exist. If the NSA is listening in on any transactions traversing our network, they are not doing so with our blessing, consent, or knowledge.

Making Sense of PRISM

As we've followed the PRISM story, we've tried to reconcile how the PRISM slides could be accurate while so many tech executives have denied participation in the program. One theory that surfaced was that the NSA had broken the private SSL keys of a select number of web giants. Our theory was that this could explain how companies were added over time—as their private SSL keys were cracked—while their executives wouldn't have any knowledge of what was happening.

Even the name of the program—"PRISM"—led credence to this theory. Prisms are often used with fiber optic cables in order to split the light the cables carry into multiple copies. This is not new technology. In 2006 in Room 641a of a data center in San Francisco, AT&T installed a beam splitter to siphon traffic from their optical network, reportedly at the request of the NSA.

SSL should protect these communications. However, with most SSL ciphers, the private key remains the same for all sessions. As a result, if the NSA were to record encrypted traffic, they could later break the SSL key used to secure the traffic and then use the broken key to decrypt what they previously recorded.

Breaking SSL

Breaking an SSL key is hard, but not impossible. Doing so is just a matter of computational power and time. For example, it is known that using a 2009-era PC cranking away for about 73 days you can reverse engineer a 512-bit key. Each bit in a key's length doubles the effective computational power needed to break the key. So, if the key were 513 bits long, you'd expect the same modest PC 132 days to break the key. These tasks are highly parallelizable, so if you have two modest PCs then you'd expect the time to break the 513-bit key to drop down to 66 days again. (Note: this assumes a naive factorization algorithm. The state of the art is to use a generalized number field sieve. This reduces the rate of complexity growth to something that is sub-exponential. This means if you know what you're doing the problem doesn't double in difficulty with each additional bit.)

It is not inconceivable that the NSA has data centers full of specialized hardware optimized for SSL key breaking. According to data shared with us from a survey of SSL keys used by various websites, the majority of web companies were using 1024-bit SSL ciphers and RSA-based encryption through 2012. Given enough specialized hardware, it is within the realm of possibility that the NSA could within a reasonable period of time reverse engineer 1024-bit SSL keys for certain web companies. If they'd been recording the traffic to these web companies, they could then use the broken key to go back and decrypt all the transactions.

While this seems like a compelling theory, ultimately, we remain skeptical this is how the PRISM program described in the slides actually works. Cracking 1024-bit keys would be a big deal and likely involve some cutting-edge cryptography and computational power, even for the NSA. The largest SSL key that is known to have been broken to date is 768 bits long. While that was 4 years ago, and the NSA undoubtedly has some of the best cryptographers in the world, it's still a considerable distance from 768 bits to 1024 bits—especially given the slide suggests Microsoft's key would have to had been broken back in 2007.

Moreover, the slide showing the dates on which "collection began" for various companies also puts the cost of the program at 20M/year. While the NSA may have broken 1024-bit SSL keys as part of some other program, if the slide is accurate and complete, we think it's highly unlikely they did so as part of the PRISM program. A not particularly glamorous alternative theory is that the NSA didn't break the SSL key but instead just cajoled rogue employees at firms with access to the private keys—whether the companies themselves, partners they'd shared the keys with, or the certificate authorities who issued the keys in the first place—to turn them over. That very well may be possible on a budget of $20M/year.

Making SSL More Secure

Today many web companies have largely transitioned from 1024-bit SSL to significantly stronger 2048-bit keys. (Remember, for a naive algorithm, each bit doubles the time it takes to break the key, so a 2048-bit key isn't twice as strong, it is 2^1024 times as strong.) Based on the SSL survey data, Twitter has led the way, shifting 100 percent of its HTTPS traffic to a 2048-bit key in mid-2010. By the end of 2012, the following websites had approximately the amount of requests in the parenthesis shifted to 2048-bit SSL:

• outlook.com (100%)

• microsoft.com (98%)

• live.com (90%)

• skype.com (88%)

• apple.com (85%)

• yahoo.com (82%)

• bing.com (79%)

• hotmail.com (33%)

Facebook is the laggard of the bunch and today is still using a 1024-bit key for all HTTPS requests.

Google is a notable anomaly. The company uses a 1024-bit key, but, unlike all the other companies listed above, rather than using a default cipher suite based on the RSA encryption algorithm, they instead prefer the Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) cipher suites. Without going into the technical details, a key difference of ECDHE is that they use a different private key for each user's session. This means that if the NSA, or anyone else, is recording encrypted traffic, they cannot break one private key and read all historical transactions with Google. The NSA would have to break the private key generated for each session, which, in Google's case, is unique to each user and regenerated for each user at least every 28-hours.

While ECDHE arguably already puts Google at the head of the pack for web transaction security, to further augment security Google has publicly announced that they will be increasing their key length to 2048-bit by the end of 2013. Assuming the company continues to prefer the ECDHE cipher suites, this will put Google at the cutting edge of web transaction security.

SSL on CloudFlare

There is good news in all of this. If you're using SSL on CloudFlare, your site is already at this cutting edge. We issue 2048-bit keys by default and prefer the ECDHE cipher suites. Today, most modern browsers running on up-to-date operating systems will support ECDHE. In our tests, approximately two thirds of HTTPS requests to our network support ECDHE. The remaining traffic quietly falls back on a more standard cipher suite without the visitor noticing.

Looking Ahead

Ultimately, CloudFlare's value proposition is built on trust. Core to that trust is ensuring transactions passing through our network are fundamentally secure. We will continue to work on both policy and technology to ensure the security and integrity of our network.

PRISM has sparked a conversation on privacy and transparency broadly—among citizens, between companies, and with our governments. At CloudFlare, we are actively engaged in this conversation at many levels. Our mission is to build a better web, and we believe privacy and transparency are critical to its foundation.