Real-World Security (Eurocrypt 2026)

Okay, welcome uh back everybody. I think we can start uh the next session. Uh this session is the real world security session. Uh we will have four presentations. Uh each one of them 20 minutes long. The first one is [clears throat] external operations tree and the security of MLS in RFC 9420. Uh it's a joint paper by kas crea vessel camp and mangzo and Ezra is going to give the talk. Okay. Hello everyone. I am Esrainsai from SISPA. Today I will present our work on the security of MLS in RFC 9420. This is a joint work with my co-authors Cascar vessel camp and Maxo. MLS was designed as highly secure asynchronous group messaging protocol that scales efficiently for large groups. It allows dynamic membership and provides strong security guarantees such as forward secrecy and post compromised security. MLS is set to become the backbone of many globally deployed messaging applications. It is already used by Cisco Webex, Discord, Ring Central, Fire and XMTP. Google and Apple are implementing end to end encryption between these devices by using MLS as a part of RCS. Matrix and Vicker will also move to MLS. Finally, MLS is the base of an addative protocol for messaging interpability namely Mimi. That means our work directly helps to provide provable guarantees affecting millions of users in real world. MLS has been evolved in around eight years starting from draft zero in 2018 to finally standardized as draft 20 in 2023 by IATS. Every version update includes some new features and modifications. Many advanced operations has been integrated to MLS beyond the basic operations that has been analyzed in previous works. Uh the main one of the main category of additional operations are so-called external operations. However, the latest approval guarantees was only given for draft 12 in 2022, which leads us to the central motivation of our work. We wanted to understand what additional grantees uh the final version of MLS actually provides when these external operations are also considered [snorts] at the high level. MLS separates operations into proposals and commits. Proposals are used to suggest changes to the group such as adding or removing members or updating keys. Propits are responsible for collecting these proposals uh resolving any conflicts and applying them to transition the group into a new epoch. And repo refers epoch refers to a distinct face of an continuous group key agreement session and any change in the group states initializes a new epoch. MLS has a complex key structure. It decreased the frequency of key update from every um message to every epoch since there are seven. For each epoch, a fresh set of secret is derived through key schedule. This starts from init secret from previous epoch combined with a commit secret which is then expanded into epoch secret and finally into application secrets used for encryption. Before moving to the external ad, let me briefly explain how the regular ad proposal works. When there is an outsider who would like to be a group member, an invoker that must be within the group generates a regular ad proposal. It fetches a key package that containing a fresh leaf node for the outsider from the key service and adds it to the proposal by issuing a commit not necessarily by the um invoker. However, still must be within the group. A new member's leaf node is added to the ratchet tree. The committer then sends to a new member a welcome message that contains all the necessary information to join a group including the current group secret which is encrypted by the outsiders uh key and the secret key of the lowest not in the tree. The information in welcome message is encrypted encrypted by the init key from the key package. Since draft 15, MLS includes external self proposal which allows an external party to propose the add itself to the group. To this end, Invoker first generates a key package that wraps two data structures and uh a leaf note and then init key followed by signing this key package using the identity secret key. The invoker generates a proposal message include then the intended uh group identifier intended epoch proposal type for this case new member proposal and the signed key package followed by signing all of them together and finally invoker um outputs the propo signed proposal message and eventually by issuing a commit uh by the from the side of the uh group uh members existing group members. The outsider eventually adds added to the group. We showed that the following grantees can be uh achieved in MLS by using uh external self proposals. In terms of confidentiality, a regular commit that includes regular or external self proposal is secure unless no designer in this epoch is corrupted. For the authenticity, we prove that once a party's identity signature public key has been exposed, its external proposals can always be injected by the adversary even if the circus of previous epoch remains secure. Second feature is related to update path. In MLS, users can process update to refresh their key schedule essentially to heal their um key package uh from the s uh session state. This provides per session state can be secured by using good randomness. We exemplify this from the retro tree as follows. Here um leaves represent the members and all three keeps the group state. Members only know the secrets in their direct path. Here the purple nodes represent that represent the secrets that member A is able to know and the green nodes that attack the computer circuits in some of the uh purple nodes. If one of the member commits that remove member D and rein operation namely update path is issued and the corresponding note will be blanked with member removal per session state is secured by rein. Um according to RFC for commits including only ad proposals uh including uh both regular or external no update path is issued so epo keys remain the same. Accordingly we showed the following guarantees can be uh differentiates for the uh security. A commit c remains secure unless a member edit in epoch is later corrupted before performing any key update. In that case the adversary can recover the secrets contained in the welcome message breaking confidentiality of that epoch. The third new feature is external commit which is more sub operation. Since draft of 10 MLS includes external commit which serves two purposes. First it enables an external user to join an open group as synchronously without asking any existing members to edit. To this end, external user upon having the public group info object first parses it to receive the group information and the signature. Group information contains uh values including uh group group identifier, epoch, sander text and hpka public key. The invoker first verifies the signature, checks the valid of other group variables, derives in initial secret for the key schedule and initializes the next epoch. Finally, it generates a proposal and creates external commit to add itself. Eventually, it becomes a group member without have ever been the group before. The second purpose of the uh external commit is reync. Basically, it allows an existing group member to uh replace his prior representation in the group with a new one. Different than the previous case, the committer who is already a group member generates a self remove removal proposal. The remaining process is very similar with the regular ad. It generates a self- remove proposal, access of the regry, optionally remove itself from the current group, rekeys the path, signs the commit content, computes n transcript hash and runs the key schedule, generates the confidentiality tag and external commit message and associated group info object. finally outputs the external commit message and the n uh group info. Eventually, it reyncs itself with the group. External commit is expected to achieve weaker guarantees than the one created by the regular commits. In terms of confidentiality, once the secret included in external commit is leaked uh by some randomness leakage or adversarily injected by a forgery, then the secrets in this epoch can be directly exposed even if the group member session states remain uncompromised. For the authenticity, we prove that the exposure of a party's identity signature public key can further yield the leakage of all secrets of following epochs. Before moving to the details of uh our compromise, it is important to clarify one of the core security guarantee post compromise security. Informally, a two-party protocol provides PCS if Alis has a security guarantee about communication with Bob even if Bob's secrets have already been compromised. When we move our focus to the group case, in the state-of-the-art PCS is considered as a client to return a fully secure state. So previous works show that PCS is achieved through key updates. Notably, we notice that external operations somewhat decrease PCS when a party rejoins the group because once the identity's long-term key has been leaked, the adversary can impersonate this party and rejoin the group by using this party's identity kit at any time. We exemplify this from uh from a Consider a group where member Charlie is compromised by Mallalerie. [clears throat] Here Malerie compromising the state of uh Charlie including both long-term and per session state can proceed as follows. In case of external operations are not allowed after this compromise the committer's key package can be regenerated by issuing an update path. So the compromised members state fully uh returns their fully secure state. Hence PCS is achieved. However, while ex while considering uh external operations after this compromise, the adversary who's compromised the member and then lost the current state can still rejoin the group by leveraging external operations. Specifically, it uses long-term identity signature key of the Charlie to rejoin the group. So in our work we showed that we proved that PCS cannot be achieved when reync and rejoin is a case. In the proof side in our functionality uh this PCS vulnerability is reflected by changing which epochs are considered safe and when the adversarial inje injection is allowed. Specifically it is reflected in two places in our safety predicate. First for external operations injection becomes possible once the signature is exposed. So we changed our injection allowance con by considering long-term identity signature keys. Secondly the session state compromise can be healed by secrets replaced. Accordingly we changed our secrets replace by considering updated secrets for commits except add only proposals. In the end, long-term identity signature key compromise can still enable uh external uh commits. [snorts] Apart from that uh this uh we also have the following uh additional observation. [snorts] In practice, RFC requires implementation of IATF version of the ED2559 signature scheme which is SUFCMA secure. Additionally, RFC allows for the use of ECDSA variants for FIPS compliance and that is EFCMA secure. Notably, we showed that when the underlying signature secip is not sefmma secure, the core consistency propert of the tree cam can be violated. Adversary um adversary uh can manipulate the two parties that is expect to achieve uh achie achieve the same state unable to communicate. Assume Alice send suppose Alis sends a commit message C to Bob and Charlie here Bob is the malicious insider here malicious Bob can create a commit message C prime by marking the signature within the commit C without knowing Al's secret key and computes a MAC if necessary to do to generate the C prime Bob already have all the necessary materials as it is already a group member finally Alice and Bob Alis Bob and Charlie process different commit uh messages and end up in different state even though the signed data is identical. So the adversary can make two parties that would expect to agree on the state and unable to communicate. In practice we expect many implementers will pro will provide FIPS complent secure messengers and that necessities the use of ECD use of ECDSA signatures. Hence in these implementations divergence is possible. Here are the references of this talk. In the end, I would like to conclude this talk by giving a short summary. In this talk, we analyze the MLS in RFC 9420. We introduce two functionalities, ET and ET plus. We show when external operations are considered, MLS groups cannot fully recover their security after the randomness of a member has been compromised. We proved that the usage of pressure keys can uh partially mitigate this vulnerability and we refine the necessary level of signature security by identifying an unintended behavior. Apart from this, we also have a number of great observation. So please feel free to scan the QR code and see the full version of our paper. Thank you for your attention and if you have any questions, I would be glad to answer. [applause] Thank you. I think we have a few minutes for questions. Do we have any questions in the audience? Yeah, I see one hand up there. [snorts] One one. Okay. Yeah, it's working. Uh, thank you for the great talk and the great work. Um, I have actually two questions and I think we have time. So the first one is why did you choose UC model? Because there are a lot of models that analyzed MLS before and the second question is you analyzed something that was introduced in I think version 14 but now as far as I know there is version 20 of MLS standard. Was there any change comparing to version 14 in exactly this external operations or not? Thank you. >> Um great talks. First regarding to UC choose of UC uh MLS is a huge protocol and in the state-of-the-art the previous works the main references we uh took were all UC based so we just we extended their modeling and it helps us it helped us greatly to uh to to to to proceed instead of uh making a new security model from scratch in game based uh we just took the main references that I showed in the very first slides and we expanded their model so shortly to be consistent with state-of-art regarding second questions in this work we analyzed the latest uh standardized version not the draft uh the previous draft so after the latest drafts uh standardization uh there there were no any other uh drafts or anything this is the Yeah, the latest version. Any other questions? Perhaps one more from myself. Do you think that there is a planned update now after this work? >> Oh, sorry. Can I >> Do you think they will plan to update now after this work? Um as far as I know uh MLS is fully standardized and uh IATF is not planning to make any uh update uh afterwards. Okay. >> Okay. Thank you. Anyone else? If not, I think we can thank our speaker again. [applause] Thank you. >> [cough] >> Great talk. Okay, for our second talk, uh this will be a talk entitled group key progression strong security for shared persistent data. The authors are Matilda Bakendal, David Balbas and Miro Haler and Miu will give the talk. Thank you for the introduction. Uh welcome to my talk. I wanted to start with uh talking about security guarantees that we have for data and transit and how they compare to what we have for data at rest. So for data and transit such as MLS that we just heard, uh we often have security guarantees in the event of compromise. So for example uh we have forward security meaning that an adversary who compromises a user cannot derive keys from epochs prior to the compromise but they may be able to derive keys later and in practice we can achieve this in the simplest possible way for example with a hash chain where we just hash the state of the previous apoch and if you want to go back you would need to invert a hash function with which is hard then we also have post compromise security which means that if the bry gets passive at uh some point you can introduce new randomness and that way you can move on to a new key material and lock the adversary out. But uh this is different for data address. So for example, if you have an adversary who compromises the device where all the messages are stored, then uh this also leaks past messages uh because they're just stored there in plain text and so you don't get any forward security. Also uh if those messages are eventually backed up to the cloud and if you use a static key for this backup then um if the grocery gets a hold of this backup key then you also don't have any post compromised security because eventually new messages will also be uploaded and encrypted with the same static key and then the rest also gets them. So really the question is why do we have all of these cool guarantees for data in transit and we don't have them for data rest and so the key takeaway here is for data at rest um the access must be maintained for correctness so you can't use any ephemeral keys you can't use ratcheting that you can't undo because you still need to be able to um rederive the same key material to further guarantee access to the data. But uh our goal is to do better. And so to see how we can get there, let's consider the example of a shared uh folder that for end to end encrypted files. Uh so here we use the end to end encrypted threat model. So we don't trust the server at all. And uh we consider three members Alice, Bob and Charlie. And so consider that Alice uploads a file. Maybe Bob downloads it at some time and at some point later Charlie is compromised. And so now the question is is this file compromised or not? Well, with all good questions in life, the answer is it depends. In the case that the file was already deleted before the compromise, you could get security by using puncturing which uh prior work has looked at and there essentially the idea is to update the local key material so that it can no longer decrypt this one cipher text while still being able to decrypt the others. But it's relatively expensive. Um but we're not interested in that case. We're interested in the case where the file was not deleted. And so in that case, you have a static key. So, uh, yes, of course, the file is compromised. Um, but one thing to note is that it's also compromised if Charlie left the group even before the file was uploaded. And, uh, the only thing that prevents Charlie normally from decrypting this file is regular access control by the server. The server just doesn't give the cipher text to Charlie. And so, Charlie can't decrypt it, although it has uh, the key material to decrypt it. And that's concerning because uh for example uh legal pathway pathways could be used to compel a storage provider to give out the cipher text or there can be data leaks that leak the cipher text to Charlie and then Charlie can still decrypt it. So our goal is to do better for uh this persistent data. And so the idea is that we can advance epochs on uh when group membership changes similar to what is done in messaging. So, for example, when Charlie leaves the folder, we could just rotate the keys, move to a different key, and then um the new file that is uploaded is encrypted with a new key, and all the members that are still in the uh group will need to keep track of all the keys that are used. Now, this has its limits. Uh if Charlie was part of the group when the file was uploaded and we assume um yeah uh then basically the file is leaked unless you make uh you relax for example the threat model uh which is something that updates encryption does which makes the assumption that you don't get the cipher text at the same time as the keys but uh if you have a honest procurious server for example you always have access to the cipher text so you can't get uh this kind of guarantee and then the final case we can look at is if Charlie joins the folder after the file was uploaded. And so in that case, if you don't give Charlie history access to files that were previously uploaded to the folder, then Charlie doesn't know the key and then it could still be secure. So note here that uh also the uh epochs are completely detached from the file lifetime. A file that was uploaded before can still exist in the folder. It can just not be decrypted by Charlie. The key rotations are really only dependent on the um the the group membership changes. So in our work we formalize this interval access uh control security notion for shared persistent data and uh particularly we try to limit the impact of compromising a user to the minimal interval which is when the user was part of this shared folder and uh it should not be able to derive any files that were uploaded before or after um they were a member of the group. And so to do this we introduced two primitives. One of them is group key progression which is a group primitive for rotating keys on group operation changes and the other one is a symmetric primitive that allows us to derive an interval of keys from a compact state and we instantiate GKP based on CTK from messaging and hashbased interval schemes which is something we introduce and this construction achieves IA and also post compromised security for persistent data and uh then we'll conclude this talk with a bit of a discussion. So let's jump right into it. Let's uh first start with a simpler version of group key progression. This simple version has the following syntax. We have an operation to initialize the state of a new user. Uh you can create a new group and you can uh every member can perform operations on this group. So for example, they can add a new user to the group. Uh as we've if you are familiar with messaging and as you've seen before, there is this propose and commit paradigm. Um, so this will all look familiar to you and CGKA was actually also an inspiration for our syntax. If you're not familiar with this, you need to think of this as a decentralized asynchronous algorithm. So you can't just run one algorithm to add a user. You actually need to also process this command on all the other users that are already in the folder so that they can update their local view of the group and also know that there was a new user added to the group. And then we also have an instruction uh where the invited user can process the group invitation called the welcome message. And uh so this will give this gives us different epochs that are changing on group membership changes. And now we want to also be able to derive keys from uh any of those uh for any of those epochs. And here it's very crucial to note that with any epoch we also mean epochs in the past. And so that's different from C2K where you cannot uh do the same. Uh for the security we consider a threat model with a selective adversary that uh needs to declare at the beginning which users is going to compromise but it might wait until it actually compromises them and then uh we expect security until that user was compromised. We also give the adversary full control over which group operations are performed at what time and in which order. We assume that adversary cannot forge or inject messages. It is possible with our construction to get authentication uh guarantees but we just left them out for complexity uh to reduce complexity and we also assume a passive delivery service. Uh the delivery service is what distributes the commands uh for all the members in the group and uh this is a relatively standard assumption in the messaging literature that we inherit because we also uh use primitives from messaging literature. All right. All right. So the security notion here is that we capture IA with respect to group membership changes. Uh which means that all keys outside of the um interval where the user was part of the shared folder should be indistinguishable from random to that user. So now let's look at a naive way to instantiate this simple uh GKP protocol. There was a lot of work in the messaging community on how to rotate keys on on group changes. So we want to take advantage of that. Uh so what we're doing here is we're building on continuous group key agreement uh which is also a part of MLS and um there uh you need to note though that um old keys cannot be rederived from future from a current CK epoch and in fact if you could then you would break the forward secrecy guarantee that you get uh and so you can't have that uh but still we can use it as a transport layer in our application. So what I mean with that is the naive instantiation could do the following. It could just uh pick a fresh random key for every epoch and then encrypt this key with the CGK group key which is known to all current members of the group and not to anyone that's not a member of the group. And then we can set this to all members and they can store that key and they can keep storing all of the keys for every uh epoch and that way um you can get a scheme that is uh that is secure. The problem though is that it doesn't have good PCS guarantees. uh but uh to see that you need to uh realize that all the files that are uploaded within the same epoch they're all using the same epoch key. So within that epoch you don't get any PCS and that's particularly a problem because the group composition might change much more rarely. So for example consider a shared folder with four people which are using the folder for years then you don't get any PCS for those years. So clearly we want more epochs to get better PCS. But now we have the problem that we need to store all the keys for all the epochs and so our storage grows linearly with all the keys and that's a problem because it increases storage size. It also increases communication cost because we need to send this state to for example newly invited users. And uh in general it's a problem for having uh applications with many users or that are longived. And so the key takeaway here is that we need a primitive to derive many PO keys but from a compact storage. And so that's why we designed another um primitive which is we call interval scheme that achieves this. The syntax for this interval scheme is as follows. You can initialize a global interval state which is the state from which you can derive a global sequence of keys and then there is an operation to progress this interval state one epoch at a time to add uh more epochs. You can also export sub interval states from this global um um interval state and uh you can even extend once you have a sub interval you can extend this by exporting an extension from the global key sequence and then applying this extension to a sub interval to grow the sub interval. And now in the end of course the goal is to derive keys from these epochs. And here the correctness guarantees that every interval state that covers a certain epoch um if it the epoch is covered you can derive an epo key and also that epo key is consistent with all of the other um keys that you can derive from any state that covers the same epoch and the security notion is simply IA meaning that if you have access to a sub interval any epoch that's not covered by this sub interval um you should not be able to derive those keys. In fact, you should not be able to distinguish those keys from random. So, let's make an attempt to build this. Uh remember that in for data and transit, one thing we can use is hash chains. So, the idea is we can use something similar here. This is known as dual key regression in the literature and it works as follows. We need to decide on how long our chains are at the beginning and then we use two chains and those two chains run in opposite directions. So we have a forward chain that runs um here on the slide from the top to the bottom and then we have uh backwards chain which is derived from the bottom to the top but we release elements in the reverse order. So we first pick the seed at the very bottom and then we derive all the elements and then we release them in reverse order and um then every horizontal level is an epoch and you can derive epoch keys by running a key combiner on the two chain elements for that epoch. And this key combiner actually needs to be a double PRF which was a security notion that was previously missing in the PRF literature and we proved that it's implied by dual PRF. Uh you can see the paper for this. So let's sketch how we can build an interval scheme from this. Uh the most interesting ones are how do you export an a sub interval? Well uh you can do this by sharing um L and BN minus R the two darker elements. And then you can notice that from L you can derive any uh element on the forward chain that is after L and from BN minus R because it runs in the opposite direction you can derive any element before that. And so in particular for the keys KL KL to KR you can derive both chain elements and so you will be able to derive all the keys for that interval. But um for the intervals before L and after R, you're missing one element for one of the chains. And so you won't be able to derive those uh those key those keys. It's also easy to extend this. You just give out the next the element in the reverse direction of the particular chain you want to uh in which direction you want to extend to. So uh one um problem with this is that we have leakage from from a single interval. And so it turns out that if an adversary compromises multiple intervals, then you can combine this leakage um to actually derive keys in between those intervals. And um you can fix this and that's what we're doing with uh with our extension of DKR. Um and uh you can do this by rotating keys. Uh the details are a bit intricate uh but they are uh really crucial to achieve efficiency, but I'll refer you to the paper for the rest. Uh the key takeaway for for here is that uh the GKP instantiation can efficiently derive EPO keys from interval states if it somehow can manage to um keep this global key sequence somewhere and also if it uses um if it can use key rotations carefully to prevent leakage from multi-user compromise. So this now we can finally put it together and have our final group key progression syntax um or primitive where in addition to what I introduced for simple GKP we now add operations to add admin users to the group and though and we add uh update operations which can advance epochs without the group composition changing and that's good for PCs of course. So now it's finally time for grapa our instantiation of GKP. Grapo is the combination of uh dual CGKA which uh and an interval scheme called our interval scheme called DHF. Uh dual CGK uses basically two CGKAS ones for members and ones for admins and that allows admins to have secrets among themselves. And so that allows them to maintain the global interval state and all members only get uh access to sub intervals. And so then for most operations admins can just release new backwards chain elements and that doesn't cost any storage. Um so that's great. And then for some operations if a user is removed we we rotate the forward chain so that no that that user can never derive future keys. And if uh in rare cases the admin is removed for example we need to rotate the backwards chain and those operations grow the storage a bit. But the crucial thing is the operation we want to run all the time. The updates they um they they don't increase the storage space unless we run out of a chain uh the length of the chain but that happens rarely and so uh we get PCS with very low storage costs and our construction also very carefully avoids using pair user messages and that allows us to still preserve the efficiency from CGK. Speaking of efficiency, we implemented a simulator for uh Grappa and we uh ran this uh for 10 to the five operations with 500 users and five admins um and compared basically our instantiation with different ways of instantiating interval schemes. There is the trivial one with the one key for epoch and then there are two others that use three uh constructions to achieve the same same thing. Um and so you can see here in in the the plot that our um DHF construction was the most efficient for our particular use case. But if you have a different use case, if you have a different probability for operations, if you for some reason have way more user additions or so, you could change these parameters, use our artifact and figure out which one of those performs best for you. So uh let's wrap up with a discussion of uh um future work. Uh, grapo can not only be used for shared folders, it can be used for any application that has shared persistent data. Um, so for example, it can also be used for messaging backups. Um, you can also see our RWC talk uh from last year where we talked about some limitations um of the MLS API that we ran into when we wanted to use CGKA as a transport layer. um if you're interested in that. Another limitation is that we uh don't have active security uh for the CGK part. Uh that's an active research direction in CGK and uh we just wanted to have some something that is efficient. Uh but once someone figures out an efficient way to do this for CGKA, we could use that in our construction because we use a blackbox and uh this would need to be proven but probably we could get um active security guarantees then for also GKP. Uh there's many exciting extensions that you can do for this. Um for example, we could see how we can get immediate post compromised security without an admin coming online. Um you can look into how to grant people history access in a shared folder for example. Or there's a way to reset the growth of the state uh of intervals by sacrificing some of the security guarantees. And uh we could also look into temporal access removal from from the the group. Um some of these add storage overhead or uh require per user channel. So we will need to evaluate uh which ones make sense for which applications. And um yeah with that uh we have our paper online um since the year already but we just recently made an update. Uh so you should definitely pull the newest version and we also have a reproducible artifact um where if you have a big server and an a day of time you can reproduce our simulation results. Uh yeah, with that I'm happy to take any questions. Thank you. [applause] >> I think we only have like 30 seconds left for a question. So if it's a yes, no question, we can take one. [laughter] >> Otherwise, catch me in the break. >> Yeah, catch them in the break. All right. Thanks again, [applause] All right. So, now we have our third paper. Yes. This is the Yeah. >> Okay. Yeah. >> For the slides. Good. Uh third paper of the session is at compromised security, the case for alert blindness. It's a paper by Martin Alrech, Simony Colbo, Benjamin Dling, and Ricky Ber Yensen. And the speaker today is Simony. >> Thank you for the introduction. So just to specify, Martin, myself and Ben are cryptographers and Regga is agrapher. So all the authors are in the room together with other ethnographers. Uh before starting, I would like to warn you. So in this talk I will discuss about abductions and torture. So I think it's kind of fair to say at least in this session that we try to base our work on the real world and then when we write our introductions we want to convince also reviewers and readers that our work is indeed based on the real world. So we propose to imagine scenarios to prove this or we give examples because we really think that our models, our solutions, protocols, games are based on the real world because we believe faithfully believe that this is the reality of things. But behind these seemingly simple qu sentences in an introduction, there are quite a lot of questions as Blanchett back in 2012 mentioned. So for example, where do the requirements to consider a work based on real world come from and how can we identify real world so natural security concerns? Well, on these questions, the cryptographic literature remains mostly silent. And that's why I think we often define our new security notion in a speculative way. And actually this morning we heard that everything is cryptography but we think also that cryptography is multiple things because beside being a technical science cryptography is also a social science because cryptography models potentially adversarial relationships. That's why our answer to these questions is ethnography. So it's through ethnographic findings that we analyze the social relations that I mentioned before and from this analysis we discover security practices. So the natural security concerns that I mentioned before and we study them with cryptography. So my goal today is to try to unpack this very dense slide with the following outline. I will introduce or mention a bit ethnography. Then I will talk about the social foundations of our security notion which is at compromise alert blindness of which I will talk and then I will conclude and mention some future work. So let's start with ethnography but first let's start with some context. So the context of our work is the genz protests in Kenya. So in 2024, unprecedented large-scale protests erupted in Kenya, sparked by the 2024 finance bill. And the goal of this bill was to raise taxes to pay the debt of the International Monetary Fund in a country where life was already unafford unaffordable for many. So the peak of this protest was on the 25th of June 2024 where there was the largest protest and on that day some protesters managed to enter the parliament and the senate. The response of the state was to kill and injure protesters. in uh as a consequence of this uh uh protest movement, this finance bill was actually withdrawn on the day after this big the biggest protest. Uh but smaller scale protests continued until the 8th of August. It's in this context that we observe that abductions emerged as a new security threat. Abductions by William Ruto's repressive forces. Well, William R is and was the president of Kenya. Concretely, we know about 82 abductions between June and December 2024. On the day of the biggest protest, we know about coordinated abductions of at least 50 known protesters and then additionally 15 abductions linked to the one-year anniversary in 2025. And it's important to say and to remark that the whereabouts of several abducted people remain unknown today. It's in this context that we apply the ethnographic methodology because a methodology that comprises two pillars data collection methods and then analytical steps to analyze this data. And this is exactly our technique to introduce ethnography in cryptography to discover to uncover from the data from this ethnographic analysis security goals and it's through the application of this technique that in this work we arrived at our security notion that I will discuss shortly but first let's talk about these two pillars. So data are collecting are collected during field work and field work is a long immersion in the setting. So for us was reus immersion in the social movement in Kenya and this long immersion opened up access and relationships with a wide network of activists and as you can see on the slide rea spent more than six months in Kenya between 2024 and 2025. During this time she collected data and data collection in cryptography is really about a deep hanging out in the field not only focusing on security practices but on ordinary life of people in the context. She collected data using mainly two approaches. So the first one is active participant observation. She attended 11 protests in Nairobi. She also attended activist meetings, planning sessions, strategic discussions and community gatherings. but also as I mentioned the ordinary life day-to-day activities in informal settlements. During this time she also conducted ethnographic interviews 77 of them with protesters among which eight abducted people and these interviews were loosely structured around the topic guide because one of the goals of cryptograph uh ethnography sorry is also to let people speak and that's why the duration of the interviews is pretty long as you can see once this data are collected well they have to be analyzed and for us the analysis was conducted across the two disciplines. So across ethnography and cryptography during between and after the field work and during this analysis we applied inductive reasoning which could be a bit unknown for for this audience which might be more used to deductive reasoning. Inductive reasoning is really about developing the theory from empirical data not from a preconceived hypothesis. Concretely for us in cryptography [snorts] this means we did not go to the field to test an intuited security notion but we really analyze the data coming from the field to discover this security notion uh concretely. So the initial analysis was conducted by the field worker because for ethical reasons the cryptographers don't have access to the raw data but then we did a collective analysis and formalization between the three cryptographers and the field worker the ethnographer. So okay this is uh about ethnography and now let's see what this data analysis actually showed us. So I mentioned before that abductions emerged in that context and setting. Um and actually the goal for abductors for the adversary was to abduct people to gather intelligence information and often there was torture involved. Abduction then torture to get information. Psychological tortures to get answers but also physical torture. Participant 72, an abductive from Nairobi, said they were using a tool. I don't know whether it was an iron or hood hitting me on the arm. So, I still have injuries while they rolled up their sleeve to show the scars. In response to this, we observed during these protests the practice of raising an alarm. Now, I want to read out this quote because it's very important and central. I wrote to him a message, very brief message. Hey, I'm being abducted. I don't know where I am. After I had texted him, he took the screenshot of the message and posted it on X. So, that is how it spread. Funnily enough, after like 30 minutes or so, as the abductors were driving me around, the car stopped again. They opened the trunk and then they started beating me up and then they asked me, "Where is that phone?" So they knew that I I had another phone because my friend shared my screenshot. I think that is the only thing that saved me because if it wasn't for that message, these guys had another motive because nobody was aware of my abduction apart from that one message. So they could have killed me and taken me somewhere nobody could have known. So we have abductions, torture with the goal of gathering intelligence information about the protest movement and the practice of raising an alarm that emerged. Why? Because after raising an alarm uh shouting could happen across platforms like I mentioned X before because we observed a network of connected and non-activists could amplify this message and this created a feedback loop. the abductors eventually hear the message which put pressure on them to release the abducted person. So those are the social foundations of our security notion that we introduce in this work which is called at compromise alert blindness. Informally this mean that when someone is taken the abducted person can alert their network without the adversary noticing that they are alerting the network. But of course to reason formally about this we need a syntax in cryptography. So we propose a client server protocol composed of two phases. A setup phase which is trusted and an alert phase. In the setup phase the client can run so the person actually can can run the client setup function that takes as input a key an application key. Think about a key protecting your signal messages and a personal secret like a pin or a password and outputs a client message and device state. This client message goes to the server. The server runs the server setup function with the client message to output the server state. This is the end of the setup phase. In the alert phase, the person can run the request function on the device that takes a input the device state and the personal secret to output a client message. Client message goes to the server. Server runs the response function. the response function that takes as input the server said and the client message to output a detect boolean value and the server message and then server message goes to the client and the client can run the get key function to recover the application key. Uh when I said that we formally uh discuss we formalize the security practices I really mean that we formalize security practices. So we define them. A game is a definition, a formal definition. But here we do something more because thanks to electronography we can prove this claim. We can discuss and prove actually with data this claim. We can say this game correctly responds to security needs of some organizers and frontliners in Kenya in 2024. I mentioned that we arrive at our security or new security notions and definition in a speculative way. Now we can actually claim that this is the correct security notion in that settings and context. So in the remaining time I will go over some parts most important [snorts] parts of this game. First thing you might realize is actually uh that we decouple um people from their devices right so we have the device state and personal secret because we have our own secrets. Not all our secrets are on our devices fortunately. And actually we also have agents in the world right and we observe that of course abducted people know when they are abducted. So they can use different personal secrets depending on the situation they are in. And now I will go over these three winning condition uh that encode three different security properties in this game. The first one is confidentiality. So we know from the data that abductors wanted to know who was funding the protest. They wanted to gather intelligence information. What what this lines winning condition formalizes is that we exploit the abductor's goal to access information. We say that breaking the king distinguishability bit D requires at least one message to reach the server in which case the received flag is set to true. And why we need a message to go to the server? Well, we because we want to send an alert. So this second winning condition is really about this make this appearance publicly known. Participant 51 in the long quote that I read before said I think that is the only thing that's safe. This line says [snorts] that any pin any PS0 different from the setup pin PS1 the one was used during the setup phase triggers an alarm on the server meaning that detect is set to true. We are almost there but we need the third property. We need blindness. So in this case is the bit there bit B that selects the personal [snorts] secret in the game. You might think okay why about not giving the pin at all. Right. Well non cooperation was impossible. If I do anything now to upset these guys I'm dead. Participant 60 said a consequence of blindness is that the protocol always reconstructs the key because otherwise blindness would be broken and because more importantly abducted people would cooperate regardless. Non cooperation was impossible and this is something we could learn from the data. And I want to be perfectly clear here. We give up confidentiality at this point in the game for alert because confidentiality is already lost and because the goal for people in that time in that situation was alert and I think this is a goal that only ethnography could suggest to a group of cryptographers that think that confidentiality is the most basic and needed property. Uh actually I just discussed the game in the paper we give uh and actually also implement a provably secure construction under this notion. Uh let me move now to the conclusions. So in this work we bring ethnography in cryptography to determine to discover security goals. We apply this technique to study at compromise security and ethnographic field work with protesters in Kenya reveals. So we discovered it from the field the goal of our alert blindness. What about future work? The my first thing you might think about is okay what should the server do when there is an alarm? For now we just set the detect flag to true and this might be actually not enough right? So we are starting a codeesign phase with people in Kenya with participants in Kenya to find out what we should do once an alarm has been raised on the server. [snorts] Then we might think okay could this notion be useful somewhere else like can at compromise alert blindness be useful in other contexts and maybe but we need to study we need to understand this context and maybe one of the takeaways of this thought is really before thinking or throwing a security solution in some context or setting we need to understand with ethnography or other means but what we do is ethnography understand the setting and Then of course we will uh and we are actually applying our technique to other settings and context. And before concluding and taking uh your question, I would like to emphasize that this work would have been impossible without the contributions from protest protesters and activists in Kenya that trusted us with their experiences. Uh and on this I conclude and I'm happy to take any question you might have. [applause] >> [applause] >> Okay, we have a few minutes. Does anybody have a question? I think I see a raised hand in the back over there. A little bit towards maybe to the right from my perspective here. Yeah. Thank you for the talk. um wanted to ask you one thing I couldn't understand is um does it mean that if I just feel the device I can always access all the data because uh what you said is that and any password that is not the actual password will raise the alert but so does it mean that the data on the device are not actually protected or maybe I misunderstood >> no the data on the device are protected by the key But you can think of this as something embedded in an application not the entire device like an application that stores your uh documents to which the adversary wants to have access would have this because at some point in those situation you have to give those documents to the uh to the adversary. So it's not the entire device you envision this to be embedded in some application on which you have your secrets. >> Okay. that when I access the application uh still if I input a different password I can still access. >> Yes. Because in this goal again in this goal we need uh we we gave up confidentiality because the goal was alert right in a normal situation you access your pin your with your normal PIN. But then of course if you can think someone else gets your phone you you need a pin an initial pin on the phone and then a secure enclave but made of cryptography and not of hardware with more your [snorts] most important documents that has this alert property. >> Okay thank you. >> Any other questions? Oh yeah I see two more. One way in the back and one in the middle here. >> Thanks for the nice talk. So in your example um confidentiality meant for example revealing the identity of the organizers of the protest which might put them also in danger. So why is um giving up confidentiality for alert always the right choice. So okay your qu okay your question is why giving up confidentiality is a good so you are asking why we can give up confidentiality and not because this would put put people in danger right >> well because so for us we didn't decide this I mean we we really read that I mean we we sat down with the data that someone that spent six more than six months in Kenya brought back and this is what the data were telling us in that situation people would would cooperate regardless. Confidentiality was lost. I mean they they were tortured and killed. So at that point of course they would perhaps put someone in danger. I mean police forces had a a quite good idea of like the relationships there but still I mean we did not decide what were the security properties there. We we sat down with the data coming from there and this what what is what emerged from the data. >> I'm saying maybe there are other compromises you can make like other solutions or other um tradeoffs that are possible. >> I I think there there might be other trade-offs. I think there might be other directions uh that we can explore from this work. But it's important to say that adversary wanted knowledge of the data on the device or or on the app or some data there. So if we don't give those data non cooperation was impossible. So we have to be careful about the trade-off and I think it's interesting but we have to understand and and we don't have to project our own beliefs and variations on confidentiality. We have to wait for the d or to read the data and from there we can know what we have to implement and to think and to define. >> Okay. Thank you. >> Okay. All the way in the back. Is your question short or if it's going to be a long discussion then? Okay. Short question over there please. In the back. >> No no very top. >> At the very top. Last question. >> Okay. Thank you. Uh have you considered a malicious server? because as a state level adversary this could be a possibility. >> Yeah. So we have another property in the paper that deals with a malicious server that cannot recover the key but this the server is trusted in this case for the alert because I mean we we trigger the alert on the server but we have another property in the paper that this deals with actually a server that is compromised after the fact and we want to protect the application key in that case. Yes. Thank you. All right. Well, thank you very much. This is a very very good uh very good talk and paper. Thanks. [applause] All right. So our fourth and last uh talk in the session is about postquantum TLS 1.3 handshake from CPA secure chems with tighter reductions and there's a lot of authors Jin Rang Shen Bingu Rang Mao Chen Haang Jiang Yi Wang Shini Wang Yunlay Zhao I hope I pronounced that correctly sorry and Moti and Moti will give the Yeah, some some people they look at it, they don't know me and they say, "Oh, this is the Chinese guy's paper." Because my last name can also be Chinese names. So, uh before I start my talk, a remark about the previous talk. uh you know that uh uh Google accounts are are being uh hijacked by bad guys and then you have to either return and and get try to return and things like this and these things happen. There was only I I worked on account recovery at some point and we got from a very uh reliable sources that in some country this guy who is the father of this woman who is a friend of mine that we can verify was abducted please hijack his uh account don't let anybody access it. So confidentiality was important there and after verification and so on and understanding the geopolitical the company hijacked the the the account from the from the person as a method to protect all the others who were uh discussing with this uh opposition whatever. So sometimes confidentiality is important because it in the data includes endangers other people. Okay. But now now to my talk. My talk is about TLS 1.3. TLS is everywhere. We don't need ethnography to understand the importance of it. We only need cryptography and communication. It's web browsing. It's email. It's messaging. Uh cloud services and you name it. all using uh TLS which used to be TLS 1.2 2 which used to be TLS which used to be SSL over the years and it's a very uh well analyzed protocol by many people and I'm not going to mention all of them because just mentioning all the previous relevant literature uh will take the the 20 minutes and uh also the our paper itself is uh very detailed long paper that is uh about uh reductions by simulation arguments and it's very long and I'm not going to get I'm not going to get into the the details of it. I'm going to show one or two uh one or two uh things I'm going to mention it. On the other hand, the slides will have the details because remember these slides they have dual purpose. So one is to enable me to give this talk so you see something. The second one they go they go on the website for other people to see it and then the slides with a little bit more details will uh encourage the people to to read the paper. The paper itself as I said it's it's a it's a long journey in simulation studies and other and other techniques that I will mention and uh it's one of the longest simulation paper it's it's real world but you know it's one of the longest theoretical simulation argument and concrete that that we have done in in recent years it's more than seven did I already say that it's more than 70 pages it is more than 70 pages even if you cut the the references. So uh TLS 1.3 uh so there is sync and sync ank and then then there is uh then there is >> moti >> yes >> can I just interrupt one second there's a little bit of back feed or something in the microphone they would like to change Okay, now I'll be I wanted to prove everything by hand waving and now I'm less capable of doing it. So uh so we have this uh the client uh sends essentially g to the x uh uh and uh and uh then the the uh the server sends g to the y and you know plus other things signing the the thing hashing the previous rounds everything that you need to combine everything and also at the end with the mcking and kind of finishing the the the the key exchange, the authenticated key exchange, but at the end they they they they share a key based on the defy helman key exchange that we were reminded that it's 50 year old today in Anna's lecture and uh this was the best incident in your talk. The worst incident was about the losing of the election key that I want to apologize for. So uh but you know if you do nothing you will never have any mistakes. So sorry I do a lot. [laughter] So uh so no need no need no need. things that just happened. So, so this is the classical one. So it's essentially defy helman and then key derivation function that deres key for the max for the encryption of the future uh payload of the session and but but but the the the core technique is defy helman and now cryptography is under various uh stress sources nowadays new things you know as as though as we solve the old problems which we didn't we have quantum which is this talk we have AI that who knows whether it's going to how it's going to influence cryptography and um and also blockchain and new applications and so on and so forth. So so the field is growing not just in number of attendees of Euro but in a number of subjects that we need to cover. So this is the classical again without all the gory details but there is like start of a session start of a of a of a session and then continuing of a session and and and and acknowledging that we just uh established keys and then starting to to to send data and many people worked on on this area because this is authenticated key exchange essentially. I think the first paper in the crypto eurocrypt uh series about this was a paper that I was uh author of and Anna reminded me that you have to talk about your own work. So in 1991 we actually had a a an IBM project to do or to improve what I show broken LU 6.2 authentication. This was pre pre- internet that was systems network architecture and we defined parallel sessions which exists here and we defined matching executions which are here and we had the paper and then many other people uh many of them working for IBM like rogue crafty crafty kaneti improved on this and and and this this led this is really the foundations of especially TLS 1.3 authenticated encryption and and and and and things like this. So it's good it's good to see progress and this is less than 50 years. This is from 91. So um the the the the the quantum the postquantum. So this uh this started in uh the call for I mean quantum quantum was always there from the creation of the world but but the call for proquantum uh uh primitive started in 216 and and and go went on went on went on and one of the suggestions to replace uh defy helman because we know defy helman is discrete log discrete log is broken by the the shore uh famous uh algorithm. So what was what was suggested uh was CAM key encapsulation method in which one side sends a public key. The other sides do encapsulation of the key K, encrypt it with uh the public key in a cipher C and send C to the other side. The other side who owns the public key the trap door of the public key can de do can perform decapsulation and recovery K again because of Anna's lecture I have to me mention my own work and this brings me back to a note that I wrote in crypto 85 more than 40 years ago a note a note that was called symmetric public key cryptography just for the fun of it. And the idea was you know everybody is doing now zero knowledge proofs interactive. So if we go to interaction I can exchange essentially exchange a key in the have a cam and I can encrypt from both sides based on just one one side having a public key not two of them. So we can avoid full uh public infrastructure. It's a short note. Now everybody understands this. It's why did we write this paper? Because we thought it's very important. It will be very important to practice and uh I hope to show it. So um there are uh there are chem security notions indistinguishability under chosen ciphertics attacks. Erh indistinguishability under what is called one CCA one chosen ciphertics attacks one CCA. This is different than this by by the number of oracle calls to to to to the to the decapsulation oracle decapsulation like decryption and there's of course indistinguishability under uh chosen plain text attack and even oneway uh oneway security of of of uh CPA. Uh so of course uh NCCA allows the the adversary to get a challenge and to uh ask a decryption oracle uh to to decrypt as well. That's the that's the CCA versus CPA and then you get the answer. Of course the adversary is limited to ask on everything but the target cipher text. Whereas uh one way CPA is uh just uh the adversary just get uh get uh uh get the cipher text essentially the description of the public key and and the cipher text and it has to has to output kar it it is like oneway functions. So anyway, so uh so all these notions and these are weaker and weaker and weaker notions and uh have been used before and uh the goal of all this work that uh we have been doing is to uh there is a tightness of the security reduction between uh hard problem and a protocol. I want to show that uh adversary against a protocol will fail because this adversary against the building block or the basic problem erh will uh will uh will fail and the the the differences between the adversary. this this guy succeeding and this guy succeeding is L which is the loss and we want to minimize it and you know this proof by by reductions is what is the foundation of modern cryptography theoretical cryptography the uh the first guy to use it before even the foundations was uh Michael Rabin who be just after the RSA function had The rabbin encryption function which was based on squaring as with squaring you can show that if you can find square roots you can factor and that was reduction between two problem and I want to mention even though it's not my work it's Michael Rabin's work it's timely to mention it because Michael Rabin passed away just two weeks ago you know one of the giants of of the field and it's worth mentioning so so uh so So the tightness of the reduction this L if it's if it's one then it's very tight but if it's more than you lose the tightness and if if there's too large an L you actually lose the meaning of security you pro security but it's insecure you know one million uh times more than this and you know you start losing it and of course uh we are talking about the replacement for the quantum area. So we will use random oracles and quantum random oracles and this is the only mention that I will do of quantum and uh now now the TLS uh 1.3 is changing the the DLman is out and you put a cam you put the client decides on ephemeral public key sends it to the server server. The server performs the encap encapsulation and derive the key from the encapsulated data SS send it back to the client. The client who came up with the public key and has the secret key can decapsulate and recover SS. Now they have uh the same uh key and of course the the the server also have the public uh signature on the transcript on the hash of all the past and they can change max as before to to finish the the key exchange. So so uh this is the the new thing and we we have to prove it. So [snorts] uh what security requirement is needed for CAM and how much it affects the security of TLS 1.3 and existing results showed uh showed two things that one technique to prove it and this is Hugan Hugan Dumiten and Vod which is a great paper It was the first to show that you don't need uh uh CCA secure cam. You it's enough to have uh something weaker and you get it. These are just reduction. What's written on top of the reduction is the loss. This is a reduction to an intermediate state that is done there as part of the games. we do games and we change the the the security and this is the reduction. So we they they had an intermediate game and one CCA uh MAC and with this it was enough to prove the security of uh TLS. As I said, these are just the the the ideas of what what is what the idea is and uh and uh and the further work showed that other reductions uh through intermediate states. Intermediate states are different restrictions on the uh on the game. when do you h when do you activate the adversary and when do you ask which oracle and things like this and you schedule it differently you get a different game as as anybody who has done thorough proof of protocol knows that this jumping between games is the way the way the way to prove it and uh the summary of our work which I put first before I run out of time which I thought so and so I I do it so what we what we show is that uh non-malleable CPA secure cams any reduction from these notions in one CCA in one CCA MAC and MAC star doesn't matter exact the exact differences the security to CPA security must incur a loss factor it's we always work about on possibilities but we don't show impossibility this is kind of impossibility why Why and it's important that this is a malleable CPA. This gives you the power to show that you need uh to pay some loss in the reduction and uh the loss actually you can show that it's omega q for random oracle model and more for for for quantum random oracle model and the possibility what we showed is that another technique that we can do when we suggest new protocols is actually changing the protocol. So what we do we introduce in the payload. So we want to improve the loss. So one way is to increase the security parameter increase everything. A second one is to do slight increase by adding a tag. And this tag is actually coming from the same data that is being encapsulated. And the role of this tag is to decrease the flexibility of the random oracle uh uh probing because it has to it has to match the tag once you this hash function. So, so, so this technique is changing the protocol but not necessarily increasing the the uh the uh security parameter but but but but partially changing the payload uh to get something. This is what what we get and I think we are about running out of time so I will do it very fast. >> Maybe skip the next 70. No, you should just get to the result. >> No, the issue is that whatever I say here, I will I will frustrate you because I say here we do this technique, but it's written here, but I'm not covering this and I do it five times. So, you can you can you can go home and and parse this into the the slides, but it will be online. So, this is this is what we've done. It's it's interesting. It's real world, but it's really a really really really an exercise in in in reduction proofs and simulations. And that's the beauty of cryptography. You can do both at the same time, especially when it's about postquantum. Thank you. [applause] >> Okay, I think we are almost already in the break. So perhaps if you have questions, Moody will take them during the break. [laughter] >> I'm here to I'm here to >> All right. Thank you very much. Thanks to all the speakers and uh let's let's break for coffee. [applause]