 Thanks for the introduction. Yeah, can you hear me? Yeah, so I'll be talking about broadcast and trace with short circuit exercise. This is John work with Rishabh Goyal, Brainwaters in the New Weeks. So first, let me tell you about what broadcast and trace is. And in a nutshell, broadcast and trace combines two different primitives that are broadcast encryption and trader tracing in such a way that the combined protocol is more powerful than taking the true primitive individually. So in more detail, let me review what trader tracing and broadcast encryption are. So in a trader tracing scheme, you have, it's a public key encryption scheme where there are many potential receivers with each with individual keys. And the main feature is that there's a way to trace colliding users. So what does that mean? Here I suppose that Alice and Bob produce a decoding box that can decrypt the message or infer any meaningful information about the message. Then you want there to be a tracing procedure that identifies at least one trader that participate in decoding the box. In a broadcast encryption scheme, it has somewhat the same syntax in the sense that there are many users each with respective keys. But now the functionality provides a way to target a specific subset of users. So say when I am crit, I provide this for instance subset S as a part of the encryption and only Bob and Carol would be authorized to decrypt. And in particular Alice won't have any meaningful, won't be able to infer any meaningful information about the message. So similarly for instance, if the target set of receiving users is this, then these are Alice or Bob are authorized and security requires that even if they collude by combining the information of their secret keys, they won't be able to infer any meaningful information about the message. Okay, so what's broadcast and trace? Well, it's a way to combine both. So in particular, it's a broadcast encryption scheme. So whenever you are encrypting a message, you can target a specific set of users and similar to trader tracing if authorized user are producing decoding boxes, then there should be a meaningful way to trace traders. But the way that broadcast and trace is really meaningful and in particular, more powerful than just having broadcast encryption and trader tracing side by side is by having some security property whenever authorized users collude with unauthorized user. So in particular, if you would simply use broadcast encryption and trader tracing side by side, one thing that could happen by using a tracing algorithm would be to trace a non-authorized user, which is really weird because intuitively, Alice here shouldn't have any, key shouldn't have any power to infer any information about the message. So what we require instead is that the tracing algorithm should trace authorized trader. And that's really what makes the primitive much more interesting and how that should be. Okay, so let me review a bit of previous work. So there was a lot of progress in terms of, sorry, sorry, so the main quantity we'll be looking at to judge the quality of a scheme will be the scalability in the number of users. So suppose there's many, many, many users, you want the ciphertext size to be as short as possible. That will be our main quantity for comparison. So it turns out that we have many different primitives from many different assumptions. And from standard assumptions, so I'll forget about IO or Winess Encryption. Essentially, we have this, essentially optimal broadcast encryption from pairings and optimal trader tracing from LWE. But it turns out that since more than 10 years ago, the best broadcast and trace scheme that we have only have ciphertext scale we square root of N. So if N is big, this is still pretty large. So what we do in this paper is we give a construction of a broadcast and trace scheme with short ciphertext size. So for arbitrarily fixed constant size, the ciphertext size will only scale as N to the epsilon. And the assumptions that we make are both learning reserves and some banana types assumptions. So it particularly needs both. As a drawback, our tracing procedure needs master secret key in order to trace authorized traders. But this is inherited by pretty much all optimal trader tracing schemes that we have under standard assumptions. So for the rest of the talk, I'll be telling about how to build broadcast and trace with short ciphertext. And to do so, I will talk a bit about how we get, actually, optimal trader tracing from LWE and how to mirror every step in order to carefully add broadcast. Okay, so how do we build a trader tracing from LWE? Very cute recipe to do that is to use what we call private linear broadcast encryption that was introduced by Buenos Aires and others. So I will call that PLB for short. And the idea is really to, so you start with a scheme where everybody can decrypt. And the idea will be to deemble the users one by one. So what does that mean? You'll have a special type of encryption that I will call for this talk, a trace encryption where you additionally impose a threshold index. And the main idea is that the user keys with index less than the threshold won't be able to decrypt. So the first property you want is that this trace encryption, whenever the threshold authorizes all the users to be indistinguishable from a standard encryption. And then when you raise the threshold, you little by little, you disable all the keys. And in particular, in the end, no key should be working in some sense. So here the encryption should hide all the information about the message. So the last property we want is some kind of privacy of this threshold. So then as an example, if the threshold varies from two to three, of course, Bob can tell the difference because in one case, his key works and not in the second. But what we want is that Bob should be the only person who is able to tell the difference. Okay, so how do we build a threshold tracing from such a primitive? So suppose we have a decoding box that allows you to infer meaningful information about the message. Well, first we'll switch to this tracing mode. And in particular, this will be indistinguishable from the decoder, so the decoder will still work with this new ciphertext. But we know that if we increase the threshold all the way down, then the decoder shouldn't work because there's no information anymore about the message here. So what happens is that there has to be some index starting at which the decoder stops working in some sense. So what happens is that there's some index such that the decoder works here, but suddenly it kind of stops working here. And because of our privacy property over there, the only way the decoder could have meaningful, meaningfully different behavior between those two is if the secret key two was used to produce the decoder blocks. So in particular, that means that this index corresponds to a trader, and we can flag this user as a trader, okay? So how do we add broadcasting to that? We'll use a very similar idea where we'll disable users one by one, but now we want to only trace authorized user. So the natural thing to do is to only disable authorized users one by one. So what happens is similar as before, now you start with a broadcast encryption scheme, and now you add a threshold that will additionally disable users. So in particular, even in the beginning, Alice is disabled because she's not in the authorized set. And when you increase the threshold, well, in the end, the message should be completely hidden. So the only thing that changes is the privacy property we mentioned before. In particular, for instance, if I increase the threshold from one to two, what we want is that the key from Alice shouldn't be helping distinguish. In some sense, if she's not able to decode the message in the first place, her key shouldn't help, well, if I am meaningfully information about the threshold either. So instead, what we want is that when we increase the threshold here, the only keys that allow to tell the difference between two different indices are the ones that are authorized, okay? And similar as before, now, if we have a decoding box, we can set the threshold to include all the authorized users, disable them one by one, and the same argument as before simply states that the user that will trace will be now in the authorized set. So that gives a general recipe for broadcast on trace. So let me now get back to Trader Tracing, so without broadcast, and how do we build such a scheme? So our first step is to add attribute-based encryption. So if you were at the base paper top from Rotem, you know that in an attribute-based encryption scheme, there are secret keys with respect to policies and encryption with respect to attributes, and the only way the keys can decrypt some ciphertext is if, say, the attributes decrypt to one. So what it does is simply shifts all the message delivery part towards the ABE, and now what we are left to do is simply define this policy that states whether users are authorized to decrypt or not. So if in a private linear broadcast encryption, users decrypt to either nothing or the message with some privacy property over there, then in a mixed functional encryption scheme, the only thing we need to do is to decrypt to a Boolean that states whether users are authorized or not. So in particular in the standard encryption in the bottom, all the keys will decrypt to one. So a more convenient way to see that will be that the mixed Fee will be used to disable traitors. I will get back to that later. Okay, so how do we build such a mixed Fee? And the main tool that we'll use are private constraint PRFs that will be PCPRFs. And what are PCPRFs? Those are pseudo random functions that can additionally be constrained. So if you have a predicate that takes an input to the PRF, then you get a new key such that the predicate defines whether you are allowed to compute the original PRF or not. So say if the predicate evaluates to zero, then you are about to compute the original PRF value. But if the predicate evaluates to one, then the original value of the PRF remains pseudo random even given the key. Okay, so another general property that we use is that the constraint should be private in the sense that given two keys, well, of course, the two keys won't evaluate the same way on the point where the predicates differ. And the privacy property that we want is that this should actually be the only way you can tell the true constraint keys apart. Okay, so how do we build, yeah, we get a private constraint PRF from LW, pretty much. Oh yeah, so how do we build mixed-up here from a private constraint PRF? The idea would be to give to every user an evaluation of the PRF on their index. And then to the crypt, we'll check whether this, the value they get is the same as the evaluation of a constraint key over the index. So more pictorially, what happens, for instance, for the standard encryption scheme that we want to always decrypt to one, if we take a PRF, sorry, a constraint PRF that is constrained everywhere, then these, those two values will be different with hyperradiance that will always decrypt to one. But more generally, if you add a threshold, you'll have a key encryption that kind of allows to compute the original value above the threshold and not under. In particular, here, Alice would be about to compute the right value, so she will decrypt to zero, and the other users, for the other users, the original PR value is to the random, so that will decrypt to one. Okay, so in particular, the privacy property of the PRF exactly tells that the only way to tell the difference between two consecutive thresholds is to have the PR value corresponding to somewhere where the protocol differs, and that's exactly what we want for the mixed FV scheme. Okay, so how do we add broadcast into all of that? So the first insight is that if we have an attribute-based encryption that is strong enough, we can defer all the broadcast functionality into the AB. So now, the AB will also test whether the users are authorized and will only deliver the message in that case. But still, we are not done. The main property of the broadcast that we want still have to be inferred by some kind of mixed FV that we still have to implement. So again, if we start with the augmented broadcast encryption over there, where the decryption over some keys evaluates to either bottom or the message, also say here, with the threshold, it disables this user. What we want from a broadcast mixed FV is a slightly different syntactically. So in particular, in the standard encryption, all the keys with the decryption one. And we slightly change the decryption property so that unauthorized users will always decrypt to one. So that's slightly different syntactically. But what we really want is that the only way, always, that you can tell the difference between mixed FV encryption that allows everybody, in some sense, to one that is up to zero, everybody is to have the key for someone who is in the authorized set. Okay, so how do we build that? And the insight will follow a similar pattern as before. And now, so we first want to ensure that for users that are not in the authorized set, they should always decrypt to one. So how do we do that? The main idea is to make the checked value that we have kind of unpredictable, even given all of the keys. So how do we do that? The idea will be to have many different PRF keys and you have some value to use in this check, some value that remains pseudo-random, even given all the keys. So if we sum over, if the check value is this one, then in particular it contains a value like that. So I'll explain with a picture later. And in particular, the value will be pseudo-random. So in particular for every user, so there's like as many keys as there are users, and users will get evaluations on their index only for different keys. So what happens is that in the sum, you'll use some value that nobody has and that will make the checks to the random and that will make the decryption output one. Okay, so that works for us, but there's still a syntactical problem in particular. It's not clear at all how to even evaluate this. In particular before, what you had was the encryption was a constraint key, but now you don't want to give all the constraint keys individually because otherwise the argument of this being pseudo-random wouldn't hold. So the idea is to use some additional property of the PCAPRF that's called key homomorphism. So what's this property? It states that to compute a sum over different keys of PR values, there's two ways to do it. Either you can simply compute the sum of the outputs, or you can perform some homomorphic operation over the keys, and then evaluate the PRF. And what this allows us to do is to take a similar sum as before over the constraint keys, and that will finish the construction. Okay, so what we get overall is a broadcast and trace encryption, starting from attribute-based encryption, and broadcast mix safety. And I roughly showed how to build a broadcast mix safety scheme starting from key homomorphic private constraint PRFs, and those we can also build from LW, okay? But still, I didn't talk about efficiency at all, so what's going on here? Well, in the end, in the final scheme, the ciphertext will pretty much be an A-B ciphertext. In terms of that, A-B is with ciphertext? Well, we have from binary maps. So in some sense, the A-B will also provide the broadcast part, and that's why, in some sense, the broadcast functionality comes from the binary part, in some sense. But that's, there's still a problem in the sense that A-Bs from binary maps only support kind of weak families of policies, small family of policies. And partially, we know all those A-B schemes only support policies in NCO. And we know that here, the policy that dictates whether users are authorized to decrypt or not is given by this broadcast mix-to-feed decryption. So jumping back to the construction, this broadcast mix-to-feed decryption was a private constraint PRF evaluation. So it turns out that if you look under the hood, this is done using roughly login multiplication, so this is not known to be in NCO as is. So the final ingredient that we have is to pre-compute blocks of matrices so that in the end, to evaluate, you only need to multiply a constant number of matrices and that you can do in NCO. And in particular, the encryption part will consist of many of N to the epsilon matrices over there. Cool. So as open questions, we showed how to build broadcast on trace with N to the epsilon-safetype size. It's a really natural question to ask whether this could be brought down towards polylog, as that would match more closely what we have to understay IO. And roughly what I also showed before is that this could follow from two points, two different orthogonal kind of progresses either from to have stronger ABs, 16-tibs, or even, or alternatively have PRFs with a more efficient evaluation unless we could ask to have slightly milder standard assumptions in our constructions. So that's it for me. If you have any questions, I'll be happy to take them. All right. Thank you. Are there any questions? So I was wondering if I got it correctly, the trader tracing gives you the guarantee that you will get one of the authorized traders. Is there any known results regarding getting all the traders that combine the decryption box? Well, so for traders, trader tracing is not clear, but at least something that you can do with broadcast on trace is say flag a trader. And then if the decoding box still works over the authorized set where you remove the trader, then you can still trace and remove more traders one at a time. So that's not something you can do generally with trader tracing, but that's also something that is really interesting with broadcast on trace. Okay, thanks. All right, if there are no further questions, let's thank William again.