Bidirectional Asynchronous Ratcheted Key Agreement
with Linear Complexity
⋆F. Bet¨ul Durak1,2 and Serge Vaudenay1
1 Ecole Polytechnique F´ed´erale de Lausanne (EPFL)
Lausanne, Switzerland
2 Robert Bosch LLC — Research and Technology Center
Pittsburgh PA, USA
Abstract. Following up mass surveillance and privacy issues, modern secure communica-tion 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 post-compromise 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, exchangingnmessages has complexity O(n2)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 secureBARK scheme using no key-update primitives, no random oracle, and withO(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 thatBARK(even unidirec-tional) implies public-key cryptography, meaning that it cannot solely rely on symmetric cryptography.
1
Introduction
In standard communication systems, protocols are designed to provide messaging services with end-to-end encryption. Essentially, secure communication reduces to continuously exchanging keys, because each message requires a new key. In bidirectional two-party secure communication, partic-ipants alternate their role as senders andreceivers. The modern instant messaging protocols are substantiallyasynchronous. In other words, for a two-party communication, the messages should be transmitted (or the key exchange should be done) even though the counterpart is not online. Moreover, to be able to send the payload data without requiring online exchanges is a major design goal calledzero round trip time (0-RTT). Finally, the moment when a participant wants to send a message is undefined, meaning that participants userandom roles (sender or receiver) without any synchronization. They could send messages at the same time.
Even though many systems were designed for the privacy of their users, they rapidly faced security vulnerabilities caused by thecompromises of the participants’ states. In this work, com-promising a participant means to obtain some information about its internal state. We will call it
exposure. The desired security notion is that compromised information should not uncover more
than possible by trivial attacks. For instance, the compromised state of participants should not allow decryption of messages exchanged in the past. This is calledforward secrecy. Typically, for-ward secrecy is obtained by updating states with a one-way function x→H(x)→H(H(x))→... and deleting old entries. It is used, for instance, in RFID protocols [14, 15]. A popular technique in mechanics, that allows forward movement but prevents moving backward is the use of a de-vice called ratchet. In the context of secure communication, a ratchet-like action is achieved by
using randomness in every state update so that a compromised state is not sufficient for the de-cryption of any future communication either. This is calledfuture secrecy orbackward secrecy or
post-compromise security or evenself-healing. One thesis of the present work is that healing after
an active attack involving a forgery is not a nice property. We show that it implies insecurity. After one participant is compromised and impersonated, if communication self-heals, it means that some adversary can make a trivial attack which is not detected. We also demonstrate other events leading to breach of security. Hence, we recommend that communication is totally cut after active attacks.
Previous work. The security of key exchange was studied by many authors. The prominent models
are the CK and eCK models [4, 13].
Techniques for ratcheting first appeared in real life protocols. It appeared in the Off-the-Record (OTR) communication system by Borisov et al. [3]. The Signal protocol designed by Open Whisper Systems [17] later gained a lot of interest from message communication companies. Today, the WhatsApp messaging application has reached billions of users worldwide [20]. It uses the Signal protocol. A broad survey about various techniques and terminologies was made at S&P 2015 by Unger et al. [18]. At CSF 2016, Cohn-Gordon et al. [6] studied bidirectional ratcheted communication and proposed a protocol. However, their protocol does not offer 0-RTT and requires synchronized roles. At EuroS&P 2017, Cohn-Gordon et al. [5] formally studied Signal.
0-RTT communication with forward secrecy was achieved using puncturable encryption by G¨unther et al. at EUROCRYPT 2017 [10]. Later on, at EUROCRYPT 2018, Derler et al. made it reasonably practical by using Bloom filters [7].
At CRYPTO 2017, Bellare et al. [2] gave a secure ratcheting key exchange protocol. Their protocol is unidirectional and does not allow receiver exposure.
At CRYPTO 2018, Poettering and R¨osler (PR) [16] studied bidirectional asynchronous ratch-eted key agreement and presented a protocol which is secure in the random oracle model. Their solution further relies on hierarchical identity-based encryption (HIBE) but offers stronger security than required for practical usage, leaving ample room for improving the protocol. At the same conference, Jaeger and Stepanovs (JS) [11] had similar results but focused on secure communica-tion rather than key agreement. They proposed another protocol relying onHIBE. In both results, HIBEis used to construct encryption/signature schemes with key-update security. This is a rather new notion allowing forward secrecy but is expensive to achieve. In both cases, it was claimed that the depth ofHIBEis really small. However, when participants are disconnected and continue sending several messages, the depth increases quite rapidly. Consequently,HIBEneeds unbounded depth.
Two papers appeared after the first version of the current paper was released.
At EUROCRYPT 2019, Jost, Maurer, and Mularczyk (JMM) [12] designed another ratcheting protocol which has “near-optimal” security and does not use HIBE. Nevertheless, it still has a huge complexity: When messages alternate well (i.e., no participant sends two messages without receiving one in between), processingnmessages requiresO(n)operations in total. However, when messages accumulate before alternating (for instance, because the participants are disconnected by the network), the complexity becomes O(n2). This is also the case for PR [16] and JS [11].3 One advantage of the JMM protocol [12] comes with the resilience with random coin leakage as discussed below.
At EUROCRYPT 2019, Alwen, Coretti, and Dodis (ACD) [1] designed two other ratcheting protocols aiming at immediate decryption, i.e. the ability to decrypt even though some previous messages have not been received yet. This is closer to real-life protocols but this comes with a potential threat: keys to decrypt un-delivered messages are stored until the messages are delivered. Hence, the adversary could choose to hold messages and decrypt them with future state exposure. This prevents forward secrecy. Furthermore, unless the direction of communication changes (or
3 For JS, this is only visible in the corrected version of the paper on eprint [11]. Our complexity analysis
more precisely, if the epoch increases), their protocols do not strictly adhere to the definition of ratcheting as no random coins are used to update the state. This weakens post-compromise se-curity as well. In Table 1, we call this weaker sese-curity “id-optimal” (not to say “insecure” in the model we are interested in) because it is the best we can obtain with immediate decryption. The lighter of the two protocols is not competing in the same category because it mostly uses sym-metric cryptography. It is more efficient but with lower security. Namely, corrupting the state of a participantAimplies impersonatingBtoA, and also decrypting the messages thatAsends. Other protocols do not have this weakness. The second ACD [1] (in the full version) uses asymmetric cryptography.
Some authors address the corruption of random coins in different ways. Bellare et al. [2] and JMM [12] allow leaking the random coins justafter use. JS [11] allow leaking it justbefore usage only. ACD [1] allow adversarially chosen random coins. In most of the protocols, revealing (or choosing) the random coins imply revealing some part of the new state which allows decrypting incoming messages. It is comparable to state exposure. JMM [12] offers better security as revealing the random coins reveals the new state (and allows to decrypt) only when the previous state was already known.
Table 1: Comparison of Protocols: complexity for exchangingnmessages in alternating or accumu-lating mode, with timing (in seconds) forn=900 of comparable implementations and asymptotic; and types of coin-leakage security (⇒state exposure means coins leakage implies a state exposure).
Security Complexity Coins leakage resilience Model
alternating accumulating
Poettering-R¨osler [16] optimal 86.3 ,O(n)5897 , O(n2) no ROM
Jaeger-Stepanovs [11] optimal 58.1 ,O(n)9087 , O(n2) pre-send leakage,⇒state exposure ROM Jost-Maurer-Mularczyk [12] near-optimal 2.08 ,O(n) 11.4 , O(n2) post-send leakage ROM
BARK[this paper] sub-optimal 1.46 ,O(n) 1.09 , O(n) no plain
Alwen-Coretti-Dodis [1] id-optimal 1.18 ,O(n) 0.92 , O(n) chosen coins,⇒state exposure plain
Our contributions. We give a definition for a bidirectional asynchronous key agreement (BARK)
along with security properties. We start setting the stage with some definitions (such asmatching
status) then identify all cases leading to trivial attacks. We split them into direct and indirect
leakages. Then, we define security with a KINDgame (privacy). We also consider the resistance
to forgery (impersonation) and the resistance to attacks which would heal after active attacks (RECOVER security). We use these two notions as building blocks to prove KIND-security. We finally construct a secure protocol. Our design choices are detailed below and compared to other papers. More comprehensive and technical comparisons between BARK and Bellare et al. [2], JS [11], and PR [16] protocols are given in Appendix C.
1. Simplicity. Contrary to previous work, we define KINDsecurity in a very comprehensive
way by bringing all notions under the umbrella of a cleanness predicate which identifies and captures all trivial ways of attacking.
while the generated key is transferred to other applications which may leak for different reasons. We do not consider exposure of the random coins.
3. Slightly sub-optimal security. Using the result from exposure allows the adversary to
be active, e.g. by impersonating the exposed participant. However, the adversary is not allowed to use exposures to make atrivial attack. Identifying such trivial attacks is not easy. As a design goal, we adopt not to forbid more than what the intuitive notion of ratcheting captures. We do forbid a bit more than PR [16] and JS [11] which are considered of having optimal security and than JMM [12] (which has near-optimalsecurity)4, though, allowing lighter building blocks. Namely, we need no key-update primitives and have linear-time complexity in terms of the number of exchanged messages, even when the network is occasionally down. This translates to an
important speedup factor, as shown on Table 1. We argue that this is a reasonable choice
enabling ratchet security as we define it:unless trivial leakage, a message is private as long as it
is acknowledged for reception in a subsequent message from the receiver.
4.Sequence integrity. We believe that duplex communication is reliably enforced by a lower level protocol. This is assumed to solve non-malicious packet losses e.g. by resend requests and also to reconstruct the correct sequence order. What we only have to care of is when an adversary prevents the delivery of a message consistently. We make the choice to make the transmission of the next messages impossible under such an attack. Contrarily, ACD [1] advocates for immediate decryption, even though one message is missing. This lowers the security and we chose not to have it.
In theBARKprotocol, the correctness implies that both participants generate the same keys. We define the stages matching status, direct leakage, indirect leakage. We aim to separate trivial attacks and trivial forgeries from non-trivial cases with our definitions. Direct and indirect leak-ages define when the adversary can trivially deduce the key generated due to the exposure of a participant who can either be the same participant (direct) or their counterpart (indirect).
We construct a secure BARK protocol. We build our constructions on top of a public-key cryptosystem and a signature scheme and achieve strong security, without key-update primitives or random oracles. We further show that a weakly secure unidirectionalBARKimplies public-key cryptography.
Notations. We have two characters: Alice (A) and Bob (B). When P designates a participant,
P refers to P’s counterpart. We use the roles send and rec for sender and receiver respectively. We define send = rec and rec = send. When participants A and B have exclusive roles (like in unidirectional cases), we call themsender Sandreceiver R.
Structure of the paper. In Section 2, we define ourBARKprotocol along with correctness definition
andKINDsecurity. Section 3 proves that a simple unidirectional scheme implies public-key encryp-tion. In Section 4 we define the security notions unforgeability and unrecoverability. In Section 5, we give our BARKconstruction. Appendix A recalls definitions for underlying primitives. Using plaintext-aware security, Appendix B shows that “optimally secure” protocols may still eliminate attacks which are of no harm, hence eliminate more than necessary. In Appendix C, we make some comments and comparison with the results of Bellare et al. [2], Poettering-R¨osler [16], and Jaeger-Stepanovs [11].
2
Bidirectional Asynchronous Ratcheted Communication
2.1 BARK Definition and Correctness
Definition 1 (BARK). A bidirectional asynchronous ratcheted key agreement (BARK) consists
of the following polynomially bounded algorithms:
– Setup(1λ)−→$ pp: This defines the common public parameterspp.
– Gen(1λ,pp)→−$ (sk,pk): This generates the secret key skand the public keypkof a participant.
– Init(1λ,pp,sk
P,pkP,P) →stP: This sets up the initial statestP of P given his secret key and
the public key of his counterpart. – Send(stP)
$
− →(st′
P,upd,k): The algorithm inputs a current state stP forP∈{A,B}. It outputs
a tuple (stP′,upd,k)with an updated statestP′, a messageupd, and a keyk.
– Receive(stP,upd)→(acc,stP′,k): The algorithm inputs (stP,upd)where P∈{A,B}. It outputs
a triple consisting of a flagacc∈{true,false}to indicate an accept or reject ofupdinformation,
an updated state stP′, and a keyk i.e.(acc,stP′,k).
For convenience, we define the following initialization procedure for all games. It returns the initial
states as well as some publicly available information z.
Initall(1λ,pp):
1: Gen(1λ,pp)→(sk A,pkA)
2: Gen(1λ,pp)→(skB,pk B)
3: stA←Init(1λ,pp,skA,pkB,A)
4: stB←Init(1λ,pp,skB,pk A,B)
5: z←(pp,pkA,pkB)
6: return(stA,stB,z)
Initialization issplittable in the sense that private keys can be generated by their holders with no need to rely on an authority (except maybe for authentication ofpkA andpkB). Other protocols from the literature assume a trusted initialization.
We consider bidirectional asynchronous communications. We can see, in Fig. 1, Alice and Bob running some sequences of SendandReceiveoperations without any prior agreement. Theirtime
scale is different. This means that Alice and Bob run algorithms in an asynchronous way. We
consider a notion of time relative to a participant P. Formally, the time t for P is the number of elementary steps that P executed since the beginning of the game. We assume no common clock. However, events occur in a game and we may have to compare the time of two different participants by reference to the scheduling of the game. E.g., we could say that time tA for A
happensbeforetimetB forB. Normally, scheduling is under the control of the adversary except in
theCORRECTgame in which there is no adversary. There, we define the scheduling by a sequence of actions. Reading the sequence tells who executes a new step of the protocol.
The protocol also uses random roles. Alice and Bob can both send and receive messages. They take their role (sender or receiver) in a sequence, but the sequences of roles of Alice and Bob are not necessarily synchronized. Sending/receiving is refined by theRATCH(P,role,[upd])call in Fig. 2.
Correctness. We say that a ratcheted communication protocol functions correctly if the receiver
accepts the update information updand generates the same key as its counterpart. Correctness implies that the received keys for participantPhave been generated in the same order as sent keys of participantP. We formally define theCORRECTgame in Fig. 2. We define variables.receivedPkey (respectively sentP
key) keeps a list of secret keys that are generated by P when running Receive (respectively, Send). Similarly, receivedPmsg (respectively sentP
msg) keeps a list of upd information that are received (respectively sent) by P and accepted by Receive. Thereceived sequences only keep values for whichacc=true.
Each variable v such as receivedPmsg, kP, or stP is relative to a participant P. We denote by
v(t)the value ofv at time tforP. For instance,receivedAmsg(t)is the sequence ofupdwhich were received byAat timetforA.
(TInit)
Alice Bob
receivedAlicekey
sentAlice
key received
Bob
key sent
Bob key
Send (T0)
Send (T1)
Receive (T2)
Send (T3)
Receive (T4)
.. .
Send (T5)
Send (T6)
Send (T7)
Receive (T8)
Send (T9)
Receive (T10)
Receive (T11)
k0
k1
k2
k4
k3
k2
k3
k5
k0
k6
k1
k4
Fig. 1: The message exchange between Alice and Bob.
Definition 2 (Correctness of BARK). We say that BARK is correct if for all sequencesched,
the CORRECT game of Fig. 2 never returns 1. Namely, for eachP,receivedPkey is always prefix of
sentP
key5 and eachRATCH(.,rec, .)call accepts.
Security. We model our security notion with an active adversary who can have access to some
of the states of Alice or Bob along with access to their secret keys enabling them to act both as a sender and as a receiver. For simplicity, we have only Alice and Bob as participants. (Models with more participants would be asymptotically equivalent.) We focus on three main security notions which are key indistinguishability (denoted as KIND) under the compromise of states or keys, unforgeability of upd information (FORGE) by the adversary which will be accepted, and
recovery from impersonation (RECOVER) which will make the two participants restore secure
communication without noticing a (trivial) impersonation resulting from a state exposure. A challenge in these notions is to eliminate the trivial attacks.FORGEand RECOVERsecurity will be useful to proveKINDsecurity.
2.2 KIND Security
The adversary can access four oracles calledRATCH, EXPst,EXPkey, andTEST.
RATCH. This is essentially the message exchange procedure. It is defined in Fig. 2. The adversary can call it with three inputs, a participant P, where P ∈ {A,B}; a role of P; and an upd information if the role is rec. The adversary getsupd(forrole=send) oracc (forrole=rec) in return.
EXPst. The adversary can expose the state of Alice or Bob. It inputs P ∈ {A,B} to the EXPst oracle and it receives the full statestP ofP.
EXPkey. The adversary can expose the generated key by calling this oracle. Upon inputtingP, it gets the last keykP generated byP. If no key was generated,⊥is returned.
5 By saying thatreceivedP
keyis prefix ofsent
P
key, we mean that whennis the number of keys generated by
OracleRATCH(P,rec,upd)
1: (acc,stP′,k)←Receive(stP,upd)
2: if accthen 3: updP←upd 4: kP←k 5: stP←stP′
6: appendkPtoreceivedPkey
7: appendupdPtoreceivedPmsg 8: end if
9: returnacc
OracleRATCH(P,send)
10: (st′
P,updP,kP)←Send(stP) 11: stP←stP′
12: appendkP tosentPkey
13: appendupdP tosentP
msg
14: returnupd P
GameCORRECT(1λ,sched) 1: set allsent∗∗ andreceived
∗
∗ variables to∅
2: Setup(1λ)−→$ pp
3: Initall(1λ,pp)→−$ (stA,stB,z)
4: initialize two FIFO listsincomingAandincomingB to empty 5: i←1
6: whileschedi existsdo 7: (P,role)←schedi 8: if role=recthen 9: if incoming
Pis emptythen return0 10: pullupdfromincomingP
11: acc←RATCH(P,rec,upd)
12: if acc=falsethen return1 13: else
14: upd←RATCH(P,send)
15: pushupdtoincomingP 16: end if
17: ifreceivedA
key not prefix ofsentBkey then return1
18: ifreceivedB
key not prefix ofsentAkey then return1
19: i←i+1 20: end while 21: return0
Fig. 2: TheCORRECT game.
TEST. This oracle can be called only once to receive a challenge key which is generated either uniformly at random (if the challenge bit is b = 0) or given as the last generated key of a participantPspecified as input (if the challenge bit isb=1). The oracle cannot be queried if no key was generated yet.
We specifically separateEXPkeyfromEXPst because the keykgenerated byBARKwill be used by an external process which may leak the key. Thus,EXPkey can be more frequent than EXPst, however it harms security less.
To define security, we avoid trivial attacks. Capturing the trivial cases in a broad sense requires a new set of definitions. All of them are intuitive.
Intuitively,Pis in a matching status at a given time if his state is not dependent on an “active” attack (i.e. could result from aCORRECTgame).
Definition 3 (Matching status). We say thatPis in a matching statusat timet forPif
1. at any moment of the game before timetforP,receivedPmsgis a prefix ofsentP
msg— this defines
the time t forPwhenP sent the last message inreceivedPmsg(t);
2. at any moment of the game before timet forP,receivedPmsg is a prefix ofsentP
msg.
We further say that timet forPoriginatesfrom time tforP.
The first condition clearly states that each of the received (and accepted) updmessage was sent before by the counterpart of P, in the same order, without any loss in between. The second condition similarly verifies that those messages from Ponly depend on information coming from
The key exchange literature often defines a notion of partnering which is simpler. Asynchronous random roles makes it more complicated.
Here is an easy property of the notion of matching status.
Lemma 4. IfPis in a matching status at timet, thenPis also in a matching status at any time t06t. Similarly, ifP is in a matching status at timetand tforP originates from t forP, then
Pis in a matching status at timet.
Proof. In Def. 3, it is clear that if the first property holds with timetforP, then it holds for any
timet0< tfor P. Similarly, if the second property holds with timetfor P, then it holds for any timet0< tforP.
Hence, ifPis in a matching status at timet, then he is in a matching status at any timet0< t. Furthermore, if P is in a matching status at timet and time t for P originates from timet for
t, we can exchange the roles of P andP, obtain the first property with time t instead of t, and deduce the second property for some time which is even before. Hence,P is in a matching status
at timet. ⊓⊔
Definition 5 (Forgery). Given a participant P in a game, we say that upd∈ receivedPmsg is a
forgery if at the moment of the game just before Preceived upd,Pwas in a matching status, but
no longer after receiving upd.
In a matching status, any upd received by P must correspond to an upd sent by P and the sequences must match. This implies the following notion.
Definition 6 (Corresponding RATCH calls). Let P be a participant. We consider only the
RATCH(P,rec, .) calls by P returning true. We say that the ith receiving call corresponds to the
jth sending RATCH(P,send) call by P if i= j and P is in matching status at the time of this ith
accepting RATCH(P,rec, .)call.
Lemma 7. In a correctBARKprotocol, two correspondingRATCH(P,rec,upd)andRATCH(P,send)
calls generate the same keykP=kP.
Proof. We lettbe the time of theRATCH(P,rec,upd)call andtbe the time of theRATCH(P,send). IfRATCH(P,rec,upd)andRATCH(P,send)correspond to each other, thenPis in matching status andtoriginates fromt. We follow the sequence ofRATCHcalls made by the game until timetfor
Pand time tforP(i.e., we ignore what happens toPafter time tand to Pafter timet). Due to the properties of the matching status, we can model them as a sequenceschedas in theCORRECT game, where the updmessages are buffered. Using the same random coins, this game produces the same keys. Due to correctness, we havereceivedPkey =sentP
key. The ith element ofreceivedPkey is
kP(t). Thejth element ofsentPkey iskP(t). Since i=j, we havekP(t) =kP(t). ⊓⊔
Definition 8 (Ratcheting period of P). A maximal time interval during which there is no
RATCH(P,send)call is called a ratcheting periodof P.
Consequently, aRATCH(P,send)call ends a ratcheting period forPand starts a new one. In Fig. 1, the time betweenT1 andT3 or the intervalT5−T6 are called ratcheting period of Alice and Bob respectively.
We now define when the adversary can trivially obtain a key generated byPdue to an exposure. We distinguish the case when the exposure was done on P (direct leakage) and on P (indirect leakage).
Definition 9 (Direct leakage). Let t be a time andP be a participant. We say that kP(t)has
a direct leakage if one of the following conditions is satisfied:
– There is anEXPkey(P)at a timetesuch that the lastRATCHcall which is executed byPbefore
– P is in a matching status and there exists t0 6 te 6 tRATCH 6 t and t such that time t
originates from timet; time toriginates from timet0; there is oneEXPst(P)at timete; there
is oneRATCH(P,rec, .)at timetRATCH; and there is noRATCH(P, ., .)between timetRATCH and
timet.
In the first case, it is clear thatEXPkey(P)giveskP(te) =kP(t). In the second case (in Fig. 3)6,
the state which leaks from EXPst(P) at time te allows to simulate all deterministic Receive (by
skipping allSend) and to compute the keykP(tRATCH) =kP(t). The reason why we can allow the
adversary to skip all Send is that they make messages which are supposed to be delivered to P
after timet, so they have no impact onkP(t).
Consider Fig. 1. Suppose t is in between time T3 andT4. According to our definition P= A and the lastRATCHcall is at timeT3. It is aSend, thus the second case cannot apply. The next RATCHcall is at timeT4. In this case,kA(t)has a direct leakage if there is a key exposure of Alice
betweenT3 andT4.
Suppose now that T8 < t < T9. We have P = B, the last RATCH call is a Receive, it is at time tRATCH =T8, and t originates from timet= T0 which itself originates from the origin time
t0 =TInit for B. We say thatthas a direct leakage if there is a key exposure between T8−T9 or a state exposure of Bob before time T8. Indeed, with this last state exposure, the adversary can ignore allSendand simulate all Receiveto derive k0.
P P
t0
(EXPst)te
tRATCH
t
t Receive
noRATCH
P P
t′
tRATCH
t
t
te(EXPst)
Send noRATCH
Fig. 3: Direct (left) and indirect (right) leakage
Definition 10 (Indirect leakage).We consider a timetand a participantP. LettRATCH be the
time of the last successful RATCHcall androle be its input role. (We havekP(tRATCH) =kP(t).)
We say that kP(t) has an indirect leakage if P is in matching status at time t and one of the
following conditions is satisfied
– There exists aRATCH(P,role, .)corresponding to thatRATCH(P,role, .)and making akP which
has a direct leakage for P.
– There exists t′ 6 tRATCH 6 t and t 6 te such that P is in a matching status at time te, t
originates from t,te originates from t′, there is one EXPst(P)at timete, androle=send.
In the first case,kP(t) =kP(tRATCH)is also computed by Pand leaks from there. The second case (in Fig. 3) is more complicated: it corresponds to an adversary who can get the internal state ofPbyEXPst(P)then simulate allReceivewith messages fromPuntil the one sent at timetRATCH, ignoring allSendbyP, to recoverkP(t).
For example, lettbe a time betweenT1andT2in Fig. 1. We takeP=A. The lastRATCHcall is at timetRATCH=T1, it is aSendand corresponds to aReceiveat timeT10, buttoriginates from timet=TInit. We say thatthas an indirect leakage forAif there exists a direct leakage forP=B at a time betweenT10 andT11 (first condition) or there exists a EXPst(B)call at a timete(after
time t= TInit), originating from a time t′ before time T1, sote< T10 (second condition). In the latter case, the adversary can simulate Receivewith the updates sent at time T0 andT1 to derive the keyk1.
Exposing the state of a participant gives certain advantages to the attacker and make trivial attacks possible. In our security game, we avoid those attack scenarios. In the following lemma, we show that direct and indirect leakage capture the times when the adversary can trivially win. The proof is straightforward.
Lemma 11 (Trivial attacks). Assume that BARK is correct. For any t and P, if kP(t)has a
direct or indirect leakage, the adversary can computekP(t).
Proof. We use correctness, Lemma 7, and the explanations given after Def. 9 and Def. 10. ⊓⊔
So far, we mostly focused on matching status cases but there could be situations with forgeries. Some are unavoidable. We call themtrivial forgeries.
Definition 12 (Trivial forgery). Let upd be a forgery received by P. At the time t just before
the RATCH(P,rec,upd)call,P was in a matching status. We assume that timet forP originates
from timetforP. If there is anEXPst(P)call during the ratcheting period of Pstarting at timet,
we say thatupdis a trivial forgery.
We define the KINDsecurity game in Fig. 4. Essentially, the adversary plays with all oracles. At some point, he does oneTEST(P)call which returns either the same result asEXPkey(P)(case
b= 1) or some random value (case b= 0). The goal of the adversary is to guess b. The TEST call can be done only once and it defines the participant Ptest = P and the time ttest at which this call is made. It also defines updtest, the last upd which was used (either sent or received) to carry kPtest(ttest) from the sender to the receiver. It is not allowed to make this call at the
beginning, whenPdid not generate a key yet. It is not allowed to make a trivial attack as defined by a cleanness predicate Cclean appearing on Step 6 in the KINDgame in Fig. 4. Identifying the appropriate cleanness predicate Cclean is not easy. It must clearly forbid trivial attacks but also allow efficient protocols. In what follows we use the following predicates:
– Cleak:kPtest(ttest)has no direct or indirect leakage. – CP
trivial forge:Preceived no trivial forgery untilPhas seenupdtest.
(This implies that updtest is not a trivial forgery. It also implies that if P never sees updtest, thenPreceived no trivial forgery at all.)
– CP
forge:Preceived no forgery untilPhas seenupdtest.
– Cratchet:updtestwas sent by a participantP, then received and accepted byP, then someupdack was sent byP, thenupdackwas received and accepted by P.
(Here, P could be Ptest or his counterpart. This accounts for the receipt of updtest being ac-knowledged by Pthroughupdack.)
– CnoEXP(R): there is noEXPst(R)and noEXPkey(R)query. (Ris the receiver.)
Lemma 11 says that the adopted cleanness predicate Cclean must imply Cleak in all considered games. Otherwise, no security is possible. It is however not sufficient as it hardly covers trivial attacks with forgeries.
Cratchet targets that any acknowledged sent message is secure. Another way to say is that a key generated by one Send starting a round trip must be safe. This is the notion of healing by ratcheting. Intuitively, the security notion fromCclean=Cleak∧Cratchet is fair enough.
Bellare et al. [2] consider unidirectional BARK with Cclean = Cleak∧Ctrivial forgePtest ∧CnoEXP(R).
minimal cleanness predicate (it is nevertheless called “optimal”). JMM [12] excludes cases where
Ptest received a (trivial) forgery then had an EXPst(Ptest) before receiving updtest. Actually, they use a cleanness predicate (“near-optimal” security) which is somewhere betweenCleak∧CPtrivial forgetest andCleak∧CAtrivial forge∧CBtrivial forge: this cleanness implies the JMM cleanness which itself implies the PR/JS cleanness.
In our construction (“sub-optimal”), we use the predicateCclean=Cleak∧CAforge∧CBforge. How-ever, in Section 4.1, we define the FORGE security (unforgeability) which implies that (Cleak∧
CA
forge∧CBforge)-KIND security and (Cleak∧CAtrivial forge∧CBtrivial forge)-KIND security are equivalent. (See Th. 16.) One drawback is that it forbids more than (Cleak∧CPtrivial forgetest )-KIND security. The advantage is that we can achieve security without key-update primitives. We will prove in Th. 19 that this security is enough to achieve security with the predicateCclean=Cleak∧Cratchet, thanks toRECOVER-security which we define in Section 4.2. Thus, our cleanness notion is fair enough.
GameKINDAb,Cclean(1
λ)
1:Setup(1λ)−→$ pp
2:Initall(1λ,pp)→−$ (stA,stB,z)
3: set allsent∗
∗andreceived ∗
∗variables to∅
4: setttest,kA,kB to⊥
5:b′←ARATCH,EXPst,EXPkey,TEST(z) 6:if ¬Ccleanthen return⊥ 7:returnb′
OracleEXPst(P) 1:returnstP
OracleTEST(P)
1:if ttest6=⊥then return⊥ 2:if kP=⊥then return⊥
3:ttest←time,Ptest←P,updtest←updP
4:if b=1then
5: returnkP
6:else
7: returnrandom{0, 1}|kP| 8:end if
OracleEXPkey(P) 1:returnkP
Fig. 4:Cclean-KINDgame. (OracleRATCHis defined in Fig. 2.)
Definition 13 (Cclean-KIND security). Let Cclean be a cleanness predicate. We consider the KINDAb,Cclean game of Fig. 4. We say that the ratcheted key agreement BARK is (λ,q,T,ε)-Cclean -KIND-secureif for any adversary limited toq queries and time complexityT, the advantage
AdvA(1λ) =
Pr
KINDA0,Cclean(1λ)→1
−Pr
KINDA1,Cclean(1λ)→1
of Ain KINDAb,Cclean(1
λ)security game is bounded byε.
3
uniARK
Implies
KEM
We now prove that a weakly secureuniARK(a unidirectional asynchronous ratcheted key exchange — a straightforward variant ofBARKin which messages can only be sent from a participant whom we call S and can only be received by another participant whom we call R) implies public key encryption. Namely, we can construct a key encapsulation mechanism (KEM) out of it. We recall theKEMdefinition and itsIND-CPAsecurity in Appendix A.
We consider a uniARKwhich isKIND-secure for the following cleanness predicate:
Cweak: the adversary makes only three oracle calls which are, in order,EXPst(S),RATCH(S,send), andTEST(S).
Theorem 14. Given a uniARK protocol, we can construct a KEM with the following properties.
The correctness of uniARK implies the correctness of KEM. The Cweak-KIND-security of uniARK
implies theIND-CPAsecurity ofKEM.
Proof. Assuming auniARKprotocol, we construct aKEMas follows:
KEM.Gen(1λ)−→$ (sk,pk): run uniARK.Setup(1λ) −→$ pp, uniARK.Initall(1λ,pp) −→$ (st
S,stR,z) and
set pk=stS, sk=stR.
KEM.Enc(pk)−→$ (k,ct): rununiARK.Send(pk)−→$ (.,upd,k)and set ct=upd. KEM.Dec(sk,ct)→k: rununiARK.Receive(sk,upd)→(., .,k).
TheIND-CPAsecurity game with adversaryAworks as in the left-hand side below. We transform Ainto aKINDadversaryBin the right-hand side below.
GameIND-CPA: 1: KEM.Gen−→$ (sk,pk)
2: KEM.Enc(pk)−→$ (k,ct)
3: if b=0 thensetkto random 4: A(pk,ct,k)−→$ b′
5: returnb′
AdversaryB(z): 1: callEXPst(S)→pk 2: callRATCH(S,send)→ct 3: callTEST(S)→k
4: runA(pk,ct,k)→b′
5: returnb′
We can check that Cweak is satisfied. The KIND game with B simulates perfectly the IND-CPA game withA. So, theKIND-security ofuniARKimplies theIND-CPAsecurity ofKEM. ⊓⊔
4
FORGE
and
RECOVER
Security
4.1 Unforgeability
Another security aspect of the key agreementBARKis to have that noupdinformation is forgeable by any bounded adversary except trivially by state exposure. This security notion is independent from KIND security but is certainly nice to have for explicit authentication in key agreement. Besides, it is easy to achieve. We will also use it as a helper to prove KIND security: to reduce
CP
trivial forge-cleanness toCPforge-cleanness.
Let the adversary interact with the oracles RATCH,EXPst,EXPkey in any order. ForBARKto have unforgeability, we eliminate the trivial forgeries (as defined in Def. 12). TheFORGEgame is defined in Fig. 5.
Definition 15 (FORGEsecurity). Consider FORGEA(1λ) game in Fig. 5 associated to the
ad-versary A. Let the advantage of Abe the probability that the game outputs 1. We say that BARK
is (λ,q,T,ε)-FORGE-secure if, for any adversary limited toq queries and time complexityT, the
advantage is bounded byε.
We can now justify why forgeries in theKINDgame must be trivial for aBARKwith unforge-ability.
Theorem 16. If a BARK is (λ,q,T,ε)-FORGE-secure, then (λ,q,T,ε′)-(Cleak ∧CPforgetest)-KIND
-security implies(λ,q,T, 2qε+ε′)-(Cleak∧CPtrivial forgetest )-KIND-security and(λ,q,T,ε′)-(Cleak∧CAforge∧
CB
forge)-KIND-security implies (λ,q,T, 2qε+ε′)-(Cleak∧CAtrivial forge∧CBtrivial forge)-KIND-security.
Proof. Let us assume that we haveFORGE-security and (Cleak∧CPforgetest)-KIND-security. To prove
(Cleak∧CPtrivial forgetest )-KIND-security, we consider an adversaryA. LetCclean=Cleak∧CPtrivial forgetest and
Cclean′ = Cleak∧CPforgetest. We transform the game KIND
A
b,Cclean into a KIND
A
b,C′
clean game by adding a
failure event F which is true if and only if Ptest received a non-trivial forgery before he has seen updtest. By using the Difference Lemma, we have
|Pr[KINDAb,Cclean →1] −Pr[KIND
A
b,C′
GameFORGEA(1λ)
1:Setup(1λ)−→$ pp
2:Initall(1λ,pp) $ −
→(stA,stB,z)
3:(P,upd)←ARATCH,EXPst,EXPkey(z) 4:RATCH(P,rec,upd)→acc
5:if acc=falsethen return0
6:if updis not a forgery forPthen return0 7:if updis a trivial forgery forPthen return0 8:return1
GameRECOVERABARK(1λ) 1:win←0
2:Setup(1λ)−→$ pp
3:Initall(1λ,pp) $ −
→(stA,stB,z)
4: set allsent∗
∗andreceived∗∗variables to∅
5:P←ARATCH,EXPst,EXPkey(z) 6:if we can parse receivedP
msg = (seq1,upd,seq2) and
sentP
msg= (seq3,upd,seq4)withseq16=seq3(whereupd is a single message and allseqiare finite sequences of single messages)thenwin←1
7:returnwin
GamePREDICTABARK(1λ) 1: Setup(1λ)−→$ pp
2: Initall(1λ,pp)−→$ (st A,stB,z)
3: P←ARATCH,EXPst,EXPkey(z) 4: RATCH(P,send)→upd
5: if upd∈receivedPmsg then return1 6: return0
Fig. 5:FORGE,RECOVER, andPREDICTgames. (OracleRATCH,EXPst,EXPkeyare defined in Fig. 2 and Fig. 4.)
We show below that Pr[F]6qε, we deduce
Adv(KINDAC′
clean)6Adv(KIND
A
C′
clean) +2qε
and conclude.
To show Pr[F]6qε, fori=1, . . . ,q, we transformAinto aFORGE-adversaryAias follows:Ai
simulatesAuntilAasks for theith receiveRATCHcall. We denote by Pandupdthe parameters of this ith RATCH(P,rec,upd)call by A. The adversaryAi just stops and outputs (P,upd). The
FORGEgame goes on by making this RATCH(P,rec,upd)call in line 4 of the FORGEgame. and returns 1 if and only if it is accepted as a non-trivial forgery. WhenFoccurs, at least one of theAi
wins in theFORGEgame. However, forgery implies that Pr[FORGEAi→1]6ε. Hence, Pr[F]6qε.
The same proof works for the other cleanness predicates in the statement. ⊓⊔
4.2 Recovery from Impersonation
A priori, it seems nice to be able to restore a secure state when a state exposure of a participant takes place. We show here that it is not a good idea.
LetAbe an adversary playing the two games in Fig. 6. On the left strategy,AexposesAwith anEXPst query (Step 2). Then, the adversaryAimpersonates Aby running the Sendalgorithm on its own (Step 3). Next, the adversary A “sends” a message to B which is accepted due to correctness because it is generated withA’s state. In Step 5,Alets the legitimate sender generate upd′ by callingRATCHoracle. In this step,if security self-restores, thenBaccepts upd′ which is sent byA, henceacc′=1. It is clear that the strategy shown on the left side in Fig. 6 is equivalent
to the strategy shown on the right side of the same figure (which only switches Alice and the adversary who run the same algorithm). Hence, both lead toacc′=1 with the same probabilityp. The crucial point is that the forgery in the right-hand strategy becomes non-trivial, which implies that the protocol is not FORGE-secure. In addition to this, if such phenomenon occurs, we can make a KIND adversary passing the Cleak∧CPtrivial forgetest condition. Thus, we lose KIND-security. Consequently, security shouldnot self-restore.
Alice adversary Bob
(EXPst)
•
•
•
•
•
(forgery)
•
acc=1
acc=1
acc=1
acc=1
acc=1
1: · · ·(normal communications)· · ·
2: EXPst(A)→stA
3: Send(stA)→(st′A,upd,kA)
4: RATCH(B,rec,upd)→acc 5: RATCH(A,send)→upd′
6: RATCH(B,rec,upd′)→acc′
Alice adversary Bob
(EXPst)
•
•
•
•
•
•
(forgery)
acc=1
acc=1
acc=1
acc=1
acc=1
1: · · ·(normal communications)· · ·
2: EXPst(A)→stA
3: RATCH(A,send)→upd 4: RATCH(B,rec,upd)→acc 5: Send(stA)→(st′
A,upd′,kA′)
6: RATCH(B,rec,upd′)→acc′
Fig. 6: Two recoveries succeeding with the same probability.
Definition 17 (RECOVERsecurity). ConsiderRECOVERABARK(1λ)game in Fig. 5 associated to
the adversary A. Let the advantage of Ain succeeding playing the game be Pr(win=1). We say
that the ratcheted communication protocol is (λ,q,T,ε)-RECOVER-secure, if for any adversary
limited toq queries and time complexityT, the advantage is bounded byε.
RECOVER-security is easy to achieve using a collision-resistant hash function.
To be sure that no message was received before it was sent, we need the following security notion. In thePREDICTgame, the adversary tries to makePreceive a messageupdbefore it was sent byP.
Definition 18 (PREDICT security). Consider PREDICTABARK(1λ) game in Fig. 5 associated to
the adversary A. Let the advantage of A in succeeding playing the game be the probability that1
is returned. We say that the ratcheted communication protocol is (λ,q,ε)-PREDICT-secure, if for
any adversary limited to qqueries, the advantage is bounded by ε.
Theorem 19. If aBARKis(λ,q,T,ε)-RECOVER-secure,(λ,ε′)-PREDICT-secure, and(λ,q,T,ε′′)
-(Cleak∧CAforge∧CforgeB )-KINDsecure, then it is(λ,q,T, 4ε+2qε′+ε′′)-(Cleak∧Cratchet)-KINDsecure.
Proof. Let Cclean = Cleak ∧Cratchet, and let us consider a Cclean-KIND game with an adversary
A. In this game, we define the failure eventF that Cratchet holds and the following happens. We denote by P the participant who sent updtest. Since Cratchet holds, we know that updtest and its acknowledgementupdack are genuine messages. We consider the failure event that, at the end of the game, we can parse
– either receivedPmsg= (seq1,updtest,seq2),sentP
msg= (seq3,updtest,seq4)withseq16=seq3,
– or receivedPmsg= (seq1,updack,seq2),sentmsgP = (seq3,updack,seq4)withseq16=seq3.
We define four RECOVER adversaries Ab,P for b ∈ {0, 1} and P ∈ {A,B} to transform the
KINDAb,Cclean game into a RECOVERAb,P game. More precisely, A
b,P essentially simulates A
ex-cept for theTESToracle, and eventually outputsP. WhenAmakes aTESTquery,Ab,P simulates
this oracle (it uses a EXPkey oracle call for that in the b= 1 case). Clearly, if the failure event happens inKINDAb,Cclean, then eitherRECOVER
Ab,A orRECOVERAb,B returns 1. Due toRECOVER
security, the failure event inKINDAb,Cclean occurs with probability bounded by 2ε.
In a KINDgame where Cratchet holds and the failure eventF does not occurs, we have that
receivedPmsg= (seq1,updtest,seq2),sentP
msg= (seq1,updtest,seq4)
receivedPmsg= (seq1′,updack,seq2′),sentPmsg= (seq
′
Namely, all messages received byPuntilupdtest were sent in the same order byP, and all messages received byPuntilupdackwere sent in the same order by P.
We define another failure event F′ thatCratchet holds,F does not occur, and eitherPis not in a matching status when receivingupdack, orPis not in a matching status when receivingupdtest. For each i = 1, . . . ,q and each b = 0, 1, we define a PREDICT adversary A′
b,i who simulates
KINDAb,Cclean until it makes thei
thsendRATCHcall. If this call is made with a participantQ,A′
b,P
just stops and outputs Q. The simulation of TEST works like for Ab,P. If the failure event F′
happens, it must be the case that one of theA′
b,P adversaries wins thePREDICT game because
one message was received before it was sent. Hence,F′ happens with probability bounded byqε′. When neitherF norF′ happens, the matching status of both participants imply thatCA
forge∧
CB
forgeholds. Hence, by lettingCclean′ =Cleak∧CAforge∧CBforge, we have
|Pr[KINDAb,Cclean→1] −Pr[KIND
A
b,C′
clean →1]|6Pr[F] +Pr[F
′]
62ε+qε′
Hence
Adv(KINDACclean)6Adv(KINDAC′
clean) +4ε+2qε
′
64ε+2qε′+ε′′
⊓ ⊔
5
Our
BARK
Protocol
We construct aBARKin Fig. 7. We use a public-key cryptosystemPKC, a digital signature scheme DSS, a one-time symmetric encryption Sym, and a collision-resistant hash function H. They are all defined in Appendix A. First, we construct a naive signcryption SCfrom PKCandDSSby
SC.Enc(
stS z }| {
skS,pkR,ad,pt) =PKC.Enc(pkR,(pt,DSS.Sign(skS,(ad,pt))))
SC.Dec(skR,pkS
| {z }
stR
,ad,ct) = (pt,σ)←PKC.Dec(skR,ct); DSS.Verify(pkS,(ad,pt),σ)?pt : ⊥
Second, we extend SC to multi-key encryption called onion due to the multiple layers of keys. Third, we transformonion into a unidirectional ratcheting schemeuni. Finally, we designBARK. (See Fig. 7.)
The state of a participant is a tuple st= (λ,hk,ListS,ListR,Hsent,Hreceived)where hk is the
hashing key,Hsentis the iterated hash of all sent messages, and Hreceivedis the iterated hash of all received messages. We also have two listsListS and ListR. They are lists of states to be used
for unidirectional communication: sending and receiving. Both lists are growing but entries are eventually erased. Thus, they can be compressed. (Typically, only the last entry is not erased.)
The idea is that the ith entry of List
S for a participant P is associated to the ith entry of
ListR for its counterpartP. Every time a participant Psends a message, it creates a new pair of
states for sending and receiving and sends the sending state to his counterpartP, to be used in the casePwants to respond. If the same participantPkeeps sending without receiving anything, he accumulates some receiving states this way. Whenever a participant P who received many messages starts sending, he also accumulated many sending states. His message is sent usingall
those states in theuni.Sendprocedure. After sending, all but the last send state are erased, and the message shall indicate the erasures to the counterpartP, who shall erase corresponding receiving states accordingly. Our onion encryption needs to ensureO(n)complexity (we cannot composeSC encryptions as ciphertext overheads would produce aO(n2)complexity). For that, we use a one-time symmetric encryption Symusing a keyk in {0, 1}Sym.kl which is split into shares k
1, . . . ,kn.
Each share isSC-encrypted in one state. Only the last state is updated (as others are meant to be erased).
onion.Enc(1λ,hk,st1S, . . . ,stnS,ad,pt) 1: pickk1, . . . ,knin{0, 1}Sym.kl(λ) 2:k←k1⊕ · · · ⊕kn
3:ctn+1←Sym.Enc(k,pt)
4:adn+1←ad
5:fori=ndown to 1do
6: adi←H.Eval(hk,adi+1,n,cti+1)
7: cti←SC.Enc(stiS,adi,ki) 8:end for
9:return(ct1, . . . ,ctn+1)
onion.Dec(hk,stR, . . . ,1 stnR,ad,ct~) 1:if|ct~|6=n+1then return⊥ 2: parsect~= (ct
1, . . . ,ctn+1)
3:adn+1←ad
4:fori=ndown to 1do
5: adi←H.Eval(hk,adi+1,n,cti+1)
6: SC.Dec(stiR,adi,ct i)→ki 7: ifki=⊥then return⊥ 8:end for
9:k←k1⊕ · · · ⊕kn 10:pt←Sym.Dec(k,ctn+1)
11:returnpt
uni.Init(1λ) 1:SC.GenS(1λ)
$
− →(skS,pkS) 2:SC.GenR(1λ)
$
− →(skR,pkR) 3:stS←(skS,pkR) 4:stR←(skR,pkS) 5:return(stS,stR)
uni.Send(1λ,hk,st~S,ad,pt) 1:SC.GenS(1λ)
$
− →(skS,′ pk′S) 2:SC.GenR(1λ)
$
− →(skR,′ pkR′) 3:st′
S←(sk
′
S,pk′
R) 4:st′
R←(sk
′
R,pk′
S) 5:pt′←(stR,′ pt)
6:onion.Enc(1λ,hk,~stS,ad,pt′)→ct~ 7:return(stS,′ ct~)
uni.Receive(hk,st~R,ad,ct~) 1:onion.Dec(hk,st~R,ad,ct~)→pt′
2:ifpt′=⊥then return(false,⊥,⊥)
3: parsept′= (st′R,pt)
4:return(true,stR,′ pt)
BARK.Setup(1λ) 1:H.Gen(1λ)$
− →hk
2:returnhk
BARK.Gen(1λ,hk) 1:SC.GenS(1λ)
$
− →(skS,pkS) 2:SC.GenR(1λ)
$
− →(skR,pkR) 3:sk←(skS,skR) 4:pk←(pkS,pkR) 5:return(sk,pk)
BARK.Init(1λ,hk,skP,pkP,P) 1: parseskP= (skS,skR) 2: parsepkP= (pkS,pkR) 3:stsend
P ←(skS,pkR) 4:strec
P ←(skR,pkS)
5:stP←(λ,hk,(stPsend),(strecP),⊥,⊥) 6:returnstP
BARK.Send(stP)
1: pickkat random in{0, 1}BARK.kl
2: parsestP= (λ,hk,(stsendP ,1, . . . ,st
send,u P ),(st
rec,1
P , . . . ,st
rec,v
P ),Hsent,Hreceived) 3:uni.Init(1λ)−→$ (st
Snew,st rec,v+1
P ) ⊲append a new receive state to thestrecP list 4:pt←(stSnew,k) ⊲stSnewcould be deleted immediately to avoid leaking
5: take the smallestis.t.stsend,i
P 6=⊥ ⊲i=u−nif we hadnReceivesince the lastSend 6:uni.Send(1λ,hk,(stsend,i
P , . . . ,st
send,u
P ),Hsent,pt)
$
− →(stsend,u
P ,ct~) ⊲updatest
send,u P 7:stsend,i
P , . . . ,st
send,u−1
P ← ⊥ ⊲flush the send state list: onlyst
send,u P remains 8:upd←(Hsent,ct~) ⊲ ~cthasu−i+2(=n+1)components 9:Hsent′←H
.Eval(hk,upd)
10:st′
P←(λ,hk,(st
send,1
P , . . . ,st
send,u P ),(st
rec,1
P , . . . ,st
rec,v+1
P ),Hsent
′
,Hreceived)
11:return(st′
P,upd,k)
BARK.Receive(stP,upd)
12: parsestP= (λ,hk,(stsendP ,1, . . . ,st
send,u P ),(st
rec,1
P , . . . ,st
rec,v
P ),Hsent,Hreceived) 13: parseupd= (h,ct~)
14: setn+1 to the number of components in~ct ⊲the onion hasnlayers 15:ifh6=Hreceivedthen return(false,stP,⊥)
16: setito the smallest index such thatstrec,i P 6=⊥ 17:ifi+n−1> vthen return(false,stP,⊥)
18:uni.Receive(hk,(strec,i P , . . . ,st
rec,i+n−1
P ),Hreceived,~ct)→(acc,stP′
rec,i+n−1
,pt)
19:ifacc=falsethen return(false,stP,⊥)
20: parsept= (stsend,u+1
P ,k) ⊲a newsendstate is added in the list
21:strec,i P , . . . ,st
rec,i+n−2
P ← ⊥ ⊲updatestrecP stage 1: clean up
22:strec,i+n−1
P ←st
′
P
rec,i+n−1 ⊲
updatestrec
P stage 2: updatest
rec,i+n−1
P 23:Hreceived′←H
.Eval(hk,upd)
24:st′
P←(λ,hk,(st
send,1
P , . . . ,st
send,u+1
P ),(st
rec,1
P , . . . ,st
rec,v
P ),Hsent,Hreceived
′)
25:return(acc,st′
P,k)
Fig. 7: Our BARKProtocol.
any exposure has very limited impact. If there are unidirectional sequences, the protocol becomes less and less efficient due to the growth of the lists.
We note that our protocol does not offer (Cleak ∧CPforgetest)-KIND security due to the following attack:
1: EXPst(A)→stA
2: EXPst(B)→stB ⊲this revealssk
rec,1
4: RATCH(A,rec,updB)→true 5: RATCH(A,send)→upd 6: TEST(A)→k
7: Send(stA)→updA ⊲this creates a trivial forgery 8: RATCH(B,rec,updA)→true ⊲this makesBout-of-sync and updatessk
rec,1
B 9: EXPst(B)→stB′ ⊲this revealssk
rec,2
B andsk
rec,1
B (updated) 10: useskrecB,1(from Step 2) andskrecB,2to decryptupd
11: compare the result withk
Note that the trivial forgery is here to make the followingEXPst(B)a non-trivial leakage forskrec,2B (skrec,1B is already known).
The attack is ruled out in the (Cleak∧CAforge∧CBforge)-KIND security which does not allow forgeries untilupdis received.
Theorem 20 (Correctness). BARKin Fig. 7 is correct.
Proof. To prove correctness, we first show that the underlying constructions inBARKare correct.
This is quite straightforward for the signcryptionSCand the multi-key extensiononionof it. When twoSCstatesstS andstR are generated, we call themassociatedSCstates and we denotestS⊲stR
(or stR⊳stS). By convention, we say that⊥ and ⊥are associated SC states as well:⊥⊲⊥. We
extend this notion to vectors ofSCstates. We say that a vectorstsend
P of sending states is associated
to a vector strec
P of receiving states if we haveu6v, where u(resp.v) denotes the size ofst
send
P
(resp.strecP ), and we have stsend,P j⊲strec,j
P forj=1, . . . ,u. We denotest
send
P ⊲strecR orstrecP ⊳stsendR .
For BARK, we first observe that Hsent is the hash of sentmsg and Hreceived is the hash of receivedmsg. In the CORRECT game, the participants are always in a matching status, thus the hashes match. We ignore them below.
For every participant Pand every integer i, letstP,i be the state ofPafter the ith step of the
loop in theCORRECT game. LetuP,i be the size of stsendP,i andvP,i be the size of strecP,i. Similarly,
letkP,i be the key generated byPat stepi.
Each new entry strec,P,ij is generated as somestRfrom auni.InitinBARK.Send. Each new entry
stsend,P,i j is the result of a decryption (which is presumably somestS generated byPfrom a uni.Init
before encryption). Entriesstrec,P,ijare updated with outputs fromSC.GenS inuni.Send. Conversely,
entries stsend,P,i j are updated with the result of decryptions (which are presumably some outputs fromSC.GenR inuni.SendbyP). We have to identify whichstsend,P,i jis associated with whichst
rec,j P,i′.
We can see by looking at the Send and Receive procedures that exactly uP,i−1 messages
were received byP after theith step of the game (stsend
P grows by 1 at every Receiveand its size
remains unchanged at every Send) and exactly vP,i−1 messages were sent by P (strecP grows by
1 at every Send and its size remains unchanged at every Receive). Actually, strec,P j+1 was created whenPsent hisjthmessage andstsend,j+1
P was set whenPdecrypted thej
th message fromP. Due to the structure of theCORRECTgame, a participantPcannot receive more messages than what
Phas sent. Hence, we have the property that
∀P,m,m′ m6m′=⇒uP,m 6vP,m′ (1)
Ifschedi+1= (P,send), we denotestroleP,i
send
−→strole
P,i+1forrole∈{send,rec}. Similarly, ifschedi+1=
(P,rec), we denotestrole
P,i
rec
−→strole
P,i+1forrole∈{send,rec}.
By inspection on theSend andReceiveprocedures, we easily show that
stsendP,m⊲strecP,m′∧st
send
P,m
send
−→stsendP,m+1∧strecP,m′
rec
−→strecP,m′+1
=⇒
stsend
P,m+1⊲strecP,m′+1 strec,vP,m+1
P,m+1 ⊳st
send,uP,m′+1
P,m′+1
kP,m+1=kP,m′+1
Similarly,
stsendP,m⊲strec
P,m′ ∧st
rec
P,m′
send
−→strecP,m′+1
=⇒stsendP,m⊲strec
P,m′+1
because thesendoperation only adds one extrarecstatestrec,vP,m′+1
P,m′+1 , which cannot be taken into account in the⊲definition sinceuP,m 6v
P,m′ < vP,m′+1. We call this property the correctness of the⊥/sendtransition.
We show by induction onithat
∀P,m,m′ (06m6i, 06m′6i,uP,m6vP,m′,vP,m=uP,m′)=⇒stsendP,m⊲strecP,m′
We denote this property byRi.
First of all, R0 is trivial: it is equivalent to∀P stsend,1P,0 ⊲st rec,1
P,0 which is true due to howInitall works. We now assume thatRiis true and we proveRi+1. We consider the operation done in this iteration numberi+1, followingschedi+1. We assume it involves a participantQ. Sinceschedi+1 only involvesQ, we havestQ,i+1=stQ,i. Thus, to proveRi+1, we only have to considerP=Qand
m=i+1, orP=Qand m′ =i+1. Hence, we only have to prove the two following properties:
R1i+1:∀m′ (06m′ 6i,uQ,i+16vQ,m′,vQ,i+1=uQ,m′)=⇒stsendQ,i+1⊲strecQ,m′ (2)
R2i+1:∀m (06m6i,uQ,m 6vQ,i+1,vQ,m =uQ,i+1)=⇒strecQ,i+1⊳stsendQ,m (3)
Case 1:schedi+1= (Q,send). We first proveRi1+1: Letm′ be such that 06m′6i. Due to the sendoperation, we have vQ,i+1 =vQ,i+1. Sincem′ 6i, due to (1) we haveuQ,m′ 6vQ,i thus
uQ,m′ < vQ,i+1. Hence, we cannot havevQ,i+1=uQ,m′. Therefore,R1i+1is true. We also proveR2
i+1: Letmbe such that 06m6i,uQ,m6vQ,i+1, andvQ,m =uQ,i+1. Due to thesendoperation, we haveuQ,i+1=uQ,i. Sincem6i, due to (1) we haveuQ,m6vQ,i. Hence,
we haveuQ,m 6vQ,iandvQ,m=uQ,i. Due toRi, we deducestrecQ,i⊳stsendQ,m. Since,st
rec
Q,i
send
−→strec
Q,i+1, we apply the correctness of the ⊥/send transition to deduce strecQ,i+1⊳stsend
Q,m. Therefore, R
2
i+1 is true.
Therefore,Ri+1 is true in theschedi+1= (Q,send)case.
Case 2: schedi+1= (Q,rec). We consider the smallestm′′6i such thatvQ,m′′ =uQ,i+1(i.e., the message received by Q at step i+1 is the message sent by Q at step m′′ and schedm′′ = (Q,send)). Due to both the send and receive operations, we have vQ,m′′ = vQ,m′′−1+1 and
uQ,i+1 = uQ,i+1 thusvQ,m′′−1 = uQ,i. Furthermore, due to (1), since m′′−1 6 i, we have
uQ,m′′−16vQ,i. We can applyRiand deducestsendQ,m′′−1⊲st
rec
Q,i. We can then apply the correctness
of thesend/rectransition and deduce stsend
Q,m′′⊲strecQ,i+1 andst
rec,vQ,m′′
Q,m′′ ⊳st
send,uQ,i+1
Q,i+1 . We first prove R1
i+1. Let m′ be such that 06m′ 6i, uQ,i+1 6vQ,m′, andvQ,i+1 =uQ,m′.
Due to therecoperation, we haveuQ,i+1=uQ,i+1 andvQ,i+1=vQ,i. Sincem′6i, due to (1) we
haveuQ,m′ 6vQ,i. thus,uQ,i< vQ,m′, andvQ,i=uQ,m′. Due toRi, we havestsendQ,i⊲strecQ,m′. The
rec operation only adds a new elementstsend,uQ,i+1
Q,i+1 in stsendQ,i. We have shown above that this new
element is such thatstsend,uQ,i+1
Q,i+1 ⊲st
rec,vQ,m′′
Q,m′′ . SincevQ,m′′=uQ,i+16vQ,m′, we havem′′6m′.
None of the rec operations for Q in between step m′′ and step m′ will need to use strec,Q,mvQ,m′′′′
because Q has uQ,j 6 uQ,i < vQ,m′′ for all j 6i. Hence, st
rec,vQ,m′′
Q,m′′ = st
rec,vQ,m′′
Q,m′ . We deduce
stsend,uQ,i+1
Q,i+1 ⊲st rec,vQ,m′
Q,m′ . Sincest
send
Q,i ⊲strecQ,m′ and the recoperation does not change the elements
instsendQ,i, we deducestsendQ,i+1⊲strec
Q,m′. Therefore,R
1
i+1 is true.
We also proveR2i+1: Let mbe such that 06m6i,uQ,m6vQ,i+1, andvQ,m =uQ,i+1. We have already proven thatstsend
Q,m′′⊲st
rec
Q,i+1. We havem>m′′(becausem′′ is the smallest integer with thevQ,m =uQ,i+1 property). Hence, only somerecoperations occur forQbetween stepm′′ and stepm. Theserec only add new elements instsend
