 So our first speaker Tyler Kelly welcome and give a big round of applause. Alright everybody. Hi so my name is Tyler I work at Cornell Tech in New York City. I hope everyone's hangovers aren't too bad and thanks for braving the hard heat to come up here in the morning. This presentation represents some joint work with some very smart people who are all also at Cornell. So today we're going to talk about tools to improve anonymity on the internet and specifically I'm going to cover an anonymity tool called Dining Cryptographer Networks. Some academic research in that area and then our open source project that we call Howl which is a Dining Cryptographer Protocol. I'm hoping that you leave this talk with a rough intuition of how DC nets work and some excitement about our project and so yeah let's jump in. So let's talk about every cryptographer's favorite topic which is of course cryptocurrency. How many times do you guys think the word privacy occurs in the white paper for Facebook's new crypto coin? Okay I'm seeing some zero and some hands. Anyone else? Also zero? A lot of zero. Okay. Alright well the actual answer is one and this quote is golden. It's like all we're not even going to try and do anything about privacy but we'll like think about it and see what other people do. Yeah. Pretty great. So it's become pretty clear that the digital revolution has in many ways eroded privacy and enabled surveillance on a grand scale that was never before possible. I think that's pretty well understood. So we have this problem today which is that for all intents and purposes digitally speaking privacy is dead right? Like you are tracked online at every step by everyone from your ISP to Facebook at the application layer to Mastercard at the payment layer etc etc etc. And anonymity is a subset of privacy and you need anonymity in some sense to preserve privacy because you need a crowd to hide in. So you know privacy tools like Tor and I2P exist but they're not necessarily widely used and often have pitfalls for users. So we'd like to improve the state of you know existence right now. Um so we need privacy enhancing tools on the internet. Um not just for activists like those in Hong Kong during the protests like the umbrella protests but also for whistleblowers or for applications where treating all parties the same is important like anonymous voting. So we understand that being anonymous is hard so where could we find a solution? How about back in the 1980s and who's going to be our mad scientist? Well David Chong. So there are a variety of anonymity techniques that exist but one of the most thorough and strong privacy preserving techniques that we have today is called Dining Cryptographer Networks and this idea has been around since the late 80s. So let's say hypothetically not that this could possibly have happened but you know last night maybe a group of you went to a bar in valleys and shared a round of drinks and at some point the bartender informs you that some person who wishes to stay anonymous um has purchased you all the next round of drinks. But being in this audience you are sophisticated cryptographers so you're concerned that maybe the NSA is trying to bribe you by buying you a round of drinks and that wouldn't be good. So but at the same time it's possible that someone sitting at the bar bought the round of drinks and if it was someone at the bar you respect their like wishes for privacy so what can you do? Well we have this DC net thing so let's talk about how it works with an example um so we have our familiar friends Alice, Bob and Charlie and the first thing that they do um is they agree on a shared secret setup. So for this example we're gonna just anonymize one bit of information. I'm trying to make this as simple as possible. Um so you know Alice goes to Bob and agrees on a shared secret and they agree on the shared secret one and Bob you know goes to Charlie and they talk and they're like alright we're gonna agree on zero. So everybody does this and uh so on and so forth. Then when it comes time to reveal who paid each person takes the information about whether they paid in this case represented by the bit one or zero um and they XOR this information with the combination of shared secrets that they have with all of the other parties in the system. So what this does is it obfuscates the information you want to broadcast with the shared secrets. Um so Alice here paid so she broadcasts a one. And Bob didn't pay so he broadcasts a zero with a one and a zero because those were his shared secrets. And Charlie does you know he does the same thing and he uh he outputs a one as well. So now that we've broadcasted our encrypted values we can take the XOR of all of these values together and you will have one XOR one XOR one which equals one. All of the participants in the system compute this output separately at the same time. And since the output is one um everybody knows that somebody paid but they don't necessarily know who paid. But I want to break this down a little more obviously so it's it's very clear. Um all of the shared secrets cancel out um when you XOR the shared secrets together in the final output um this is because you have two of each shared secret that gets rolled into the final broadcasted value uh that comes from each of the people. So that shared secret when you XOR them together because of the truth table for XOR which is over there you can see that they'll cancel out. So hopefully that provides some intuition about how you can broadcast some information through this protocol and how like nobody can know what other people are broadcasting uh without actually knowing other people's shared secrets. So that's like a very quick primer on DC nets. So DC nets have some problems um for one only one person can broadcast at a time that's a kind of an issue. Um and second if someone doesn't respond in a timely manner they can slow down the system because everyone has to wait for everyone else. And parties could lie like there's there's no reason why anyone has to be honest. And um and then lastly this DC net has exponential communication complexity and the number of participants in the system. So it becomes very very gossipy. We can solve some of these problems um for instance the collision problem can be solved with a good scheduling algorithm for who can talk when. So instead of transmitting one bit at a time you do the XOR across a bit vector of known length where each person has a slot and then they just transmit their message in their slot. So Alice would transmit let me in the first slot maybe Bob could do his in the second etc etc. And as long as everyone's honest there are ways to choose who goes in what slot by essentially broadcasting the slot position as a message uh that you encrypt through the DC net. There's a paper uh called Footprint Scheduling that goes into this topic specifically scheduling uh in more detail and uh you can see it at the bottom. So one of the most successful DC nets um was a DC net that was uh designed at Yale by Gibbs and uh Ford. Um you can imagine it as a client server protocol for DC nets where clients uh share secrets with all of the servers in the system and then the servers will perform the actual XOR operation amongst themselves. So this has the advantage that um it minimizes the need for uptime in the clients. Clients can sort of come and go as they please. Um and as long as the servers don't go down the system is still robust but you do have uptime requirements on the servers. So they have two papers about this topic. The OSDI 2012 paper is the more useful one if you want to see implementation details. Um but dissent is not flawless either. Specifically there's two problems that we want to iterate on and improve on. And those two are the denial of service problem and the performance problem. So prior work essentially requires a trader tracing protocol um to punish actors that don't act as honest parties. Um and this protocol is pretty expensive and complicated and if we can get rid of it that would be pretty good. And then if we can increase the performance that would also be good for real world adoption because we want to make real world tools that actually affect people's lives and leave academia. So we're developing our own system that we call HAL. Um this stands upon the shoulders of giants and it we're trying to make a DC net that would be real world practical and usable today. The way that we do this is by separating the concept of a DC net into three components. So authorship of messages, aggregation of messages for XORing and the actual anonymization slash encryption of messages i.e. do XOR to it. So we have three types of nodes and each type of node corresponds directly to one of the required components on the previous slide. Clients will author messages and then they will send them to aggregators. These are people who want to broadcast anonymous messages obviously. Aggregators exist to help the performance of the network and what they do is they reduce bandwidth load on the root nodes so that the root nodes don't have to receive a flood of traffic from literally every client in the system. And then additionally by organizing aggregators in a hierarchical structure we can add like very primitive fault tolerance. So if your aggregator sort of tries to censor you or is not being responsive you can just switch to another aggregator in the chain and it'll still go send the message through the system. And then root nodes will perform the final XOR which does the whole do XOR to it and computes the plain text of each round in the protocol. These XOR nodes will always need to be online. So here's a diagram that shows roughly what it would look like. So the other new contribution we bring to the table is the idea of putting the DC net instead of a trusted execution environment, in this case Intel's SGX, secure guard extensions. So in the last few years Intel has been baking in this meta operating system into its processors that operates at a higher privilege level than the OS and is completely opaque to the OS. One of the side effects of this new development is that they've also included a trusted execution environment that they call SGX that essentially allows you to run instructions on the CPU. In this reverse sandbox where all of the code and RAM associated with this enclave is protected from access from the operating system. I just like memes. So they also bake private keys into the hardware and so the environment can cryptographically attest to an outside party that it's running inside of an enclave and that the code is running some specific desired code and only that code. So by using Intel's SGX we can write some DC net code that acts honestly and always follows the rules of the protocol. And then we can use the attestation features on our network and participants in the DC net can check these attestation signatures to ignore anyone not acting honestly and running in the correct environment. All of the trader tracing protocols that were necessary in prior work can just be gotten rid of with this one step. So I want to briefly head off all of the paranoid folks in the audience which I know that there will be especially here. I want to address the what about trusting Intel problem. So it's important to note here that we're only trusting Intel for preventing denial of service. The privacy component is completely and totally independent of SGX. Like if we removed SGX there would still be private. So the worst case scenario is where SGX is completely broken. In that scenario the only thing that happens is the network collapses and no longer broadcast messages. In this context I think that's preferable than trying to keep availability up. Also in the future Hawaii or Siemens might come out with their own competing product. Well then the network can add separate different trusted execution environments and you can sort of spread the trust out across multiple nation states and manufacturers to sort of have them check against each other. Also the last bullet is one of my points. So we have this anonymous broadcast channel where people can essentially shout things into the ether and hide within a crowd of participants in the DC net. I like to think of it as something akin to UDP where you can send messages in one direction but not another. I don't think this would be a good replacement for TOR for example because you'd have to build a lot of infrastructure on top of the DC net to make stateful connections and sort of like HTTP work. But I think it's interesting that you can build TCP out of UDP and that you could build TOR out of this some kind of sort of analogous. There are some potential use cases that we've come up with that we think this would be great for. One is social media where you're broadcasting public statements unidirectionally. So this is like Twitter for example. So with the proper API jig built we could have a relay bot that listens to the DC net for input and posts anonymous tweets from the DC net. The other big use case which I am personally more excited about is anonymizing IP layer metadata from cryptocurrency transactions to try to achieve the goal of anonymous digital cash. So in the transition of monetary instruments to the digital era we've lost an element of anonymity that existed in cash transactions right. So that doesn't exist with credit cards. When you buy booze and cigarettes at valleys tonight Mastercard knows that you did that. And by extension everyone they sell data to and the government also knows that. And that's not really any other business. So we don't really need to be sharing data with third parties all the time but in the digital world that's sort of the norm. So the idea here would be that instead of broadcasting a transaction from a node directly to a cryptocurrency network which is the status quo right now. You would broadcast it through the DC net and then a relay bot would forward all of the transactions it sees in the DC net to the protocol sort of like pushing it through a proxy almost. And that essentially obfuscates the IP address data that is leaked when you broadcast a transaction from a node. So when you buy that booze tonight imagine if that transaction were privately sent through Zcash anonymized at both the IP layer and the application layer. So that would be nice. This use case also has the nice property that tying this technology into a cryptocurrency lets us financially incentivize people to participate in the DC net so you can pay people to anonymize your transactions. And also provide cover traffic. So there might be other use cases that we haven't even thought of and if you've got one I'd love to hear it. Feel free to email me or DM me on Twitter obviously. So this is the slide where I would have performance metrics to show you that our network is fast and you should use it. But unfortunately the code is still in progress. So we're working on the code. I want to do this right so if it means doing it a little slower I'm okay with that. Hopefully we'll have something out in the next few months and we are releasing as open source obviously so check our website and follow me on Twitter for news updates about when that might happen. And with that, that's how. I hope you guys found this talk interesting. Feel free to contact me and keep an eye out for the project and hopefully we can bring digital privacy tools into the mainstream. So thanks. Alright we're opening the floor for questions. If you have questions just line up over here at the middle center please. Hi have you found that there's a minimum number of participants that makes it effective and once you sort of reach below that threshold that all of a sudden it becomes easy to attack and sort of you know de-off you skate what's going on? Off the top of my head I don't know of any specific studies that have shown that but that is definitely something that's the case right? Like you want to have a certain number of minimum K out of N anonymity set to hide in. I want this to be run by like everybody that would be fantastic but I'm not in control of other people so I don't know off the top of my head know how many participants you would need to be secure but the idea is that if we have it open source and if the community likes it like it'll grow organically and so the more people that run it obviously the more crowd there is to hide in yeah. The uh scheduling broadcast does that help to um protect against kind of timing attacks or or any kind of correlation that may be possible? So the problem that scheduling solves is this problem where you can only have one person broadcast at a time so let me go back to this. So in this sort of example toy example I showed we have Alice broadcasting the bit one to indicate that she paid and this was only like a one bit system that I was describing when you want to do more than one you basically just have a bit vector and so you just encrypt the entire bit vector but um the problem is that one person can only talk at time because everyone else needs XOR zero with that um encrypted with that secret value so that the like zeros cancel out the end. Um so the problem that scheduling um solves is like how can we talk with multiple people at the same time? So you take this bit vector and you have like slots where people just sit and put their message in and the entire bit vector becomes the secret. Does that make sense? Okay. So that's that's uh every participant part um has has a slot available whether or not they use it or not is. Yeah and in in some cases you want participants to have more than one slot um but I think the paper is there and uh it's a good paper it's pretty readable. Alright the floor is open to questions. I don't buy it I promise. Alright. Questions? Alright. Alright. Thanks guys. Appreciate it.