 So, hi, I'm Noah Stevens-Bidowicz, or Noah SD. I'll be talking to you today about message transmission with reverse firewalls, a.k.a. how to do secure computation on a corrupted machine. This is joint work with Yevgeny Dodis and Ilya Mironov. So the question that we start with today is, should Alice trust her computer? So here's Alice's trustworthy computer. And he seems like a nice guy and all, but one can never be too careful. And so the basic problem that we're concerned about is something like this, right? We don't want the last person to have touched our computer to be the person, to be able to completely compromise our security, certainly not our national security. And this is not just a theoretical issue, right? So we now know that cryptographic software is broken in all sorts of ways. Perhaps the most common way is simply that there are bugs everywhere. So there are apparently accidental bugs all over cryptographic software. I'll simply flash the logos of all these things you guys have seen before, heart bleeding in the poodle bug and Apple's go to fail, et cetera. I guess those of you who saw the talk last night know this as honest but flaky implementations. So this is one way in which crypto gets broken. Another way is that there's actually deliberate corruption of hardware and software. So I think most of you have seen this picture by now. This is US government agents actually intercepting hardware on its way to a customer in order to tamper with it to compromise their security. So perhaps we'd like to think that crypto in the real world goes something like this. We have Alice. We have Bob. They interact in some way. And some adversary who's present and wants to do them harm is completely unable to. So he loses some security games, I mean, distinguishability game or whatever. But perhaps crypto in the real world actually looks more like this. Alice's computer replaces Alice because Alice can't compute bilinear maps in her head. And this computer has been corrupted in some way. And instead of sending the proper first message, Alice's first message is simply her password. And her second message is simply her credit card number. And then maybe Bob will be a little confused. But our adversary will certainly end up happy. So this is a rather terrifying prospect, I think. And of course, one can argue that this is obviously detectable, but one can do more sophisticated things, right? The adversary could use cryptography himself. He could encrypt messages under his own key so that we don't see what he's sending or he could use steganography so we can't even tell that anything's gone wrong. So this leads to a rather terrifying and seemingly absurd question, which is can we do crypto when our machine has been compromised? And actually we're not the first to ask this question. Of course, there's lots of prior work. Unfortunately, because I'm rather pressed for time, I won't be able to do it, it's proper justice. But essentially, back in the 80s, people started studying this. It went through the 90s. It was really started by Simmons with soliminal channels. And the work really died out until the Snowden revelations in which it was resurrected. And some of the first work was by Bilari Patterson and Raghway. They called this stuff algorithm substitution attacks and they studied symmetric key encryption. And I'll discuss that briefly. So in particular, Bilari Patterson and Raghway suggested using deterministic symmetric key encryption. So if you have stateful symmetric key encryption, you can actually do it deterministically. You can have a unique valid ciphertext for each plaintext. And this is nice because it prevents steganography just by fiat. If you're going to send the correct message, as long as we enforce correctness, there's no choices that can be made. So you can't substitute the algorithm with anything. So this is nice and it actually forms the basis for much of our work. But at least from my perspective, the primary result of this paper was a negative result showing that it's actually impossible to prevent steganography on any encryption that non-trivial uses randomness, right? So if we're going to use randomness in any way, the adversary can just tamper with the randomness and use this to transmit information. And in particular, this means that semantically secure public key encryption is impossible on a corrupted machine. Adversary can mess with the randomness and steganography is always possible. So this is rather disappointing. If we can't do semantically secure public key encryption, there's a lot that we can't do. So in Europe 2015, with Ilya Marinov, we introduced a new model called reverse firewalls to avoid impossibility results like this. And the idea of reverse firewall is to add a third party into the game. So the firewall is something that sits between Alice's computer and the outside world. So here's Alice's computer, here's the outside world represented by Bob. Firewall sits in the middle. And what the firewall does is it modifies the messages that Alice sends and receives. So Alice sends M1, the firewall modifies it in some way and forwards it along to Bob. Bob sends some message M2 back, firewall modifies it in some way and sends that along to Alice, et cetera. And we have some requirements on the firewall. Like it should be transparent to legitimate traffic. So Alice and Bob should neither know nor care that the firewall is present. In particular, you'll notice that every message sent by Alice corresponds to one message received by Bob and vice versa. So we don't have like 20 messages going back and forth between Alice and the firewall before every message sent to Bob. So we really want this to be as transparent as possible. And of course, the firewall should not break the functionality of the underlying protocol. If in the end, Alice and Bob are supposed to agree to a key or something, they should still agree to a key. And the firewall should share no secrets with Alice, so I'm not just sort of moving the security to a new party. I'm not creating a new trusted party. I'm actually adding more security on. And I'll just sort of put this in bold and kind of in scare quotes for now. We don't trust the firewall. I'll make that more explicit, but I hope you keep that in mind. In a few slides, I'll make it concrete. And finally, of course, we want the firewall to benefit us in some way. And the way that the firewall benefits us is that it gives us some meaningful security notions when Alice has been corrupted. So the firewall improves security in the case when Alice's machine has been compromised in some way. So let's make this formal. We can define the functionality of reverse firewall. It's actually quite simple. So we have some underlying classical protocol. So I always require that an underlying classical protocol exists. If there exists a protocol without the firewall there. And this should satisfy some functionality notion, say Alice and Bob output YA and YB. Maybe they're keys and they should match. And the protocol with the firewall should simply satisfy the same security notion. So extremely straightforward. So we have our new protocol with the firewall, Alice and Bob still output YA and YB and they should still match. The firewall shouldn't screw that up. Security is defined in the same way. It's slightly more subtle, but the idea is the same. So we have an underlying protocol that satisfies some security notion represented by some crazy game in which maybe Bob's evil and the adversary has oracle access to Alice and somehow still the adversary is thwarted. And we want our protocol with the firewall to satisfy the same security notion. So you plug in your favorite security notion here. We want the protocol with the firewall to satisfy the same notion. Now, regardless of how Alice's machine behaves as long as the corruption is efficient. So to be clear, we view the exact same security game that we had before, except now we view Alice's corrupted implementation and the firewall as one single joint party. We could think of the messages that they send between each other as being sort of the internal wires of one giant composed party. And we want to guarantee security of this new protocol that we get by substituting in Alice, substituting in for Alice, this joint party, which is one corrupted party and one honest firewall. So that's our security notion. That's what we gain from a firewall. And I wanna point out, I think I've emphasized this a bit already, that the protocol should be functional and secure even without the firewall present. So we want there to be an underlying protocol. We want that to have functionality guarantees and we want that to have security guarantees. And this is an important design decision that we made. So let's go back to our example from before. If you remember, in the algorithm substitution attack model, semantically secure public encryption is simply impossible because it requires randomness. But with a firewall, it's actually rather trivial. What we're going to do is we're going to take some re-randomizable public encryption scheme. I think as soon as I say that, the protocol is immediately obvious. So we have three algorithms, encrypt decrypt and re-randomize, encrypt and decrypt behave as you expect. They do what they say on the tin. Re-randomize has a correctness requirement. So if I re-randomize a valid encryption, it should decrypt to the correct plain text. And it has a security requirement as well, which is that if I re-randomize any ciphertext whatsoever, it doesn't matter how it was formed, it should be indistinguishable from a fresh encryption of zero. So given these notions, it's quite easy to construct semantically secure public encryption scheme with the firewall. So the underlying protocol is completely trivial. Alice is simply going to send her plain text encrypted under Bob's public key. And the firewall is also trivial. It's simply going to receive whatever horrible corrupted ciphertext Alice's corrupt implementation decides to send and it's going to re-randomize it. So let's make sure we're all on the same page. Let's just see that this simple protocol actually does satisfy our definitions. So we can ask, does it satisfy functionality? Remember, there are two requirements for functionality. The first is that the underlying protocol is functional. So is this underlying protocol functional without the firewall? And the answer is, of course, yes, as long as the encryption scheme is correct. Next we can ask if the protocol is functional with the firewall. Again, the answer is yes, as long as the re-randomization is correct. Now for security, we can ask, is the protocol secure without the firewall? And here we're guaranteed security as long as underlying encryption scheme is semantically secure. Similarly, we can ask if the protocol is semantically secure with the firewall, regardless of how Alice's computer behaves. And here we rely on the security of re-randomization. So we said that a re-randomization allows, makes a ciphertext indistinguishable from zero an encryption of zero after we re-randomize it no matter what the initial ciphertext was even if the adversary knew it in advance. So here we have semantic security regardless of how Alice's computer behaves. This is a very simple example. It makes the definitions clear, I hope, and it also shows that things are possible in this model that are not possible outside of this model. So now I'm going to address a very, very common complaint that people have, which is, well, what if the firewall itself is just corrupt? Like, haven't we just passed the buck? Aren't we just adding a trusted third party? And the answer is no. So the most natural question to ask, I think, is what if Alice is honest and the firewall is corrupt? And in this case, so here we have our corrupt firewall with his evil eyes and his horns. And in this case, we can really just view the corrupt firewall as part of a larger active adversary. We can sort of join in with Bob or join in with whatever adversary you already had in your original security game. So as long as our underlying protocol was secure against active adversaries, adding a corrupted firewall doesn't change anything in the security game. It's just like the adversary now has more wires going into it. It doesn't change anything. So this is why we require there to be an underlying secure protocol. As long as it's secure against active adversaries, we don't have to worry about corrupted firewalls. Now, another situation to consider, of course, is if Alice is corrupt and the firewall is honest. And in this case, this is what the firewall buys us. This is why we like firewalls. It's because the security of the firewall itself guarantees that we still have a meaningful security notion even in this world. And finally, we can ask the question, what if Alice and the firewall are both corrupt? And here I make no promises. So if the entire world is corrupt, I can't do anything. But the purpose of this slide is to show you that the firewall helps us, it doesn't hurt us. So in the first case, we have security with or without the firewall. In the second case, we could not possibly have security without the firewall, but with the firewall, we obtain meaningful security guarantees. In the third case, we lose no matter what. So the firewall helps us, it doesn't hurt us. It's not trusted third party, it's simply a useful third party. So this is kind of a crazy model. What can we do in it? And in our original paper, we show that actually you can do quite strong things. So oblivious transfer and secure function evaluation are possible with reverse firewalls. I think this is rather surprising because secure function evaluation subsets two-party crypto complete, so you can have sort of any functionality you want two-party crypto with a reverse firewall, admittedly, very inefficiently. In follow-up work, a Teneze Magri inventory showed that you can do signatures so you can have authenticated messages with reverse firewalls. And in this work, we handle probably the most natural primitive in cryptography, which is secure message transmission. Of course, message transmission has been studied in a variety of different contexts, and cryptography is very fundamental, and we studied in a variety of different contexts too. Probably the most important thing that we do is we show that there's an efficient CCA secure scheme. And I won't have time to get into that completely, but I'll give you a rough feel for it, I hope. So now let's talk about message transmission protocols. So a message transmission protocol is a protocol between Alice and Bob. Alice's input is a message, then they engage in some crazy protocol, and in the end, Bob outputs the same plain text message. So this is the correctness. It has some security notions. CPA security says intuitively that an eavesdropper cannot learn anything about the plain text M. Of course, we formalize this using an indistinguishability game. And there's a stronger security notion, of course, which is CCA security, which says that an active adversary with access to a decryption oracle should not be able to learn anything about the plain text M. So here we have an adversary that can send messages to Alice and Bob, can ask for decryptions of anything but the challenge ciphertext, and still the adversary should be unable to tell anything about the message. And there's an orthogonal notion known as forward secrecy, in which we hope that security still holds, even if later Alice and Bob leak their secret keys. So I showed you the simple public key encryption scheme before, but it has some obvious problems. Perhaps the most blatant is that it's only CPA secure, and this is not because I didn't use Kramer-Schuper or something, this is rather fundamental because I needed it to be re-randomizable. We can't have re-randomizable and CCA secure simultaneously. But let's put that aside for a second. The other problem that it has that it requires you to encrypt potentially very long plain text using very slow public key operations, right? If I want to encrypt the entire Bible, I have to convert it into group elements, then I have to run these complicated public key operations on each of these group elements going to take me forever. So of course, practitioners often don't even consider such schemes that you just immediately jump to hybrid encryption, right? So in hybrid encryption, Alice and Bob, Alice will send to Bob an encryption of some fresh random key for a symmetric key encryption scheme, and then she'll encrypt under the symmetric key encryption scheme her message. And this will be much more efficient because we only use the public key primitive on say a 256 bit key. But unfortunately, this doesn't work at all in the firewall world. And the reason that doesn't is because we can't re-randomize the secret key, the symmetric key RK. In fact, we make this formal, we show that if you have any scheme that's key re-randomizable, if we could re-randomize the key RK, so if we could convert an encryption under RK to encryption under RK prime for some new random key, then this would imply public key encryption. So in other words, you can't use efficient symmetric key primitives in order to build a re-randomizable hybrid encryption scheme. So things are non-trivial here, but the next question you can ask is what about key agreement? And it turns out the key agreement works. In fact, we have a composition theorem. This is the informal layout, which is that if you combine key agreement with the firewall and secret key encryption with the firewall, you get message transmission with the firewall. Now, this composition theorem exists classically as well. It's so trivial that nobody ever mentions it, right? It's obvious that if you have secure key agreement and secure symmetric key encryption, you get secure message transmission. In firewalls, it's not entirely trivial, but we've proven it, it's true, you can use it. And so this justifies the study of key agreement in the firewall model. So we can consider, obviously, the most natural key agreement protocol, which is just Diffie-Hellman key agreement, in which Bob sends G to the B, Alice sends G to the A, and they output G to the AB. As their shared secret key, this is secure as long as D to H is hard over the group. And we can consider a natural firewall for this protocol, in which the firewall simply raises Bob's message to a uniformly random exponent R, getting G to the R, B. Then when Alice sends G to the A, he raises Alice's message to the same exponent to R. And what's cute about this, it looks like the firewall's just mulling everything and screwing it up, but actually, even though they see different transcripts, they both will output the same key. This is actually rather cute, it's not due to me, it's due to Blaise Boomer and Strauss. But unfortunately, this does not work in our model. This actually is insecure. Even though the exponent is uniformly random, so Alice's message looks uniformly random, it can depend on G to the R, B. In particular, a corrupt implementation can essentially choose the key, right? So Alice's corrupt implementation can sample many, many keys and find one such that all the last bits, say the last 10 bits are all zero or something like this. So this is not a secure scheme. In the paper, we show actual secure scheme and the trick is simply to add a commitment, right? So we force Alice to commit before Bob sends G to the B and then we ask Alice to open the commitment because Alice has been forced to commit before sending G to the A. She no longer has this attack. In the paper, we prove that such a scheme works. Of course, there are lots of details that I'm skipping. The commitment scheme itself has to be re-animizable, it has to be malleable, but it turns out that this actually does work. So this is our CPA secure scheme. I won't have time to show you our authenticated key agreement scheme, but surprisingly, you can do authenticated key agreement with the reverse firewall. And I'll simply mention the main technical challenge that we had to overcome, which is that typically, in order to authenticate a key agreement, what you do is you make your protocol non-malleable. In fact, what you do is you take some secure signature and you ask the parties to sign the entire transcripts. And the parties will only accept the key if they see a signature of the same transcript that they've seen. So if either of them sees a different transcript, nothing will go through. But we have a firewall. We want the firewall to maul the messages. If the firewall can't do anything, then there's no point. So we actually need to construct a malleable authenticated key agreement protocol. So we can't use the standard tricks that everyone else uses, at least not the ones that I'm aware of. Oh, but it turns out that it works and very, very surprisingly, it's actually rather simple. So this is the entire scheme. It's just a rather slight variant of authenticated key agreement with Diffie Hellman with a couple of tricks. It uses a pairing and it uses a unique signature. But I'm a practitioner. I'm not a practitioner, so I don't really know. But as far as I can tell, this is reasonably efficient. I think this compares fairly favorably with something like ECDSA, which is actually deployed in practice. So I think this is quite interesting and quite surprising. And I'd love it if someone who actually is a practitioner were to look into it. So that's essentially my talk. I'll leave you with some open questions. So first of all, sort of the question that I just asked, when are reverse firewalls practical? So we've already shown in earlier work that reverse firewalls can actually do really, really powerful theoretical things. But we're now curious about whether or not they're actually practical. And in particular, is this firewall practical? I'm not the person to answer it, but people in the audience can. And would someone like to implement our CCA secure scheme? I would love this. Another question is, how do we handle adversariably chosen plain text? So currently we require some notion of correctness. As far as I know, all other models do the same. It's fairly necessary, but it will be really, really nice to get around this or to show that this is necessary. And of course, an after question to ask is what else can we do with reverse firewalls? NPC's not been done yet. Differential privacy's not been done yet. I think these are really interesting areas. And just a little question, can we do lattice-based crypto with reverse firewalls? At first, it seems like the answer should obviously be yes, but if you play with it for a little bit, you'll see that it's actually rather subtle. So that's my talk. Thank you.