 Thanks for that introduction Stefano. Hi everybody. Good morning. Hope everybody is awake. I haven't had coffee yet but I hope you have. So I'm going to be telling you today about centralized like end-to-end encrypted messengers. Applications like Signal and WhatsApp are gaining widespread adoption today and their architecture is one of a central service provider that basically routes messages from senders to receivers. Crucially, the service provider is blind to the messages being sent and can't read the messages because they're end-to-end encrypted. These applications are, most of them use pretty good crypto and are assumed to be secure in standard threat models for network level adversaries. But there is one threat in particular that they don't model in their threat models, which is abusive or threatening messages. Imagine a sender sends an abusive threatening or harassing message to a receiver through the end-to-end encrypted messaging service. The receiver of this message might like to block the sender from sending them additional messages, but further than that they might want to report the sender to the central service provider to prevent them from sending additional hurtful or abusive messages. The problem here is that because of encryption, the service provider can't actually be sure that the message that the receiver is reporting was sent. And naive approaches like simply having a receiver take a screenshot of the message fail for their own reason, which is that they can themselves be abused by malicious receivers. A malicious receiver would receive an innocuous message from an honest sender and then try to report it to the central service provider as abusive. Because of this, we would like to motivate the need for verifiable abuse reporting, which is some kind of cryptographic verification of messages that are passing through the service. This year at Real World Crypto, Facebook unveiled a scheme that they call Message Franking for doing cryptographic verifiable abuse reporting and end-to-end encrypted messaging. It works basically as follows. First, the sender computes an HMAC with a randomly generated key of the message and sends an AE ciphertext of the message and the key along with the tag through Facebook to the receiver. Additionally, Facebook stores the tag but not the ciphertext. The receiver decrypts it and if the receiver wants to report the message, it can send the message and the random key to Facebook. Facebook then verifies the HMAC. Though they don't use this terminology in their official documentation on this feature, it's clear that the security property that they're using of the HMAC is that it's actually a commitment to the underlying message being sent. When the sender sends the message, it commits to the message and when the receiver wants to report a message, it opens the commitment to Facebook. This kind of composition of authenticated encryption and a commitment is novel and has not really been seen before in the literature. So this composition is a new kind of cryptographic primitive whose goals are actually distinct from standard authenticated encryption or commitments. Because Facebook didn't really do a comprehensive formal analysis of the security or the goals of this primitive, we're left with a lot of questions about it. For example, what even is this primitive? What are its functionality or security goals and how can we formalize those goals? Once we have security definitions for this primitive, can we prove that Facebook's scheme meets the notions of security that we developed? And can we develop maybe faster or better constructions or might there be other modes of authenticated encryption that already instantiate this primitive? So in this talk, we provide a constructive answer to these questions by formalizing a new primitive called compactly committing authenticated encryption. We kind of motivate its use in the cryptographically verifiable abuse reporting setting. Once we formalize this primitive and give definitions, we're able to prove under a mild but non-standard assumption that Facebook's scheme actually instantiates compactly committing authenticated encryption, which I'll sometimes refer to as CCAEAD. After that, we turn to other kinds of schemes other than the generic composition approach of Facebook. First, we analyze some legacy AE schemes and find that some of them, but not all of them, already instantiate CCAEAD. And finally, we'll present a new construction that's kind of custom made for the verifiable abuse reporting setting that's faster and more efficient than existing constructions. So we all know the syntax of regular encryption, but we kind of need to know how to view regular encryption as a commitment. Now, the view of previous work like Gertner and Hertzberg from 2003 was to view the ciphertext as the commitment to the underlying message and to view the encryption key as the opening and to verify by decrypting the ciphertext. The security guarantees of a commitment are hiding and binding. Now, the hiding guarantees are taken care of by the security guarantees of the encryption scheme when you view an encryption scheme as a commitment in this way. So to be a commitment, the encryption scheme also has to be binding, which in this case means that it's hard to find two message key pairs and a single ciphertext so that the ciphertext verifies under both pairs. So our formalization of CCAEAD is similar with a few key differences. One is the addition of associated data, which in the context of authenticated encryption is some non-secret context or metadata that might need integrity guarantees, but for protocol reasons might not be secret. An example in the messaging setting is like the recipient ID of a message, which you might want to bind to the ciphertext to avoid kind of like context manipulation attacks. The second difference in our formalization is that the ciphertext actually have two parts and the second part is what we call the committing portion of the ciphertext. And the compactness requirement says that this portion is linear in the size of the security parameter. So concretely basically that means that this committing portion should be like maybe a few block cipher outputs or like the output of a hash function or something like that. The third difference is that we have a separate opening which will denote as KF for opening the commitment and this can be distinct from the encryption key which we'll see why this is important a little bit later. So the security goals of a CCAEAD scheme, there are three basic properties. To be a multi-opening secure scheme which I'll explain what that is in a few slides, you basically need to be receiver binding and sender binding. And these two properties refer to the ability to abuse or not abuse the ciphertext to report or prevent reporting of different kinds of abusive messages in the verifiable abuse reporting setting. The final property you need is multi-opening real or random and multi-opening CTECH security. And these are kind of the liftings of traditional authenticated encryption security notions to the setting, the compact, the committing authenticated encryption setting. And I'll explain what these are in the subsequent slides. So now that we know what a CCAEAD scheme is and what security we want, we can use Facebook's scheme as a kind of running concrete example to examine our formalism. Facebook's scheme works roughly as I described it before. They generate an HMAC and they HMAC the message and the random key that they generated with the key itself. You might be thinking this is a typo, it's not a typo. I'll go into in a few slides the consequence of this. So they use this to generate the committing portion of the ciphertext and they use a regular AE scheme and CRIP then MAC composition to generate the other portion of the ciphertext. And then they send the C1 and C2 to the receiver through Facebook and Facebook stores, Facebook stores C2 but not C1. And I don't think, I actually don't think I said this before but if any of you are already be see this year you're probably wondering why I'm describing it like this. This version of the protocol is a simplification that simplifies the protocol in a way that's not really consequential for the talk but it is a little bit different than this in practice. So when the receiver receives a message it decrypts the C1 to receive the message and the HMAC opening and then checks the HMAC and then if both things pass it just outputs the message in the opening. And to report again it just kind of verifies the HMAC. So in the context of Facebook scheme receiver binding is kind of the simplest of the three properties that we have which is just a lifting of the binding notion from commitments. In this abuse reporting setting what it means is that a malicious receiver can't try to open a message to Facebook as something other than the message that it actually received from the sender. So we see that even though the sender intended to send M the receiver is going to try to open it to a different message M prime. And so receiver binding basically says that you can't take a CCAED Cypertex and open it to a message other than the one that it contains. The second property is a little bit more subtle and it's not a traditional binding property. But basically sender binding ensures that a malicious sender can't craft a Cypertex that prevents a receiver from reporting it as abusive or more formally from opening the commitment. So to illustrate what sender binding is we can kind of just get rid of this line of the Facebook protocol and we'll walk through it again and we'll see what happens. So the malicious sender kind of crafts the Cypertex and then sends a different like a junk committing portion that's not actually the one generated by encryption. And when the receiver gets this and it tries to report it as abusive Facebook actually will reject this report because the opening message and opening that it sent is not correct relative to the stored portion of the committing portion of the Cypertex that it has. So an easy theorem here is that basically if you rerun verify during decryption you can guarantee that this property holds. So the third security property that we need is a multi-opening real or random and multi-opening C text and I'll explain multi-opening real or random and kind of let you look defer to the paper for the multi-opening C text. So basically this is a lifting of the as I said before it's a lifting of real or random security to the to the setting where an adversary can get openings of Cypertex. So basically what we do is we take the standard real or random oracles from authenticated encryption and we add these other encryption and decryption oracles. So basically these oracles return Cypertex that the adversary can't request openings for but the other encryption oracle returns Cypertex that it can open via decryption. And we basically require that real or random security holds for the Cypertex that come out of the challenge encryption oracle. And so if you are familiar with C text you can probably see how to adapt this to a multi-opening setting you basically just have two decryption oracles. And I'll just define it now but it won't be important until a little bit later so single opening security is a kind of basically a version of this definition where you don't have openable Cypertex. So this is intuitively this is the security that you achieve when the opening of your CCAAD scheme is the key itself. So now that we've seen all of our security properties and defined CCAAD we can come to the kind of the first major question of the talk which is whether Facebook scheme actually is a multi-opening CCAAD scheme. So I put the security properties up here so you can just be reminded of them in a nice checklist. So we know that from the theorem I said before that Facebook actually is verifying the commitment during decryption so that means that they achieve sender binding pretty easily. But unfortunately we can't really conclude the rest of the theorem as easily because we have these two subtleties that we need to take care of. The first subtlety is that the committing portion of the Cypher text and the AE Cypher text aren't really bound together in any kind of cryptographic way. And this could potentially lead to Cypher text integrity attacks which would invalidate kind of the C text of the CCAAD scheme. And the second subtlety is that they do this frankly kind of bizarre thing where they put the key of the HMAC in the body of the HMAC. So this means that as far as I know standard model proofs for like the security properties of HMAC don't really hold in the key dependent message setting. So we can basically conclude multi-opening real or random and multi-opening C text by using the fact that the fact that they're using HMAC as a commitment means that given a message and an opening the value of the HMAC commitment is unique. This is kind of like a weak non-malleability property that is sufficient to let us conclude a C text. And we have to make an additional assumption about the key dependent message behavior of HMAC when used in this way. But given this assumption we can kind of conclude receiver binding unless we can conclude the full theorem. Which is that Facebook scheme actually is a multi-opening CCAAD scheme. So now we can take a breath. So that was Facebook scheme. Facebook scheme is very nice but it is kind of a generic composition to kind of like commit then encrypt construction. And we can ask ourselves like whether it was actually necessary for Facebook to do a generic composition at all. It might be the case that existing AEAD schemes already instantiate this primitive when instantiate CCAAD rather when kind of like suitably defined. So before we look at AEAD schemes we have to kind of figure out again how to view an AEAD scheme as a commitment. So you need to do basically three things. You need to identify the compact committing portion of the ciphertext and define the opening. And you can just let Verify recompute the kind of the committing portion of the ciphertext to check the commitment. And here as I said as I defined single opening security before you can let the opening of the CCAAD scheme be the key itself. This is fine if you're surrounding protocol guarantees one-time use keys. So an example of this is the signal protocol which because it uses ratcheting to kind of update the shared secret when every message is sent ensures that a symmetric key will only be used once. And if this is the case opening the opening the ciphertext to the key itself doesn't reveal any doesn't break confidentiality of the other messages. So let's just take like a very simple legacy AEAD scheme that everybody knows and loves which is just encrypt then Mac composition with counter and HMAC. So in this case the committing portion of the ciphertext will be the HMAC tag C2 and the opening will be encryption and I think an authentication key separately. So we can ask when defined in this way this is counter then HMAC CCAAD scheme and the answer unfortunately is no because a malicious receiver can specify the same authentication key in any other encryption key. And because the committing portion will be the same but the ciphertext will decrypt differently it's broken receiver binding trivially. So we can fix this actually pretty easily all we need to do is define the opening to be a single parent key which we then derive encryption and authentication keys from in encrypt, decrypt and verify. And if the key derivation function we use is collision resistant then everything kind of works out. So here's a slightly more general version of what I just said encrypt then Mac composition is a single opening secure CCAAD scheme if the key derivation function and the Mac are both collision resistant. One kind of like interesting and surprising to us consequence of this result is that because Facebook secret conversations which is their end to end encrypted message protocol because it used signal which used ETM with ratcheting which is to say they use, they update the shared secret to ensure one time use keys. And more than that they actually use a collision resistant key derivation function to derive encryption and authentication keys for every message sent. So an implication of this was that signals record layer which is what Facebook was using was already a compactly committing authenticated encryption scheme and kind of what Facebook did was not really adding any functionality when you view the record layer in a suitable way. Just a table of some of the other schemes for yeah for to save time we'll just do this in a table encrypt then Mac we already discussed. Mac then CBC is a CCAAD scheme even if you let the adversary specify encryption and authentication keys as the opening separately. And the committing portion here is taken to be like the last four blocks of the cipher text plus the IV. So one implication of this is that for some TLS cipher suites pre one point pre one point three the record layer of TLS is a CCAAD scheme already. Although I should caution that here because TLS doesn't actually guarantee one time use keys via like ratcheting the single opening security does become a problem because releasing the key to open a cipher text will kind of like break the confidentiality of other of other messages. In the paper we also prove in code then in cipher in the when you model the underlying permutation as an idle cipher instantiates a CCAAD scheme and you can just view some constant length substring of the cipher text is the committing portion here. The final thing we did in the paper on legacy AAD schemes was kind of looking at these more efficient block cipher modes that use Carter Wegman Macs. And in the paper we show a pretty simple attack that breaks the receiver binding of any of any mode that uses a Carter Wegman Mac as its as its authenticator. So this is like like GCM and a previous talk talked about like GCM and Chacha 20 Paula 1305. And so the implication is that because their Macs are not actually collision resistant under adversarily chosen keys these aren't really suitable to be used as CCAAD schemes. So the final thing I'll talk about here and I'll try to go a little bit fast is the final thing which is a kind of a custom built construction which we call committing encrypted PRF or CEP for short. This is a non-space authenticated encryption scheme which if you're not familiar just basically means encrypt and decrypt are deterministic and they take nonsense as input. So CEP uses a non-space PRG which will with the notice G here a regular PRF and a collision resistant PRF encryption. The first thing we do is derive size of M plus two bits of two times the block the block cipher size pseudo random pads. And the biggest one just gets used an X or with the message to generate a counter mode cipher text. And the other two get used as one time keys for these PRFs. So the first one the collision resistant PRF takes as input this one time key P zero and the header and the message concatenated together to generate the committing portion of the cipher text. And to kind of guarantee like multi opening C text we actually use the other PRF with the one time use key P one to generate the authentication tag of the of the scheme. And so this scheme has a lot of advantages over the other schemes that we've seen in this talk. If the first thing is it's not space so it's suitable for more settings especially where there might not be randomness available for encryption and decryption. There it has shorter cipher text because it doesn't have an explicit opening and but it still achieves multi opening security which is a really interesting property of the scheme. And it also requires one fewer cryptographic pass over the message and header than the than the generic composition approaches we saw before. So just in summary in this talk we introduced a new cryptographic primitive which we call compactly committing authenticated encryption. And we kind of motivated its usefulness in verifiable abuse reporting settings in encrypted messengers. We analyzed the CCAD security of Facebook's generic composition scheme as well as several legacy schemes. And finally we presented a non space CCAD scheme called CEP which is more efficient than legacy schemes or generic composition. Thanks for listening.