 Thank you for that introduction. This is joint work with my co-authors, Yevgeny Dotus, Thomas Brisenpart, and Joanne Woodich. So the subject of this talk is gonna be end-to-end encrypted messaging. These systems are gaining widespread adoption, and their architecture is pretty simple. A central service provider routes messages between a sender and a receiver. Crucially though, the service provider is blind in the sense that it can't actually read the messages or modify them, the messages that are being transmitted from sender to receiver. Perhaps because they're encrypted using authenticated encryption. There are tons of these end-to-end encrypted messaging systems now. For example, WhatsApp, Facebook Messenger, and Signal, and others. And most of them are believed to use good crypto and to be secure in standard threat models. Additionally, there's been some academic work recently analyzing the security of end-to-end encrypted messaging, including some we saw this morning. But there's one threat model that hasn't received a lot of attention in prior work which is abusive messaging. In, imagine an abusive, more malicious sender sends a message to a receiver that upsets them or threatens them or harasses them. The receiver might want to block this person, but further they might want to report this message to the central service provider to have the malicious sender banned from the platform. However, because of the end-to-end security guarantees of the messaging system, the central service provider can't actually verify that this message was sent. And if it takes the receiver's word for it, this opens up the door to a different kind of abuse wherein a malicious receiver accuses a sender of saying something that they didn't actually say. So in 2016, Facebook introduced a technique they called message-franking, which seeks to resolve this tension between end-to-end security and abuse reporting, which allows the receiver of a message to essentially generate a cryptographic proof of its contents in a report of an abusive message. Last year, my co-authors, Jawe Lu and Thomas Ristampard and I had a paper that formalized the primitive that's required for this kind of abuse reporting setting, which we called compactly committing authenticated encryption. And we proved that a simplified variant to Facebook's protocol is secure as a CCAE scheme in the way that we defined it. This talk has four main contributions. First, we show that while the security proofs of GLR still hold, if we consider Facebook's full protocol, Facebook's full protocol itself is not secure in the sense of being a CCAE. And we'll see a vulnerability which allows a malicious sender to send a message that can't be reported. Motivated by this flaw, we'll then turn to studying the efficiency of CCAE schemes and how to build the fastest possible CCAE schemes. Unfortunately, we'll show a negative result which connects a CCAE to block-cipher-based collision-resistant hashing and show that there can't exist a CCAE scheme that's as efficient as the most efficient authenticated encryption schemes. But using this connection to collision-resistant hashing a little more, we define a new symmetric key primitive, which we call equipment, and we define a construction of equipment based on collision-resistant hash functions. And this gives actually a single pass equipment construction. And finally, we'll show that equipment is kind of the core primitive underlying CCAE, basically meaning that you can take an equipment scheme and do a simple and generic transform that constructs a CCAE from it. And we'll see a transform that uses just a compression function. So first, we'll discuss the attack. And to understand the attack, we need to review Facebook's message-franking protocol. So in, oh, sorry about that. In Facebook's message-franking protocol, the sender begins by generating a random HMAC key and computing a kind of cryptographic commitment to the message it wants to send using HMAC. Then it takes the message and the HMAC key and encrypts them using a standard encrypted and HMAC authenticated encryption scheme. Then the sender sends the message to the receiver through Facebook and Facebook evaluates an HMAC using its own key on the CB value. And finally, the receiver receives the two-part message, decrypts the AE ciphertext to recover the opening and then verifies the commitment. To report an abusive message, the receiver sends the message as well as the HMAC opening, the HMAC value, and then the Facebook tag that Facebook generated for it. And using this, Facebook can essentially verify both its HMAC and also that the HMAC of the abusive message with this opening key is correct. And doing this essentially has verified that this message was actually received by the receiver. And so this is really just the message-franking protocol for chat messages. Attachments are like images and videos or handled a little bit differently for efficiency reasons. And so the question that we addressed last year here at Crypto is basically, is Facebook's approach secure? Is this scheme secure? And we showed last year that if we only consider the chat protocol itself with no attachments, that it is a CCAE scheme. But next we'll see that if we include the attachments in the protocol, there is a vulnerability that allows you to bypass the abuse reporting. So to understand exactly what the root of the flaw was, let's remember what the GLR defined as the security goals for message-franking. First, a message-franking scheme should be receiver binding, which essentially means that a receiver shouldn't be able to report, shouldn't be able to kind of create a fake abuse report by accusing the sender of sending a message that they didn't actually send. A message-franking scheme should also be sender binding, which essentially means that it's impossible for a sender to send a message that can't be reported as abusive. And finally, for messages that aren't reported as abusive, we should still be able to have the same kind of standard confidentiality and authenticity that authenticated encryption provides. So the attachment-franking protocol is somewhat similar and uses the basic message-franking protocol as a kind of chem. So the first thing the sender does is generates an attachment encryption key and an HMAC key and then computes a commitment using HMAC to the attachment encryption key. Then it encrypts the attachment encryption key along with the HMAC opening. Then it uses AESGCM to encrypt the attachment plaintext itself using this file encryption key. And remember for later that this is GCM because this is kind of where the problem is gonna start. So then it sends, the sender concludes by sending the two-part ciphertext which kind of wraps the attachment encryption key as well as the attachment ciphertext itself through Facebook. And Facebook does the same tagging with its own HMAC key and sends the encryption of the attachment key and the attachment plaintext, or the attachment ciphertext router itself through to the receiver. And the receiver decrypts the attachment key ciphertext to obtain the key and then decrypts the attachment and verifies the commitment as before. And if all the commitments verify then it displays the attachment. So if there's a transcript of messages, a transcript of attachments rather than a single attachment, this essentially just runs the protocol several times, once for each attachment. And to report an abusive, to report a conversation rather, including abusive attachments, the receiver opens all the attachment keys and all the other recent messages. So there's no kind of granular selection of messages to report. All recent messages are reported to Facebook and kind of all the keys are sent. So to generate the report that the human actually consumes to verify whether this is indeed an abusive message, Facebook will fetch the attachment ciphertexts from its internal storage. Crucially here, the receiver doesn't actually open to the attachment plaintext themselves. The attachment ciphertexts are stored inside of Facebook and Facebook will refetch them when a report is filed. So Facebook refetches the attachment ciphertexts, decrypts them, verifies all the commitments and then creates the report if everything checks. So our attack basically exploits the use of AESGCM combined with this kind of unique deduplication behavior that happens when the reports are generated. So the attack basically has four parts. The first is the malicious sender crafts an AESGCM ciphertext with the property that there are two valid decryption keys for the ciphertext. Under one key, the ciphertext decrypts to an innocuous image and under the other key, the attachment decrypts to an abusive image. Then the, I'm sorry about that. The sender sends the same ciphertext twice. Basically does this attachment franking protocol twice with the two different keys but the same attachment ciphertext. I'm sorry, my clicker is a little, yeah, okay. So when the receiver receives both of these attachments, it'll decrypt them twice and decrypt the same ciphertext under both keys. And it'll essentially see both the innocuous decryption and the abusive decryption. But when the attachment, when the conversation is reported as abusive, only the innocuous decryption will appear in the abuse report. So this violates the sender binding property of Facebook's attachment franking scheme. So let's just review what we've seen. So this attack basically has to craft an AESGCM ciphertext that decrypts correctly under two different keys. And you might be wondering, it seems kind of weird that this is possible because AESGCM is a secure authenticated encryption scheme. But recall that the standard authenticated encryption guarantees only actually hold when the attacker can't choose the keys. But in this attack, because the sender chooses these keys, it can basically craft the ciphertext. And the reason why GCM in particular is vulnerable to this attack is because it uses a kind of universal hash-based MAC which in particular isn't collision resistant under adversarily chosen keys. So the property that's actually being violated by our attack is the robustness of GCM, which basically robustness requires that you can't do exactly this, that you can't find a ciphertext that decrypts correctly under two different keys. And I'm happy to be corrected on this, but as far as I know, this is the first attack on robustness ever demonstrated against a real deployed system, which is kind of cool. Although there have been some prior academic works on a robust encryption, but I don't think any of them demonstrated an attack against a real system. So just to be concrete here, imagine that this left-hand image, rather, is the abusive decryption, and this right-hand image is the innocuous decryption. So this is the titular invisible salamander from the talk title. This actually doing, building these colliding images took a little bit of work, and it requires a little bit of messing with image file formats, and you can see the paper if you want more details on that. So we disclosed this vulnerability to Facebook, and they helped us understand the impact of the bug, and we'd like to in particular thank John Milken for answering a lot of questions that we had about the behavior of Facebook's systems, and they chose to change this basically by fixing the way that the attachment ciphertext are de-duplicated during an abuse report. Now they did this for a valid reason, which is that they didn't want to have to introduce some kind of cipher negotiation into their attachment-franking protocol, because they already had GCM deployed, but unfortunately this does leave the underlying flaw intact, which is that GCM is still used to encrypt attachments in Facebook's scheme, and they also awarded us a bug bounty for reporting it. So now that we understand the attack, we can kind of try to reflect on why it was possible in the first place. So Facebook uses a basically generic composition of a commitment and an authenticated encryption scheme, which we proved last year is secure as a CCAE scheme, but they didn't actually use this for attachments for a couple of reasons, but one major one is that it's a three-pass scheme, which especially on low-power mobile phones is much too slow to encrypt kind of like large image or video files. So this motivates the question that we'll treat for the rest of the talk, which essentially, can we actually build CCAE schemes that are faster than Facebook's? So when I say fast here, we should make our design target about one block safer call per block of message. And some existing AE schemes do achieve this, but none of them are actually secure as CCAE schemes. And it turns out that there's a fundamental reason for this, which is basically that CCAE implies a collision-resistant hash, kind of you can give a generic transformation that builds a collision-resistant hash function out of a CCAE scheme. So we basically proved that this is impossible in two steps. First, we gave this generic transformation that shows that CCAE implies collision-resistance. And then we leveraged prior work on lower bounding the efficiency of block cipher-based hash functions done by Black, Cochran, and Trimpton, and Rogaway, and Steinberger. And basically using these two things, we can combine them to rule out the existence of CCAE schemes that only make one block safer call per block of message. So this is unfortunate in some sense, but it also demonstrates an interesting connection to collision-resistant hashing, which is actually the approach we're gonna take in building a faster CCAE scheme. And we're gonna do this in two steps. First, we're gonna define a new primitive called encryptment, which is essentially a one-time CCAE scheme. And we're gonna do this because CCAE is a little bit complicated to reason about, and it has a lot of bells and whistles. So we're gonna just kind of isolate the hard parts of building it into this new primitive called encryptment. And then we're going to show how to basically transform encryptment in a very fast and simple transform to a full CCAE scheme. So we'll demonstrate encryptment, and then we'll demonstrate our construction of encryptment, which we call the hash function chaining scheme. And then we'll show one particular transform from encryptment to CCAE using a compression function. And together this will imply this will imply basically a CCAE scheme that can be evaluated in only one call to shot to 56, for example. So this is not one block cipher call per block of message, but this is still one pass, and we expect to be pretty fast in practice. So encryptment is basically kind of one-time CCAE scheme, and it's basically just three algorithms. We omit key generation and associated data, but these can be added back without too much complexity in the presentation. So the first algorithm is EC, which takes a key and a message and produces a two-part cipher text. The second part of the cipher text, CB, should be short, like for example, about 256 bits. So EC encrypts M, but also commits to it. And DO takes a key and a two-part cipher text and outputs either a message or the bot symbol. So DO basically decrypts the two-part cipher text and opens to the message M. The final algorithm is EVAR, which takes a message, a key, and the second part of a two-part cipher text, which we'll sometimes call the binding tag and outputs a zero or a one. And this essentially just verifies the commitment, verifies this binding tag as a commitment to the message M. So encryptment should have four basic security properties, which we'll describe at a high level. It should have confidentiality in the sense that it should be one time real or random secure. This is kind of the standard AE confidentiality goal restricted to a single query. It should have a property we call second cipher text unforgeability, which basically says that cipher text can't be forged, but in a way that is a little bit specific to the construction or to this primitive. And so I won't actually go into detail on exactly how the forgery should be ruled out, but you can see the paper for more details. And finally it should have these same two security goals as before. Basically it should be receiver binding, which in the sense that it shouldn't be possible to come up with pairs of keys and messages that verify that for the same binding tag. And it should be sender binding in that a cipher text that decrypts correctly also verifies. So next we'll describe our HFC scheme, which constructs an equipment from a compression function. And so to do this we'll first briefly review Merkel Damgarde style hash functions. So a Merkel Damgarde style hash function basically takes a compression function and iterates it in a particular way to obtain a kind of arbitrary hash function on arbitrary length inputs with some suitable padding. And there's this IV here at the beginning, and this is just a constant string that's just kind of fixed in the parameters. So HFC is gonna look a lot like a Merkel Damgarde hash function with a few principle modifications. The first is that rather than just hashing the message, we're gonna prepend a block of zeros and then Xor the key into every block of message. Now this isn't gonna result in a compression function that's collision resistant in the kind of key message pairs, but we're gonna be able to recover collision resistance kind of in the iteration, so to speak. The next thing is rather than kind of throwing away the internal chaining variables in the Merkel Damgarde iteration, we're gonna kind of extract them and use them as pads in a counter mode, kind of like a streamed cipher encryption construction to encrypt the message and obtain the kind of cipher text blocks. And finally we're gonna use the final chaining variable, which is the kind of output of the Merkel Damgarde iteration as this binding tag C sub B. So the algorithm to DO and EVARE work more or less the way you would expect. Basically you just rerun the iteration and recover the message or verify the tag. And so one cool thing about this construction is that it only requires one pass of the hash function. All three of these algorithms just kind of run Merkel Damgarde iteration and then you have a cipher text or a verification or whatever. So this construction is similar to two previous AE constructions. The first is the OMD construction of Coliani et al. And the second is the duplex sponge AE construction by Bertoni et al. So finally we'll see that this HFC construction and indeed any encryptment construction can be kind of generically transformed into a CCAE scheme using a fast transform. And so the way we're gonna do this is just using an additional two compression function calls as follows. So we're gonna derive a long-term key which is the kind of long-term AE key. And then we're gonna use it, we're gonna key two compression function calls with it, one at the beginning and one at the end. The first thing, the first compression function call with this long-term key is gonna be evaluated on this long-term key and some like an IV, some randomness that we derive. And this is actually gonna be used to derive the one-time encryptment key that's gonna be used for kind of a single encryptment call. And the last thing we're gonna do at the end we're gonna evaluate the compression function again with the binding tag as input and the kind of the long-term key. And this is gonna let us derive a MAC tag for the ciphertext. And so the ciphertext here is gonna be the concatenation of the randomness here, the ciphertext blocks, CB and the tag T. So in the paper, we prove that if EC is a secure encryptment scheme and again the transform I showed it with HFC but it is fully generic for any encryptment scheme. And so if that encryptment scheme is secure and the compression function is a PRF, then this construction results in a CCAE scheme. So we just saw that encryptment can be used to build CCAE pretty quickly and easily but encryptment is a primitive that might also have independent applications. In particular, we show in the paper how you can use encryptment to construct single pass constructions of things like concealments, remotely keyed authenticated encryption, robust encryption. Because I don't really have time to talk about that, you should see the paper for details. So in conclusion, this talk showed four things. The first was an attack against Facebook's message ranking scheme which allowed malicious senders to bypass the abuse reporting functionality. The second was a lower bound on the efficiency of CCAE ruling out very fast CCAE schemes. The third was a new primitive which we call encryptment and a construction of encryptment which we call hash function chaining. The fourth is a way to transform any encryptment scheme into a CCAE scheme in a kind of generic and efficient transformation. So thanks for listening. Are there any questions?