 Hello, everyone. My name is Kristianne Kuhn and I'm a PhD candidate at Karlsruhe Institute of Technology. Today, I'm happy to present to you our paper, Onion Routing with Replies. This paper is joined work together with Dennis Ruffines, Andy Rupp and Thurston Struffen. Let us first start by thinking why we need onion routing in the first place. One goal of onion routing is to provide relationship privacy, so to hide who is communicating with whom from the adversary. And this is a very important goal. Just imagine Alice contacting a web server that only offers information about a specific disease like cancer or depression. Then it is highly likely that Alice suffers from this disease and information that we much rather keep hidden from the adversary. Now, if we want to realize this goal, of course Alice cannot send a message directly to the receiver because the adversary is likely to be able to observe this. And even further, we do not trust the receiver and the receiver might be collaborating with the adversary. So instead, we need some kind of indirection. And for this, we are using onion routing. Onion routing employs multiple relays between the senders and receivers of the communication. And the message from the sender will be encrypted in multiple layers, with one layer for each relay. So that once it goes through the network, each relay will peel off one layer of this packet, which is also called onion because it consists of this many layers. Now, if the onion routing scheme is working correctly, then the adversary cannot link onions before the relay to the ones after the relay. And this ensures that as long as one of the relays is honest, the adversary does not know which sender was contacting which receiver because he does not know how the onions are linked in this case. In our example, the adversary would be able to observe that Alice is sending the gray onion, and he can even link it to the blue one because he controls the first relay. But then from the blue one, he would have no clue whether the next onion is going to be the green or the yellow one. Once the honest relay is done with the processing. So at this point, we link the senders from the receivers because of the honest relay and that the adversary cannot revert and link onions before and after the honest relay. Now, it is really important that we get this unlinking of the onions before and after the honest relay right and therefore we're interested in constructing a secure onion routing packet format. Now a packet format can only be preventing the linkings of onions that are based on the packet itself. Of course, there are more dimensions like the timing of the onions or traffic patterns that are important in practice to unlink senders and receivers, but they cannot be solved with a packet format and instead an orthogonal goal. And there are orthogonal measures that can be applied, but for now we're interested in providing a secure packet format and solving this challenge first. For this, let us look at how onion routing packet formats typically look like. And they typically consist of the header and the payload. The header contains the routing information as well as key material for the relays. But the header is encrypted in multiple layers in a clever way such that each relay only learns the information that is absolutely necessary to do this one step of the path and this one processing. The payload on the other hand is onion encrypted in the sense that well the first layer will be is therefore the first relay the second layer for the second relay and so on. So if we look at this example of the blue onion, first of all the uttermost layer of the header is encrypted with the public key of the first relay so the first relay can remove this layer and sees that the onion needs to go to the second relay. Next, and the first relay will also remove one layer of encryption from the payload. Thereby, it gets the second onion, the green onion, and now the second relay will remove one layer of encryption from the header to realize that it has to send the onion to the final receiver next and one layer from the payload. And thereby the encrypted payload finally gets sent to the receiver and the receiver can remove the last layer of encryption to see the included message. Now one interesting thing to notice about most onion routing packet formats is that they protect the integrity of the header for every hop on the path, but the payload integrity is only checked at the final receiver. And this fact that we only check the payload integrity at the very end enables dangerous attack the mulliability attack. The mulliability attack assumes that the adversary controls the first relay and the final receiver and wants to link the send letter to the receiver and thereby break relationship privacy. The idea is that the first relay will notice when the victim sends a message. In this case, Alice sends the gray message. Then the first relay notices that this onion consists of the header and the payload, but it will further modify the payload and change a bit in it. But we'll leave the header as it is and process the onion just as it would process any usual onion except that now the payload has been modified. Now the next honest relay will not notice that anything in the onion has been modified because it only checks the header and the check for the header goes through. Then this onion will be processed further until it finally is ending at the receiver. And at the receiver we can now notice that, well, the message does not look like we expected to. There is no English language or a typical pattern in there, but instead it's only random bits. Now this helps our adversarial receiver to notice that this onion must have been modified before. And of course it is highly likely that this modification indeed was the one of our adversary that just changed Alice's message in the beginning. And therefore Alice was contacting this receiver and the adversary learned who is communicating with whom, even though there is an honest relay in between. Now to prevent this attack for the case where Alice just wants to send a message to the receiver. We can simply add some protection for the payload because Alice knows the message of the payload. She can pre calculate how the payload has to look like during each part of the path. And then she can explicitly authenticate the payload with a message authentication code. And then basically to the fact that our honest relay will drop the modified onion because you can now realize that somebody tempered with the payload. And in the result, the message of the onion of Alice is not being sent forward anymore, and therefore the adversary does not learn to whom this message was actually addressed to. And this works for the case that Alice wants to send a message to the receiver. But what happens if the receiver actually also wants to reply. Therefore we first have a look at how we in general solve replying to an anonymous sender. Therefore we need to build repliable onions and repliable onions principle look like normal onions. So basically the sender will construct the header for the backward path. So the sender will pick the relays for the backward path as well as the keys that should be used during this backward communication. And then this header is included in the payload of our onion, such that the receiver then gets to retrieve it as part of the payload that he gets. So we can use the header together with the reply that he actually wants to send and just has to attach the new payload to it. So basically, the sender is already constructing a back envelope for the receiver, even though the receiver cannot read all the details of the back envelope because the information of the reply path is hidden in the header such that only each relay learns as much as it needs to learn to then forward the onion until it's back at our original sender Alice. Now, if we want to make sure that our onion routing scheme is actually also secure for replies, we do have one more requirement. We require that replies and request sign distinguishable except that the sender and receiver so any intermediate relay dealing with with an onion should have no clue whether it's a request from the sender to the receiver or reply backwards from the receiver to the sender again. This is because they might be used cases where only very few replies exist. And then of course, the set of candidates that have sent the reply is very small and having very small so called anonymity sets is dangerous for the users because then the attacker could do more attacks or use additional to exclude users from this set. So we want our requests and replies to be indistinguishable. However, we of course additionally want to protect the malleability attack. If we want to protect the malleability attack, we need to make sure that we protect the payload for requests from the sender to the receiver. Now, if we want to have this request reply indistinguishability. This means we also need to protect the payload for reply messages, but protecting the payload for reply messages is actually not as easy as for requests. Because now, well, our sender cannot precalculate any message authentication codes for it because the sender does not know how the reply will look like. So he does not know how the payload on the reply path has to look like. On the other hand, we can also not have our receiver generate such protection measures because the receiver is not trusted in this use case. So we cannot have him know how parts of the onion will look like. Once they are close at the sender again, because otherwise the receiver would just wait for Alice to send her request to him and then send his reply back and recognize his onion, even though he never modified anything, just because he added parts to this onion that he can then add the relay clues to the sender, recognize again that therefore he will know which sender sent the request and to which sender his reply just went. So we can't do this explicitly, but instead we need to find some clever way to protect the payload. And we look and therefore we look for something like implicit payload authentication. And we found two ways to do this. And there's two ways to implicitly protect the payload are the basic ideas behind our secure, repel onion routing protocols. And the first way to do this is by using snacks. And the idea behind this is very easy. Let us just prove that everybody does everything like they should. So the sender will prove that they actually generated the fresh onion and the intermediate relays will prove that they faithfully processed the onion and the receiver will prove that they generated a reply onion. Now, of course, on that this proof states is that the onion that we just see is either a fresh onion or a faithfully processed onion or a reply onion. Now, of course, we cannot only trust in this single step being right, but we need to make sure that we actually build an authentication chain until back at the very center. So we did not only show that the onion that we just see as the result of a faithful processing of an onion. But we will show that it is the result of the faithfully processing of a lever already faithfully processed on it or a fresh onion or a fresh reply onion so that we can always be sure that our authentication chain goes all the way back until the center in this case. Now how we actually do this and make sure that we link this proof is a bit more involved, which is why I would kindly refer you to have a look into our paper for more details. But what I want to tell you now is the second ray of how we can realize implicit payload authentication for onion routing, and it is by using update of encryption. Update of encryption originally comes from a very different setting. It's actually about databases and cloud service. So the idea is that you store your data, of course, and put that at some cloud server, and now you want to change your key. So you want to update all the source ciphertext from a node to a new key. And of course, you would like to do this in an efficient way so you don't want to really resend all the ciphertext, but instead, and this is what updated encryption does. You generate an update token such that then the cloud database can update the ciphertext on their own without learning any information about the included plain text or the used keys. And now there's one more very interesting property that is updated, that some updated encryption schemes have, and it is plain text integrity. Plain text integrity says that, well, an adversary is not able to generate a ciphertext that decrypts to a message unless he trivially knows about this before so of course he trivially knows all the ciphertext that were in the cloud server. But other than that, he cannot come up with new ciphertexts that actually decrypt to messages with a non-negligible probability. And this is really interesting for us because this means he cannot tamper with our payload. And we use this in this way for onion routing, so in a very different setting than the one it's originally been proposed for. And we use updated encryption in the sense that we applied to the payload and our payload needs to be updated with update tokens at every relay. And as soon as it was modified, the update will fail because of the plain text integrity property. So let us have a look at this in a bit more detail. First of all, our sender that we trust generates all the keys and tokens and of course knows all of them. Then she starts by encrypting her message with the first key using the updateable encryption function. And she sends this as the payload of the onion and includes the update tokens in the header of the onion, but only in a way such that each relay only gets to see one of the update tokens. So the first relay will get the first update token. The first relay will use the update function of updateable encryption and update the payload from key one to key two. Now certainly this first relay is adversarial so the adversary knows that the gray and the blue onion actually belong together. But now there's an honest relay and the honest relay also gets an update token that only this honest relay can see so the adversary does not notice token. And that's the important thing. Now the honest relay of course updates the payload again and the adversary does not know that this green onion is the outcome of the blue onion. It could also be any other onion that he observes at this relay at the same time. Because he does not know the update token that if another update token would have been used the other onion another onion would have been the outcome. Now we continue this way until the onion arrives at the receiver and for the receiver we want him to be able to decrypt the message so we have to tell him the fourth key but nothing more than this. With this he can decrypt the message and he will not notice that this key four actually also belongs to key two earlier because he does not know the second update token. Additionally, we give the first key for the reply path to the adversary so that he can use the update encryption function to encrypt his reply as well. And of course we include the update tokens for all the relays again in the backward header in a way such that the adversary does not learn them or at least not the ones of the honest relays. And again he will be sending his onion and with the payload encrypted under the first backwards key and the other onions will always update the backwards key to the other keys that Alice has chosen. But at the point of the honest relay the chain that the adversary can follow breaks again because he does not know the second update token for the backwards path. And therefore he cannot link it over this honest relay which is exactly what we wanted. Now if the adversary decides to modify the message before the honest relay pay the plain text integrity guarantees that the honest relay realizes and the updating of the payload will simply fail and the onion will be dropped at the honest relay. If he decides to modify after the honest relay, it is not much use for him anyways, because then he just does not get the request but also does not learn anything from it. Now of course we need to ensure that we did not include any other ways to link onions before and after the honest relay based on other attacks than the malleability attack. And we do this in our paper, but technically it's very similar to earlier work. So there has been earlier work that does not support replies as well as concurrent work that does support replies that does support replies, but is not secure against our malleability attack. So we indeed propose reusable security properties that now are protecting against the malleability attack and support replies. And we do this technically very similar to what has been done before by proposing an ideal functionality in the UC framework and then deriving game based properties from this functionality. And finally of course we prove that our protocols achieve these game based properties. But if you're interested in details, I would refer you to our paper. For now I want to summarize the talk. So we have learned about onion routings and the dangers of the malleability attack for the relationship privacy. We also learned that preventing the malleability attack and at the same time protecting replies in the sense that we want that replies and requests are indistinguishable is a challenging task because it requires us to find a way to implicitly authenticate the payload, which is a challenging task, but we found two ways to do this. And the first way is by using snacks and proving that every relay and every sender and receiver actually did the processing correctly. And the second way is by using the plain text integrity property of updatable encryption and thereby applying updatable encryption in a completely new setting where it hasn't been applied before. And with this, I would like to thank you for your attention. I'll cause and wait you to have a look into our paper for more details.