Bidirectional Asynchronous Ratcheted Key Agreement with Linear Complexity

Abstract

Following up mass surveillance and privacy issues, modern secure communication protocols now seek more security such as forward secrecy and post-compromise security. They cannot rely on an assumption such as synchronization, predictable sender/receiver roles, or online availability. Ratcheting was introduced to address forward secrecy and postcompromise security in real-world messaging protocols. At CSF 2016 and CRYPTO 2017, ratcheting was studied either without zero round-trip time (0-RTT) or without bidirectional communication. At CRYPTO 2018, ratcheting with bidirectional communication was done using heavy key-update primitives. At EUROCRYPT 2019, another protocol was proposed. All those protocols use random oracles. Furthermore, exchanging n messages has complexity O(n 2 ) in general. In this work, we define the bidirectional asynchronous ratcheted key agreement (BARK) with formal security notions. We provide a simple security model and design a secure BARK scheme using no key-update primitives, no random oracle, and with O(n) complexity. It is based on a public-key cryptosystem, a signature scheme, one-time symmetric encryption, and a collision-resistant hash function family. We further show that BARK (even unidirectional) implies public-key cryptography, meaning that it cannot solely rely on symmetric cryptography.

Determining the Core Primitive for Optimally Secure Ratcheting

“…Subsequent to these strongly secure ratcheting notions, multiple weaker formal definitions for ratcheting were proposed that consider special properties such as strong explicit authentication [8], out of order receipt of ciphertexts [1], or primarily target on allowing efficient instantiations [12,4]. Table 1: Differences in security notions of ratcheting regarding (a) uni-(→), sesqui-( →), and bidirectional (↔) interaction between A and B, (b) when the adversary is allowed to expose A's and B's state (or when this is unnecessarily restricted), (c) the adversary's ability to reveal or manipulate algorithm invocations' random coins, and (d) how soon and how complete recovery from these two attacks into a secure state is required of secure constructions (or if unnecessary delays or exceptions for recovery are permitted).…”

“…While these works are syntactically similar, we shortly sketch their different relaxations regarding security -making their security notions sub-optimal. Durak and Vaudenay [8] and Caforio et al [4] forbid the adversary to perform impersonation attacks against the communication between A and B during the establishment of a secure key. Thus, they do not require recovery from state exposures -which are a part of impersonation attacks -in all possible cases, which we denote as "partial recovery" (see Table 1).…”

“…Interestingly, both mentioned unidirectional RKE instantiations that were defined to depict optimal security [3,17] as well as bidirectional real-world examples such as the Signal protocol (analyzed in [6]), and instantiations of the above named relaxed security notions [8,12,1,4] only rely on standard PKC (cf. rows in Table 1 with gray cells).…”

“…We describe attacks against each of both constructions in our security definition in the full version [2]. Similarly, the discussed relaxed security definitions of ratcheting [6,8,12,1,4] allow for efficient constructions because they restrict the adversary more than necessary (see Table 1). Although our analysis was partially motivated by the use of kuKEM in [17,10], we do not ultimately answer whether these particular constructions necessarily relied on it.…”

“…We leave the identification of further sets of conditions as future work. 4 For example, the bidirectional channel construction in the proceedings version of [10] is not secure according to the security definition (but a corrected version is published as [11]), in the acknowledgments of [16] it is mentioned that an early submitted version of their construction was also flawed, and for an earlier version of [8] we detected during our work (and informed the authors) that the construction was insecure under bad randomness such that the updated proceedings version (also available as [7]) disregards attacks against randomness entirely. Finally, we detected and reported that the construction of HkuPke in [12] is not even correct.…”