 I welcome everyone to this presentation of the paper Beyond Security and Efficiency on Demand Ratcheting with Security Awareness. My name is Andrea Coforio and this is a joint work with Betil Durak from Boss Research and Serge Wodne from the LASAG Laboratory at EPFL. Although messaging applications permeate our everyday life basically everywhere around the globe, the cryptographic sub-discipline of secure messaging has only been gaining traction over the past few years with the emergence of several ratcheting protocols with varying security properties. The overall goal, however, for all of these constructions remains identical. How to secure an asynchronous challenge between two participants that arbitrarily switch their rules in the presence of state exposures? In this context, asynchronous means that both users do not need to be online in order to communicate, hence descending and reception of messages may be randomly interleaved. Nevertheless, this does not mean that the order of messages from a user can be mixed or that messages can be dropped. We captured the security of a messaging protocol through two notions. The first one is forward security. We want to prevent the decryption of past messages by deleting old states through one-way functions. And secondly, post-compromise security. We want to prevent the decryption of future communication by introducing some form of randomness into the user states. This is commonly called ratcheting. OTR, short for off the record, was the earliest ratcheting protocol that found real-world application. It is now superseded by the omnipresent signal construction released in 2013 and among others found in WhatsApp. The security of signal was only formally analyzed in 2017. The first ratcheting protocol that found its way on the academic stage was a construction by Corn Gordon et al that however required synchronized rules. A year later, Belarie et al proposed a unidirectional protocol with no forward security. At Crypto 2018, Petering and Rösler came forward with a protocol with optimal security in the sense that no better model is known. It is proven in the random oracle model but does not consider leakage of random coins. The construction is instantiated with a hierarchical identity-based encryption scheme that requires bilinear pairings and this does very inefficient. At the same conference, Jagger and Stepanov proposed a similar optimal protocol in the random oracle model also relying on HIDEs with random coin leakage before usage. In 2019, Durak and Vodane put forward a highly efficient ratcheting protocol with slightly lower security in the standard model that only requires ordinary cryptosystems. It is based on a publicly cryptosystem, a symmetric key system, a digital signature scheme and a hash function. They further introduced the notion of R-recover security, meaning that a participant should not be able anymore to receive genuine messages after having received the forgery, hence detecting the intrusion. Additionally, the authors proved that post-compromise security implies publicly cryptography, hence this security level cannot be achieved by symmetric primitives only. In the same year, Yoast, Maurer and Malarczyk proposed another protocol in the random oracle model with a security level somewhere between DV and PR with coin leakage resilience after their usage. As DV, it is only based on ordinary primitives but not as efficient as we will see later. Alvent, Corelli and Dodes introduced a reinterpretation of the single protocol in the standard model featuring immediate decryption, the ability to decrypt out-of-order messages. However, their construction only relies on symmetric crypto during periods when the direction of communication does not change, hence there is no post-compromise security for those messages. ACDPK is a tweak that incorporates public key cryptography into those unidirectional periods making it post-compromise secure. And finally, in 2020, Jan and Wodehne designed the so far most efficient protocol called encrypted and hash that only relies on symmetric primitives and thus offers no post-compromise security. Having reviewed state-of-the-art of secure messaging protocols, what is the crux? So in all proposed constructions, the users are oblivious to the actual protocols. Active attacks may occur undetected as communication progresses. Additionally, there is no way to modulate the security level. In some scenarios and applications, better performance is warranted at the cost of reduced security guarantees. The known protocols are either strongly secure but impractical or the other way around. In this paper, we propose the following contributions. First, a formal definition of the security awareness notion in which users are able to detect active attacks by noticing a communication breakdown, meaning the inability to further send and receive messages. Consequently, every acknowledged message is deemed secure. Secondly, users can deduce from incoming messages which of the outgoing ones were actually delivered. We call this concept an acknowledgement extractor. Additionally, given a transcript of sent and received messages alongside potential state exposures, we want to pinpoint which messages remain private. We call this a cleanest extractor. In practical terms, we give a generic toolbox that allows the composition of any two protocols with different security levels. When a strongly secured protocol is combined with a weaker but more efficient protocol, we obtain the notion of ratchet on demand. On a similar note, a hybrid system of two identical protocols allows to re-instantiate broken communication. Finally, we give a comprehensive implementation benchmark of all discussed scenes. This includes the Prithering and Rösler, Jäger and Stepanov's protocol, the construction by Durak and Vodane, the protocol by Joost, Maurer and Malarczyk, both Albin, Korty and Doris constructions, and the recent encrypt and hash protocol by Jan and Vodane. Note that some of those constructions are technically key agreement protocols, however from a security standpoint we consider them equivalent. Before jumping into the meat of the paper, we need to revisit some general concepts. An asynchronous-ratcheted communication protocol with associated data is a five-tuple of a PPT algorithms. A setup algorithm that creates the public parameters according to some security parameter, a key generation algorithm that creates a public secret key pair, an initialization algorithm that creates the initial state of a user, a center team that produces a ciphertext and an updated state, and a reception procedure that, given a ciphertext produces the plaintext, an updated state and a flag indicating whether the decryption succeeded. In terms of correctness, we demand that any untempered sequence of wretched send and wretched receive calls be permitted as long as no messages are dropped or a sequence of messages from a user are received in a different order. In the form of a correctness game, this means that we have two oracles, a sent and received one that populate a sent and received list for each user. Then for any schedule of sent and receive calls, we demand that the received list of each user is prefixed of the sent list of its counterpart. More formally, we say that a user P is in a matching status at time t if at any moment of the game before time t, the received list of the user P is a prefix of the sent list of the user P bar, and at any moment of the game before the time t bar for the user P bar, we demand that his received list is a prefix of the sent list of the user P. In order to simplify the analysis of various security properties, we would like to talk away trivial attacks, for example, trivial forgeries after a state exposure, behind a cleanest predicate cclean, such that the games for the other security notions become easier to pause. Specifically, we are interested in forge security, resistance against forgeries, or recover security, detecting a forgery through the inability to receive further genuine messages, predict security, the inability for an adversary to guess the ciphertext, and most importantly in CTA security for confidentiality. Making such a predicate simplifies our game significantly. For example, in the forge game, the adversary has access to a sent and received oracle, a state exposure oracle, and a plaintext exposure oracle, and his goal is to make a message accept by some user according to some cleanest predicate. In the R-recovered game, the goal of the adversary is to create divergence in the sent and received list of the users that goes unnoticed. In this NCCA game, there is an additional oracle called challenge where either a random plaintext is encrypted or the given one. As already indicated, R-recovered security averts that a user P continues to accept genuine ciphertext from its counterpart after having received a forgery. However, in this scenario, the user P-bar is still able to receive messages from P. However, we demand a complete breakdown of communication. Communication breakdown should reveal any forgery and receiving genuine messages should indicate that no forteries took place. We capture this with the S-recovered security notion whose game or in whose game the adversary attempts to make a user accept the message from another user that has received a forgery. The combination of R-recovered, S-recovered and predicted security yields the following very useful results. If an R-cat is R-recovered, S-recovered and predicted secure, whenever P receives a genuine message from P-bar, P is in a matching status except with negligible probability. In addition to R-recovered security, we want to give a user the power to verify whether a message has been accepted by its counterpart and check whether some cleanness predicate has been violated. For this, let T of P be the chronological partial transcript of the up-to-time T of send, receive, exposure and challenge calls involving the user P alongside the ciphertext pairs corresponding to each send and receive invocation. Furthermore, let T-ratch of P be the transcript that only contains the send, receive and challenge call. In addition to R-recovered security, we want to give a user the power to verify whether a message has been accepted by its counterpart and check whether some cleanness predicate has been violated. For this, let T of P be the chronological partial transcript of the up-to-time T of send, receive, exposure and challenge calls involving P alongside message pairs corresponding to each send and receive invocation. Let T-ratch of P be the transcript that only contains send, receive and challenge calls. Given such a transcript, it is rather simple to define an acknowledgment extractor. So given a transcript T of P and a message ADCT successfully received by P at time T that are sent by P-bar at time T-bar, let AD-prime and CD-prime be the last message received by P-bar before time T-bar. An acknowledgment extractor is an efficient function F such that F of T-ratch of P returns AD-prime and CD-prime for any time T when P is in a matching status. Furthermore, we can also define a cleanness extractor. So let T-P and T-P-bar be two partial transcripts. There is a cleanness extractor for C-clean. If there is an efficient function G such that G given those two transcripts has the following properties. There is one challenge in T-P and either P received AD-test and CD-test or there is a roundtrip P to P-bar to P starting with P sending AD-test and CT-test. Then G given those two transcripts tells us whether the cleanness predicate has been violated. The reason that we need such a roundtrip for an outgoing challenge message is that there is no way to know whether the challenge message has actually been correctly received by P-bar. In the following, we give a generic construction that elevates any secure R-card 0 into a security-aware R-card 1 denoted by chain of R-card 0. Intuitively, a blockchain-like structure that contains a hash chain of sent ciphertexts that is sent alongside each message suffices to associate each message to the digest of the chain. For this, we define some auxiliary variables. H sent is the hash of all sent ciphertexts computed by the sender and sent along each message and updated with a hashing key HK. H received is the hash of all received ciphertexts, also updated with the hashing key upon every reception. It should be easy to see that H sent and H received are enough to ensure our recover security since those two variables only need to be compared upon every message reception. However, more work is required for S recover security. We define more auxiliary variables. H received is a counter of received messages that need to be reported in the next sent call. The latest H received is attached to the message, to acknowledge received messages, and then resets to 0. And then A sent is a list of hashes of sent ciphertexts that are waiting for an acknowledgement. With those two variables, any impersonation of a participant leads to an immediate cut in communication as the intrusion is detected. So how does such a protocol actually look like in practice? So we have a set-up routine that generates the public parameters and the hashing key and an initialization routine that initializes the states of the two users alongside the auxiliary variables. And then in the send function, we attach the H sent to each message as well as the H received and update the H sent variable with the hash function. And then in the receive call, we compare the received H sent to the H received and decrypt the message. And if it succeeds, we update our H received variable with the hashing function and increment the H received counter. We can now show that if H is a collision-resistant hash function, our chain RCATs construction is recover secure for both R recover and S recover security. It's also easy to see that our construction has an acknowledgement extractor. Furthermore, we can also show that our chain RCAT scheme has a clean extractor for a group of cleanest predicates. For the full definition of those predicates, I refer the listener to the full paper. And finally, we can show that if RCAT zero is predict secure, then our chain RCAT construction is also predict secure. We move on to the notion of on-demand ratcheting, where we combine a strongly secure protocol using public key cryptography with a weaker protocol that is only based on symmetric primitives that is more efficient. The weaker protocol is used for frequent exchanges, where no post-compromise security is guaranteed. And the strong protocol is engaged periodically. For example, ratcheting could be administered at the application level or even by the users themselves. For this, we denote by RCAT main the strong protocol and by RCAT sub the weak protocol. The composition of RCAT main and RCAT sub we call a hybrid. And we instigate a ratcheting execution with a flag that is sent alongside the associated data. Our protocol proceeds in so-called epochs, a concept that first appeared in the Patrick and Rosier protocol. Intuitively, an epoch designates a batch of sent and received messages until the direction of communication changes. For this, each user stores two counters, eSent and eReceive, indicating the epoch of the last sent and received message. An epoch counter is also sent alongside each message. So here an epoch counter e of m is equal to eSent if eReceived is smaller than eSent or equal to eReceive plus one otherwise. How does this look like in an example? So here in this example, user A starts off with a batch of messages that are sent to B and B responds with an incremented message epoch. A responds again, but this time the message of A crosses an earlier message of B. So in the following response to this message by A, the epoch counter is not incremented. In addition to the epoch counters, each user keeps count of the number of messages within one epoch. So from a high level perspective, each ARCAT main call creates a new ARCAT sub send and receive state. The sender stores the send state in an array and transmits the receive state in the ciphertext. So how does our protocol actually look like? The setup and initialization routines are very similar to the security or construction from before. In the initialization function, we create an ARCAT main state for each user and initialize their epoch counters and arrays. In the send routine, we first check if you wanna actually instigate a ratcheting call. If so, we first create a new ARCAT sub send and receive state. We keep the send state, but pack the receive state into the ciphertext and encrypt it with ARCAT main. Otherwise, if you don't want to ratchet, we simply use ARCAT sub for the ciphertext creation. Note that the very first message of a communication is necessarily a ratcheting call since no ARCAT sub states are created in the initialization function. Then the corresponding receive function, we first check if an ratcheting call has been demanded. If so, we use ARCAT main for the decryption. Otherwise, we simply use ARCAT sub. We can show that we can derive the security of our hybrid construction directly from the security properties of the sub-protocols, mainly ARCAT main and ARCAT sub. Furthermore, if the two protocols are actually identical, so if ARCAT main is equal to ARCAT sub, then we can use ARCAT main to generate a new ARCAT sub session whenever we want. So making it possible to restore a broken communication in ARCAT sub. For the last part of this presentation, we move on to the benchmarks. So we implemented the discussed protocols on a comparable, on a machine comparable to a high-end smartphone in three different scenarios. First looked at alternating traffic. So A and the users A and B take alternating turns in sending and receiving messages. Then we looked at unidirectional traffic. So first user A sends N messages that are received by user B and then user B proceeds to send his share of N messages. And finally, we looked at something similar called a deferred and unidirectional traffic which starts off by A sending N messages. But before B receives those messages, he sends his share of messages. What can we conclude from those three messages or traffic scenarios? First, we look at alternating traffic. So it is dominated, of course, by the ETH construction by Jan and Baudenay which doesn't use any public key cryptography. We also see that the two schemes which are relying on HIVEs are significantly less efficient than the other schemes relying on symmetric and public key cryptography. A similar thing is true for unidirectional traffic. However, if you look at deferred unidirectional traffic, we see that the JMM protocol, so the protocol by ULST, MAUDER and MULARCHIC actually has a hidden complexity when it comes to this type of traffic. And with this slide, I conclude my presentation.