 Okay, so let me start again. Welcome to this first session of the morning of the day. It's gonna be about real-world systems. We're gonna have three different talks, one being online, the second one. And the first talk is about Cocoa Concurrent Continuous Group Care Agreement by Joel Alwin, Benedict Auerbach, Miguel Cuedo-Noval, Karen Klein, Wilermo Pascal Perez, Shestof Pichak, and Michael Walter, and Wilermo is giving the talk. That works now, kind of. Now it seems to... Okay, so is this working now? Yes, good. So as I was saying, I will talk to you about Cocoa Concurrent Continuous Group Care Agreement, which is joint work with Joel, Benedict, Miguel, Karen, Shestofa, and Michael. And so the motivation for our work is secure group messaging, where a set of parties want to communicate, and they want to do so in the presence of an adversary that has control over the network and moreover can corrupt parties. So in particular, we will talk later about this, but the parties will want to rotate their keys. So what do they do in this case? So the naive solution, of course, is just to use bi-directional channels. For example, between each pair of users, they can instantiate a signal protocol, a double ratchet protocol. But the problem here is that whenever they want to rotate the keys, this would need to be communicated independently to each individual user, which has linear communication costs, linear in the size of the group, of course. This means it's not scalable. So instead, what we want to do is to, we want users to agree on a shared common key, which they will then use to encrypt the messages, right? So this brings us to the primitive of continuous group key agreement, or CGKA, that was coined by Al Venetal in crypto 20. And very roughly, this allows a group of end users to agree on a common key, with the following properties. So we wanted to support dynamic membership. So in particular, we want to be able to add and remove users from the group. We want it to be asynchronous, meaning we don't make any assumptions on the online behavior of users. So we have some untrusted server that buffers the messages and relays them afterwards. And we want it to be secure against compromise. And in particular, so as I said, we assume the adversary can corrupt users. And if I can remove that bottom part from... Can it be removed? So the bottom of the slide can be seen properly. Well, so we want some security property to hold called PCFS, which is the combination of forward secrecy, or FS, and post-compromise security, or PCS. And for those of you which are not familiar with these two notions, let me just recall them very quickly. So if we imagine the group timeline with time running from left to right, and we imagine some compromise in the middle, which in our model means that the adversary can read everything in the corrupted device. So from all the keys that are currently stored there to all the random coins sampled during that period, what forward secrecy ensures is that all the keys up to some point in the past remain secure, and PCS, or post-compromise security in turn ensures that after some point after the compromise ends, the keys are again secure. And of course, as you can imagine, and I discussed before, we will need to rotate the keys that parties have. So what we're aiming to do is to do this efficiently in particular with logarithmic communication per rotation. So this brings us to our contribution, which is a new protocol, COCO, a new CGKA, that allows for concurrent key rotations that do not have, that do not degrade the efficiency of the protocol. And in particular, our protocol overcomes previous impossibility results on the communication of such concurrent protocols by relaxing the requirement on post-compromise security. What does relaxation mean? I will go into it later. And we also introduced the notion of partial states, which allows us to decrease the recipient communication of such protocols. So during this talk, I will give you an introduction on Trichem, which is the main example of such CGKA. We will discuss a bit about how concurrency in Trichem looks like. And then I will tell you about our protocol. We will talk about how concurrency is handled, efficiency, these partial states, and a few words on security just before introducing a couple of open problems. So let's talk about Trichem. Trichem is the CGKA underlying MLS, which stands for Message Layer Security. And it's a working group by the ITF, trying to standardize group messaging. And its aim is to scale to up to 50,000 users. So in particular, these efficient key rotations that I discussed before are really important, right? Because we're talking about very big groups. And just to give you a historical note, this was proposed together with MLS in 2018 and Replace Art, which stands for Asynchronous Ratchetine Trees. So what does MLS look like? It assumes a binary tree where each node has an associated keeper and the users are associated to the leaves. And the arrows here denote either encryptions or hash evaluations. So in particular, what this means is that if a user knows the key at the node that is at the source of an edge, they will also know the secret key corresponding to the node at the sink of set edge. So in particular, it follows that a user will know the keys for the nodes in their path, right? So in particular, this user A will know the keys highlighted in green. And the key associated to the root, which is shared by all the users, is the group key. And this will be used later to encrypt messages or derive a symmetric key to encrypt messages or whatever this CKA is used for. Before I told you that we can rotate our key material using only logarithmic communication. So how could we do this? So let's say here A wants to rotate our keys. So what does she do? And so what she does is she will sample a new seed for her leaf, a zero. And by evaluating a hash function, she will just sample new seed for all the nodes in their path. From this, you can derive keepers, so a secret key, public key. And then she will create encryptions of these seeds and the node in the copa. So in particular, if we look at this node here, for example, we see that a single encryption from the root node allows all the four users in this sub tree, sorry, in this sub tree to learn the new key, right? So in particular, this means that we only need an logarithmic number of ciphertext to communicate the new keys to everyone. So the continuous edges here are encryption edges, in case you cannot read it. And the other ones are hash edges. And then the new keys substitute the old ones. So what this means is that now all the previous keys that were in, all the keys that used to be in A is the state are useless now and not part of the tree. And let me just very quickly go through how we can handle removes because this will be relevant for later. So if A here wants to remove E, what she does is samples all the nodes, sorry, blanks all the nodes on E's path. And blanking here means that these nodes will then have no associated key. So these keys are useless. And effectively E is removed from the group. And the effect that having a blank node in the tree has is that if we imagine that A now wants to update, so what this says below, it says that if you want to encrypt to a blank, so in this case A, the root, she would want to encrypt to this node, but this node is blank here, right? So instead she will need to encrypt to something called the resolution, which are these two yellow nodes. And essentially, informally it's just the smallest set of nodes to which she needs to encrypt so that all the users in that subtree learn the new key. So effectively, having blank nodes degrades the efficiency of the protocol because more encryptions are needed. With respect to concurrence in Trichem, we can differentiate between two versions. So we have plain Trichem, which corresponds to versions before seven. And this is not concurrent. And updates need to be processed all in order. So in particular, if we imagine two users, A and B, that want to update at the same time, one of them will get their update accepted by the server, the other one will be rejected. And the one that gets it rejected, say B, will need to then process the update by A and then issue a new update that hopefully will now get accepted. So in particular, this means that if we want T users to update, to rotate their keys, we will need T communication rounds. In contrast, we have propose and commit, which corresponds to versions eight and up. We are currently in version 14. And this does allow for concurrent updates. And what it does is, let me see if I do this. Perhaps you can see the bottom. That's a, sorry. Yeah, but here I don't have it actually. No, I actually see a different screen from here and there, but yeah, well, perhaps we can do it like this so you see a slightly more of the screen. So we have propose commit, which is another flavor of Trichem where actually we can have concurrent updates. And what we have here is a decoupling of operations between proposals and commits. So users can send proposals which just get buffered and not applied immediately. And then a commit will collect several of these proposals and execute them simultaneously. So what this means for post-compromise security is that we can achieve it in two rounds regardless of how many corruptions we have in the tree. So before we call in the previous flavor of Trichem, if we had T corrupted users and we want all of them to update, we will need T rounds. So here we need two. And the way this would look like is all corrupted users could then issue an update proposal and then a second user could just commit. All of these proposals would get executed concurrently and that's it. And this incurs a communication which is linear in the number of updating users. So this is actually shown to be optimal if we want to heal in two rounds by being stuck at all in TCC20. This sounds good. The problem of course is that having these update proposals ruins the tree structure. So having this fast healing in two rounds degrades the performance. And just to give you an example of what this looks like, let's say that C, E, and F want to propose updates here and then A comes along and commits them. So what a proposal does is it just simply send, so if C wants to propose an update, they just simply send a new key for the leaf. Here are Martin Blue. And when these proposals get committed, what happens is that the old key gets substituted by the new one and then all the other nodes in their path get blanked. So now this new key sample by A need to be encrypted individually to all the leaves because all the inside nodes of the tree are blanked. So of course this tree is fairly small but in general you can see that the communication can be degrade all the way down to linear. So in particular we're back at this trivial case of bidirectional channels that we mentioned at the beginning which is what we wanted to avoid. So if we want to see, look at this pictorially perhaps to have a clear idea, plain tricking, we could imagine it as some long queue of users waiting to update. Whereas proposed commit will allow a lot of users to do it all at once at the cost of perhaps degrading the or making it harder for future users to update. The realization that we have in our paper is that we can actually do better if we don't require PCS to hold in two rounds but instead we relax it to perhaps heal in a few more rounds. So let's talk about how concurrency is handled in cocoa. So let's say here that two parties A and C want to update concurrently. So they would propose updates just as in Trichem. So A would sample the new seeds together with encryptions, C in blue would do the same. And now the question is how do we apply them? So if this affect, so if a node is affected by only one update, such as would be the case for this node, for example, we just apply them as in Trichem. However, if an update, if a node is affected by two updates like the node in the intersection of the two paths, then we would use some ordering to choose which update takes precedence. So this ordering can be chosen arbitrarily, can be chosen by the server or could just be some fixed pre-agreed ordering like right most user wins. And we just have a new tree where we see that the update from A didn't make it all the way to the root but that's okay. What does this mean for PCS? So let's take the same example where now A and C are corrupted. So here the red signal is the keys that the adversary has knowledge of. And let's say they both update with the same ordering as before. So what we can observe here is that as before if a node has only been affected by one update, it will heal. But the node and the intersection will get encrypted to an old key from the key, sorry, the C that the intersection will get encrypted to an old key from A which is under the knowledge of the adversary. So in particular, the adversary can decrypt, learn the new C, derive the new key and learn the two new keys for those two red paths, right? So even though both users updated, there are still some insecure keys but nevertheless the updating parties made some progress. And in particular if any of them do a future update they will heal. So this sort of highlights the difference between our protocol which heals the tree layer by layer as opposed to tricking, the plain tricking would just heal the tree path by path or propose and commit which would just heal the tree all at once by just flattening it. Yeah, sorry. So of course we don't consider such simple examples where the corruptions end at the same time. But in general the statement we get very informally is if we consider a group key K in some round then we say that this key is secure if the following is true for every user. So for each user we look at the last time they were corrupted and then we require the following. Either the user performed a logarithmic number of updates from the last time this corruption happened finished or they performed at least one but such that no other user updated concurrently to them. So if we again go back to our pictures we could imagine as cocoa as something where the users do need to go through more updating processes but they can do it all at the same time and without damaging any structure. When it comes to efficiency I have a table here which highlights some of the points. So on the top we would just have plain tricking which as I said is just non-concurrent so we would just take n rounds to heal. So sorry, here I should say I am plotting the cost of healing an arbitrary number of corruptions per user and here we are assuming that there is no knowledge of who is corrupted and no coordination. So in particular all users will try to update since they don't know whether they are corrupted and also they cannot agree on an ordering. Also for simplicity of course there are no further corruptions or ads and removes in between these processes. So as I said that the top protocol non-concurrent we just take n rounds then we have three protocols so proposed commit the Binge Talk at all protocol there's a typo should be TCC 20 and bi-directional channels that all can heal in two rounds at the cost of linear communication per user and moreover they have the cost that they destroy the tree structure to some extent so subsequent updates per user would cost either linear or in the case of Binge Talk linear in the worst case but logarithmic on average. The trade off that Coco brings is fairly obvious so we take a few more rounds to heal so logarithm n plus one but on the upside the communication both for senders and recipients is now logarithmic square and moreover the subsequent update cost is still logarithmic and one particular thing to point out is that we have logarithmic number of rounds we have a linear number of users updating in each round so we would expect the recipient communication to be at least n log n, right? However it's log n squared and this is due to partial states which is the thing that I will talk about now. The observation here is that if we want users to keep track of the changes that happen in the whole tree then this incurs a download size which is linear in the number of updaters. However, A in this case only needs the keys for the green nodes which are the ones for which she knows the secret key off so she needs these for the encryption and she needs the public keys for the purple nodes because she needs to encrypt to these nodes whenever she sends a message. However, she doesn't care about the black keys about the keys for the black nodes. So what we have is we have the server only relay packets for A whenever these packets correspond to ads or removes or correspond to update information for the green or purple nodes and all the packets that correspond to black nodes the server just does not relay so A does not need to download those. This seems simple enough but it actually poses a lot of challenges which I'm not going to go into detail here but just to give you a flavor of the sort of things that we need to solve. So one is consistency. Intric and consistencies are short to through mechanisms called transcript has and tree hash. These are both a hash of the group history and some miracle commitment to the tree. But of course as I just said in Cocoa the users nor know the full tree nor know all the updates that take place so we cannot no longer have a unified definition of what users cannot agree on which operations have taken place or how the tree looks like. So instead we rely on the server to somehow complete the view of the tree through some commitments to sub trees. The second issue we run into is what it means defining what it means for a user to process an update and I'll motivate this with an example. So let's say that B updates here in green samples a new key and A before updated log in times or rather ceiling of log in plus one. So from our predicate we would want security but the server is assumed to be malicious. So what happens if the server ignores A updates and never sends those to B? Is the key secure? Well of course not because the new key sent by B is just encrypted to the old key of A, right? So we need some notion of B processing A sub dates and this turns out to be fairly non trivial in the partial states regime. And as a last challenge consider the case of removals. So as I mentioned before when a user is removed blanks are created. And what this means is that if you recall if A now wants to encrypt to this note here she will note she cannot because there's no key. So she will need to encrypt to these two notes. So A after E is removed A will need to learn the public keys for those two notes. And the question is how does she do that? Because of course by a synchronicity we have no guarantee that any party knowing them is online. So the server will need to send those public keys to A but then A needs to actually guarantee that these keys are correct. And again this also poses some challenges. So if you want to see how we solve all this and how we prove it secure then I invite you to read the paper. But in terms of key security we prove cocoa secure in the random oracle model against an adaptive partially active adversary. And partially active here means that they can control the server but cannot impersonate users. Our proof has a polynomial loss. And we've adapted proof of a client at all from SMP 21 for tainted tricking. And just so to give you a summary. So in this paper we present cocoa a CGK protocol that can recover from arbitrary number of corruptions in a logarithmic number of rounds without degrading the efficiency of subsequent updates. And in doing so we circumvent a lower bound by relaxing PCS. And we show that especially states are possible and in particular that they bring a great decrease in recipient communication. And as open problems we would like to better understand the trade-off between communication cost and the number of rounds that it takes to heal as well as whether we can prove active security for cocoa where we allow the adversary to actually impersonate users. And just to give you a taste of some related work that just came out called DECAF for the centralizable CGK with fast healing we actually consider a different way in which you can merge concurrent updates. And this allows us to heal in log t rounds at the cost of not being able to use partial states. With that I will finish and I'll take any questions. Thank you. If there are any questions for Guillermo please come to one of these two mics over there. Can you scroll down? Ah, sorry. Sorry, T just a number of corruptions. Sorry. Any questions for Guillermo? All right, so do you use the random oracle to make some adaptive proof, some programming possible or is this just to simplify the proof? No, so our proof needs a random oracle for proving activity, yes. Thank you for your talk. I was wondering what kind of key agreement is used in publicly available messaging apps such as Signal for example and do you have discussions with them so that they can adopt your solution in their app? So I think most, I think each app is different but so Signal will actually use bi-directional channels I believe whereas WhatsApp I think will use something called sender keys where the key for, so for groups the key is only rotated a belief when users are added and removed from the group so you actually don't get as a strong PCS. I know we have not talked to them but the work we're doing is sort of complementary to the MLS which I guess is a standard by ITF which hopefully would be the one that would get adopted. I'm not sure what their particular views, for example Signal does care about the liability which I'm not sure is totally compatible with some of these but you know. One last question maybe, very quick one. No, everybody's happy. Okay, let's thank Willard Morgan and the next presentation will be online. It's about efficient schemes for committing authenticated encryption by Mihir Belare and Viet Tung Hoang and Viet Tung should be online to give the talk. Let me share my screen.