 I'd like to talk about our work, Non-interactive Anonymous Router. This is joint work with my student, Ke Wu. And the anonymous routing problem has been studied for decades. The goal is to let users communicate without leaking who's talking to who. In this picture, we have end senders and end receivers. And there's some permutation pi that determines who talks to who. And we also call this permutation pi the routing permutation. Now these users want to talk to each other without leaking the message contents, not the routing permutation itself. Many solutions have been proposed to tackle this problem. You may have heard of MixNet, the dining cryptographers net, tar and many other systems. Interestingly, all of these existing solutions have something in common. They require decentralized trust and they require interaction. In other words, typically there are multiple routers and they interact with each other to accomplish the anonymous routing. And to get the anonymity guarantee, we have to trust that a threshold number of these routers are honest. And because of the decentralized nature of the scheme, these protocols are typically not so easy to implement. And in some cases, they may not even have a simple straightforward abstraction. When I was working with my systems collaborators, they kept asking me, can we do this non-interactively on a single untrusted router? I thought it was a really intriguing question. So I started giving it some more serious thoughts. We can first look at a silly solution. Suppose that each sender receiver pair shares a secret key. Every sender can now encrypt its message under a key that's shared with its own receiver. And it'll send the ciphertext to the router, right? So the router will collect all end incoming ciphertext and they'll send the collection of all end ciphertext to each and every receiver. Of course, each receiver can only decrypt one of them with its key. So this scheme is indeed not interactive. It works with a single untrusted router, but the block in communication is linear in the number of users. And that's very expensive. So instead we ask a more refined question, can we achieve the same? But with succinct communication, meaning that we want the communication to be, we want the communication blow up to be poly kappa where kappa is the security parameter, right? So we want basically the communication blow up to be independent of N, the number of users. So this requires us to think harder. I claim that if we have virtual black box obfuscation or BBB obfuscation, we can solve this problem. And the idea is like this. So everyone encrypts their message under a common public key pk. And there's an office gated program. The program has a decryption key which allows it to decrypt all the incoming ciphertext. And then inside the program, you will basically apply the permutation to the decrypted plaintexts. And then it'll encrypt each decrypted plaintext message under the corresponding receiver's public key. So in this case, their public keys are pk1 through pkn. And now essentially when these output ciphertexts are sent to the receiver, they can each decrypt with their own secret key. Okay, so one thing important to note here is that here, you know, what's the BBB obfuscation? What is this obfuscated program hiding? It's hiding not just the secret decryption key, but actually also the routing permutation itself. Okay, so this game actually works and achieves 16 communication. And for the only drawback is that we know, you know, BBB obfuscation is actually impossible. Let me tell you our results. And then I'll go into technical details. So at this moment, you may think, you know, maybe program obfuscation is really necessary for this task, but quite surprisingly, we show that, you know, we can achieve this without any obfuscation. We just basically use standard bilinear group assumptions. We call the resulting construction non-interactive anonymous router and it has a cute acronym, which is NEAR. In our scheme, there's a one-time trusted setup. And basically after this one-time trusted setup, standards and receivers can exchange messages for unbounded number of iterations. And more specifically, the setup will give encryption keys to all the senders and it'll give receiver keys to all the receivers and it'll give a token to the untrusted router. And the communication blow up of our scheme is just like I said, basically polykappa and independent of N. Our scheme achieves security, not only against the untrusted router itself, but also in the presence of like, you know, potentially corrupt players. Like in particular, imagine a subset of these senders and receivers can be corrupt and they may be colluding with the router. And even in this scenario, we want to make sure the adversary cannot learn the communication pattern between honest senders and honest receivers. Okay. So at the core of our construction, right? The technical core is essentially a new function privates, multi-client functional input chain for the selection operation. So I'll dive into this part later and you'll see how it works. But before I go into the technical details, I want to quickly mention a crew application of NEAR, which is to implement a non-interactive and anonymous shuffler. So imagine a COVID-19 daily checking application, right? So every day, let's say each user will encrypt a daily report describing whether he or she is feeling well, whether they've tested positive for COVID. And we want to protect the anonymity of these users. On the other hand, we want to be able to track the same users' reports over time. And that's why we call such a system pseudonymous. And we can realize this with a non-interactive anonymous shuffler and basically, imagine we give the shuffler the token that's usually given to the router and not only so we give the shuffler the receiver key for all receivers. And now the shuffler can basically decrypt the shuffled reports. And another way to think of this is like, essentially the schemes make sure if you want to decrypt the incoming ciphertext, you are forced to apply some unknown shuffle to the incoming messages. Okay, without further ado, let me show how we can get this result. In the interest of time, I'm only going to be able to explain our approach at the high level. And some of the details may not even be precise, right? So I suggest you read our paper for the formal details. And the plan is the following. I'll first explain what is a multi-client functional encryption scheme for selection. As I mentioned earlier, this is the technical part of our construction. I'll explain how to get a near scheme from a multi-client functional encryption scheme for selection. And then I'll describe how we can construct such a multi-client functional encryption scheme. Okay. So let me first explain what is a multi-client functional encryption scheme for selection. First, there's a one-time trusted setup. And the setup is going to give secret keys, EK1 to EKN, to each of the N senders. And it'll give N tokens to the router, denoted TK1 to TKN. In each time step, the sender can encrypt a message, denoted X1 through XN here, under its secret encryption key. And the message is encrypted to the current time step T. Recorded router has N tokens. So each token will allow the router to decrypt exactly one message that's destined for one receiver. Here, the token TK1 is selecting the message from the fifth sender, which is destined for the first user. So basically every token would allow the router to select one user's incoming message. And that's why we call the scheme a multi-client functional encryption scheme for selection. And when you apply all of these N tokens, like you'll get to select all N outcomes. And basically you obtain the permuted and decrypted plain texts. Okay, so at this moment, you may be puzzled because it may seem like, in this case, I'm saying the routers are sending these plain text messages to the receivers and that's not okay because then the routers can see these plain text messages. But I want to just point out that in our final near scheme, essentially these X's, they're not plain text messages, they're actually inner cipher texts themselves. Like basically each XI, you can think of it as an inner encryption of the message using a key that's shared between the corresponding sender and receiver. So okay, so basically keeping in mind these X's can be inner encryption themselves. Now let's look at the security requirements for multi-client functional encryption scheme for selection. Informally speaking, we want to make sure that the router learns only the permuted and decrypted plain texts. And if some senders are corrupt, the router can also learn these corrupt sender's destinations. But beyond this, the router should not learn anything else. Like in particular, the router cannot learn the communication pattern between the honest senders and honest receivers. Another way to say the same thing is that we want this multi-client functional encryption scheme to be function hiding. Each token should be hiding the coordinates it is selecting and then the collection of all of the end tokens would hide the permutation. And another thing to observe is like, it turns out maybe partly because the selection operation is kind of like a trivial operation, it turns out if you don't require this function hiding property, then the scheme would be trivial because there's nothing left to protect. The only thing non-trivial we are protecting here is the routing permutation itself, right? Because the router, we allow the router to see all the decrypted and X's. Okay, so going forward, I'm actually only going to focus on a single token, right? Even though in the entire near scheme, in the near scheme we are going to have end such tokens and each will allow you to select one message. Okay, and before I dive into the construction, I want to mention that the function hiding requirement actually implies that no mix and match attack should be possible. And let me explain what this means. So here the blue ciphertexts correspond to the end sender ciphertexts for time step six and the grace ones correspond to time step seven. And let's say we are given a token and it's possible to apply the token to all of these gray ciphertexts because they all correspond to the same time step and the result would be selecting one of them. Similarly, we should be able to apply token to all of the blue ciphertexts too because they also belong to the same time step. However, it shouldn't be possible to perform the following mix and match attack. Let's say you take one blue ciphertext combined with the other gray ciphertext and then you apply the token to the combination. In fact, if mix and match is possible, I claim that the router would be able to learn exactly which coordinate is being selected and this would break function privacy. For example, let's say the router wants to learn whether the first user's message is being selected. All it has to do is to let's say swapping this blue ciphertext corresponding to user one and it'll check if the decrypted result has changed. If it has changed, then it must be the case that the first user is being selected. Okay, so with this in mind, I'll go into the construction, right? Because later on, to help with intuition, it's actually helpful to revisit how our construction defends against this mix and match attack. Okay, so let's dive into the construction. First, let's introduce some useful notation. I'm going to use bracket X to denote a group element. So we'll be working with a group subprime order. So bracket X just means G to the X where G is like a generator of the group. And if I just write X without the brackets, that's an element of ZP. So it's, you know, you can think of it as an exponent. And P is, you know, the prime order of the group. As I mentioned, if we actually don't care about function privacy, then multi-client functional encryption scheme for selection would be completely trivial because there's nothing left to protect. Nonetheless, let's first look at such a trivial scheme. So imagine every user encrypts its plain text XI using just let's say Algamot encryption. So here SI denotes the secret key for user I of the Algamot encryption scheme. And the master secret key is like simply, you know, the concatenation of all of the user's secret keys. So I just omitted from the slide. Okay, imagine I use this notation B sub I to indicate whether user I is the one being selected by some token, right? So if BI is equal to zero, it's not being selected. BI equal to one, that I is the user that's being selected. So the final token consists of n components, one component corresponding to each user and denoted TK superscript one through TK superscript n. So just to be clear, like here, they're not n different tokens, like for selecting n different things, they are all the same token. We are only selecting one thing. And these terms just like, you know, they belong to the same token, but we can take this token apart and there's like one coordinate corresponding to each user. Okay, so more specifically, each TKI is of the form BI comma BI times SI. And more specifically, we can think of it as following. If user I is not being selected, then both of these terms become zero. So in other words, user I is not contributing any meaningful term to the final token. On the other hand, if user I is being selected, then these two terms become one comma SI. In other words, in this case, user I is contributing its secret key to the token. So in essence, if you think about it, the scheme is just very simple, like every user is encrypting its message using Algma. And the token is just the secret key of whichever user is being selected. I'm writing it out here a bit more laboriously in a vector format just because I want to make sure the decryption operation is an inner product between the ciphertext and the token. And this will be used for later because later when we do care about function privacy, decryption, you know, decryption cannot be just picking out the component I want and just performing the decryption only on that component, right? Because then that makes which users being selected. So we do want to make sure the decryption operation is going to basically touch every user's coordinate. Okay, so that's why I'm writing it out in this vector format. And so far, you know, I haven't done anything interesting because as I said, this is just a trivial scheme. In the next step, I will make this trivial scheme a bit more complicated but without achieving any meaningful protection at all. And this is what I call preparing for the function privacy upgrade. Okay, so although in this step, we are not introducing any extra security, I promise that later on when we do the actual function privacy upgrade, like these extra terms we introduced here are going to be very useful and specifically they're going to be critical in preventing the mix and match attack. Okay, so as I said, here we are introducing a couple of randomizing terms to use as ciphertext and also to the token component corresponding to user I as well. And let's try to navigate through this notation, right? So first T, as I said, is the current time step and the function F is a special pseudorandom function. So for the time being, just think of it as a pseudorandom function but we actually need a special property like we call it a correlated pseudorandom function and I'll explain what correlated means in just a little bit. The private key Ki, right? This is the private key for the PRF and Ki is included in the user's encryption key, EKI. So you'll also see this term AI and AI is also now a new part of the user's encryption key and this term will show up like in both the ciphertext and the token and also when the trusted authority generates a token, it's going to sample a fresh random value D and D is sample per token and the same D is going to be shared across all users' token components. Okay, so it may be confusing what's going on here but to see what's happening, like it's easiest if we just take the inner product of the ciphertext and the token and see what we get and if you do the calculation, some of these terms are going to cancel out and you are going to see what comes out is Xi times Pi plus D times this randomizing term and specifically if user i is not the one being selected, all you'll get is like some randomizing term but if user i is indeed the one being selected, you'll get Xi which is the value you want to actually select plus some randomizing term. Okay, so now let's take the inner products, the partial inner product from every user and we will sum up everything and see what we get, right? So when we sum up the contribution from every user, we first get the inner product of the plain text vector X and the selection vector B and note that X in the product B is exactly the value we want to select and not only so, we also get a second term which is like the sum of all these randomizing terms and as I said, we actually need the PRF to have a special property and we call it a correlated PRF and now it's a good time to explain what it is. The property I need is that when I sum up these randomizing terms from our users, they cancel out and you'll get zero back and importantly, like if you mix that match, let's say I take randomizing, these randomizing terms but from different time steps and then I sum them up, then it's not going to cancel out and you'll get garbage back. However, if you collect the randomizing terms from our users corresponding to the same time step, you sum them up, then they would indeed all cancel out. Okay, so that's the capability of a so-called correlated pseudo-random function. I know I haven't told you how to construct such a correlated pseudo-random function but I want you to take my word for it. You can get it just like from a standard pseudo-random function. Okay, so basically just to repeat, if I take the inner product contribution of each user and I sum everything up, what you'll get back is exactly X inner product B and that would be the value I want to select. Okay, so at this moment we are actually ready for the function privacy upgrade. Let me first tell you how the upgrade works and then I can tell you why these red terms are here and how they help prevent mix and match and in fact, I kind of alluded to it already. So the idea is basically I want to evaluate the inner product contribution from each user in an office-gated manner, such that only the answer is revealed but not any of the intermediate values. And to achieve this, we are inspired by a couple earlier works, in particular the elegant work by Ling in 2017. And the idea is to use a single input functional encryption scheme for inner product which I denote IPE here. So IPE stands for inner product encryption. Okay, so I will compute an IPE key for the ciphertext vector and compute an IPE ciphertext for the token. So there will be any instances of IPE one for each user, right? And now when I want to compute the inner product I would actually be computing it's using the IPE's decryption algorithm. So in other words, I'm evaluating the inner product wrapped inside the IPE. And we know that the security, the encryption security of the underlying IPE would now protect these terms in the key. And slightly informally, you can think of it as, basically this is an obfuscated evaluation of the inner product such that only the answer for each user is revealed, but nothing else. Okay, so this is like very close to our final scheme but it's not exactly the final scheme because we actually had to deal with more technicalities to make it fully work. Nonetheless, it's actually a good time to reflect why we needed these red terms before we do this function privacy upgrade. And the reason is exactly what I had said, right? Because, you know, these randomizing terms and if you collect these randomizing terms for all users belonging to the same time step then all of them would cancel out and you just get back the message you want to select whereas if you mix and match the time step then you get garbage back. And this is nice because when we are actually evaluating this inner product, each user's contribution of the inner product in the obfuscated manner, essentially, you know, only the contribution from each user would be revealed. And when you put everything together this basically prevents mix and match. Okay. I also want to mention that, you know although we haven't implemented our scheme yet the scheme is actually concretely somewhat efficient and it's amenable to implementation. Like you may want to perform some optimizations before you implement it. Okay. And before I finish, I want to quickly mention about some earlier related work. Our work is actually closely related to multi-client functional encryption for inner product because selection is a special case of inner product, right? Selection is basically inner product the selection vector where it's the one in a single coordinate and zero everywhere else. Okay. So multi-client functional encryption for inner product has been studied in several earlier papers and there are many constructions that are either based on bilinear group assumptions or lattices. But it turns out that none of this scheme would work in our context because it turns out they're not function hiding. And because we need something that's function hiding basically the key technical contribution we make here is essentially how to make the scheme function hiding. And this was like the techniques I talked about. Okay. There are several additional results in our paper. For example, while the basic scheme I've mentioned uses only bilinear group assumptions we additionally introduced a paranoid notion of security. So in most practical conceivable scenarios the basic level of security suffices and we don't need this paranoid security nonetheless for theoretical interests we explored this paranoid notion and we showed that assuming the existence of indistinguishability obfuscation we can get paranoid security. We also considered a tolerant version of near also our paper contains formal definitions and proofs and it turns out actually even to formally define the security requirements when near turns out to be like a somewhat, somewhat subtle. And I would refer you to the paper for more details. Thank you so much.