NOTRY: Deniable messaging with retroactive avowal

Modern secure messaging protocols typically aim to provide deniability. Achieving this requires that convincing cryptographic transcripts can be forged without the involvement of genuine users. In this work, we observe that parties may wish to revoke deniability and avow a conversation after it has taken place. We propose a new protocol called Not-on-the-Record-Yet ( NOTRY ) which enables users to prove a prior conversation transcript is genuine. As a key building block we propose avowable designated verifier proofs which may be of independent interest. Our implementation incurs roughly 8 × communication and computation overhead over the standard Signal protocol during regular operation. We find it is nonetheless deployable in a realistic setting as key exchanges (the source of the overhead) still complete in just over 1ms on a modern computer. The avowal protocol induces only constant computation and communication performance for the communicating parties and scales linearly in the number of messages avowed for the verifier—in the tens of milliseconds per avowal.


INTRODUCTION
Imagine Mallory wrongfully accuses Alice and Bob of a heinous crime.Alice and Bob have an alibi attested in their chat history, but alas!They communicated using the Off-the-Record protocol [12] (OTR), which is cryptographically deniable.They are therefore unable to satisfactorily prove their innocence to the public!In this paper, we propose a new protocol called Not-On-The-Record-Yet (NOTRY), which preserves the benefits of deniable protocols while enabling Alice and Bob to jointly avow the contents of a conversation should it later become necessary.NOTRY aims to provide the best of both worlds between deniable protocols (that prevent Alice or Bob from individually proving what was said to a third party) and non-repudiable protocols where each message is accompanied by such a proof.
Deniable protocols are commonplace.The widely used Signal [1,55] and recent Messaging Layer Security (MLS) [2,4] protocols both aim to provide deniability-which comes in various flavors.Such variants include transcript deniability (neither party can prove what was said) and participation deniability (neither party can prove who participated at all).Protocols achieve deniability by providing a construction that allows any party to forge a cryptographically valid conversation transcript, without knowledge of the private keys that the participants used to mutually communicate.Herein we present a new variant of deniable communications-with a twist: at some future time  1 after their initial exchange, Alice and Bob may retroactively avow their transcript.That is, Alice and Bob may disseminate additional values showing that a unique version of the transcript is correct (and hence that any other claims are forgeries including those generated prior to  1 ).Beyond the exonerating evidence example provided above, there are many possible scenarios in which two communicating parties might later wish to avow a conversation that they initially intended to remain off the record.A transcript may contain evidence useful to a proceeding in which the interests of the two parties are aligned (e.g.; co-inventors who wish to prove first-to-invent in patent proceedings, an alibi for a crime, or a journalist and source proving the authenticity of a conversation after events have elapsed).

Proofs of non-knowledge
The essential technical idea underlying our work is a trick to prove non-knowledge of a discrete log relationship.Given a value  and two bases , ℎ chosen such that the discrete log relationship between them is unknown, proving knowledge of the discrete logarithm of  to the base  serves as a proof of non-knowledge of the discrete logarithm of  to the base ℎ.Symmetrically, proving knowledge of the discrete logarithm of  to the base ℎ proves non-knowledge of  to the base .This works because if the discrete logarithm of  were known to both bases, this would enable computing of the discrete log of ℎ to the base , therefore the discrete log of  may be known to at most one of the bases , ℎ.The two bases can be chosen using a nothing up my sleeve technique such as hashing a constant value in two different ways to produce two pseudorandom group elements.
A similar idea has been used in protocols for oblivious transfer (OT) [5,36,56,61].For example, the sender in a classic 1-out-of-2 OT chooses two bases , ℎ such that the receiver doesn't know the discrete log relation between them.The receiver then generates two public keys  and  ′ =  ℎ .The sender is convinced that the receiver can't know the private key (discrete log) of both keys (to the base ) without learning a discrete log relation between  and ℎ, and therefore can only decrypt one of two messages.
This works effectively as a proof (to the sender) of non-knowledge of one of the two private keys.In this work, we generalize this idea and provide an explicit description (where previously it was implicit).We extend the idea to proofs-of-non-knowledge in a publicly verifiable setting (whereas in OT the proofs are effectively designated-verifier).We also apply this idea in a new context, avowal of (formerly) deniable proofs.Consider classic designated verifier proofs that prove either knowledge of some witness  for a statement  or knowledge of a secret key   .We can transform this proof by proving the following: (knowledge of  AND the discrete log of  to the base ) OR (knowledge of   AND the discrete log of  to the base ℎ).
If nothing is known about  , then this serves as a designated verifier proof, as it may have been satisfied either by knowing the genuine witness  or the verifier's key   .However, if a separate proof establishes that the discrete log of  is known to either base, this establishes which half of the disjunction was satisfied and reveals if the original designated verifier proof is real or a forgery.
We use an extension of this technique during NOTRY's authenticated key exchange, in which Alice and Bob mutually create a value  =  such that its discrete log to the base  is secret-shared between the two parties (e.g. =   + for values ,  chosen by Alice and Bob respectively).If desired, the two parties can later collaborate to prove knowledge of this discrete logarithm and revoke deniability of the key exchange.

Contributions
With NOTRY we present the first Deniable Authenticated Key Exchange (DAKE) satisfying the security properties described by Unger [66] while additionally supporting retroactive avowal.Our technical contributions are as follows: • We first develop a new primitive: avowable designated verifier proofs.As with standard designated verifier proofs, they can be forged by a party with a specified public key (the designated verifier) and hence are not convincing to other parties.However, with avowable designated verifier proofs the prover later convince a verifier that a previously generated proof is genuine and not a forgery.We formally define the notion of an avowable designated verifier proof as well as providing a concrete instantiation.• We construct a modified DAKE that incorporates our avowable designated verifier proof construction, leading to a secure messaging protocol with retroactive avowal.Our proposal (NOTRY) is the first DAKEA (DAKE with avowal) protocol.We assume that both parties store avowal secrets and verifiers store a genuine log of ciphertext transcripts to be avowed.Without authentic ciphertext it is trivial for parties to retroactively create a fake conversation and avow it.Designing an efficient and secure logging protocol is out of our scope.• We prove the security of our construction using the Universal-Composability framework [16] under a special random oracle model.The proof is conducted under the standard decisional Diffie-Hellman hardness assumption (noting that our protocol is therefore not quantum secure).We show that NOTRY guarantees a strong form of deniability, online deniability [33,68], and also demonstrate that NOTRY offers standard AKE security properties of AKE.• We implement NOTRY and evaluate its performance.In comparison to Signal [55,59], clients incur an 8× times communication overhead and an 8× times computational overhead per key exchange-a manageable performance hit in the face of likely future improvements.When parties wish to avow a message, both they and the judge pay further computation and communication costs to run the avowal protocol.• We further show that our avowal protocol scales effectively to an entire transcript.Parties are free to avow a stream of messages in a conversation without incurring communication overhead above that of avowing a single message.They only need to operate an extra scalar addition for each additional message avowal.The computation and communication performance overhead of the designated verifier grows linearly with the number of messages to be avowed for the verifier, with the slope of 0.006 for computation and receiving extra 32 bytes each time for avowing one more message.
The remainder of the paper proceeds as follows: We commence in Section 2 with a review of work relevant to our design space, which includes message franking schemes and work on retroactivity in cryptography.In Section 3 we introduce all the primitives needed to build our scheme.This proceeds with reintroducing designated verifier proofs (DVs) for the unfamiliar reader, before proceeding on our novel construction of avowable designated verifier proofs (ADVs)-allowing a prover to render a proof verifiable at some point after they first generate it.In Section 3.4 we extend ADVs by introducing mutually avowable DVs, whereby it takes two cooperating provers to avow a message transcript to a third-party verifier.We are then in Section 3.4 able to introduce our overall deniable messaging scheme with retroactive avowal (NOTRY), deferring its security proofs until Section 5. We conclude with implementing and evaluating the protocol in Section 6 followed by a few closing remarks.

RELATED WORK
Our work draws from several similar notions to that of cryptographic avowal-disavowal (its mirror image) and message franking (a one-sided complement to avowal).Here we highlight works that relate across two axes: similar cryptographic notions, and deniable messaging protocols on which we build.

Avowal, Disavowal, and Franking
Chaum [24] defined cryptographic disavowal in his work on zeroknowledge signatures -wherein a signer could convince others under zero-knowledge that a signature does not correspond to the signer's public key and purported message.Cryptographic avowal is also closely related to message franking [41,65].Message franking schemes allow a single party in a conversation to prove the authenticity of part of a conversation, typically only to one specific third party (the judge).Such schemes are useful for abuse management in encrypted communication systems, as they can provide a method for a message recipient to report content to a platform hosting the otherwise encrypted messaging service.Our scheme differs in two ways: 1) both parties to a conversation must agree to avow a conversation and 2) they can choose any third-party as a judge.This vitiates its usefulness as an abuse reporting mechanism but leads to the other use cases we described in Section 1.

Retroactivity in Signature Schemes
There are several other primitives of a similar flavor-providing the ability for parties to change the epistemic status of signatures ex post facto, which we here review.
Park and Sealfon introduced the notion of claimable ring signatures [57].Traditional ring signatures provide a form of deniability by allowing a signer to choose an arbitrary set of public keys and prove that a message was signed by some key from that set (without revealing which key).Claimable ring signatures allow the signer to later claim the signature by proving that their specific key was the one used to sign, similar to our notion of revoking deniability after the fact.The corollary notion of unclaimable ring signatures also exists in which it is not possible to provably claim who signed.
Much like ring signature schemes, some threshold signature sch-emes offer accountability in that the signature reveals which key shares were used to sign.Others may offer privacy in that signatures are indistinguishable regardless of which shares were used.Boneh and Komlo [11] proposed threshold signature schemes with private accountability by introducing a separate accountability key that can be used to compute (and prove) which shares were used to sign, similar to our notion of avowal.
Chaum and van Antwerpen introduced undeniable signatures [25].Undeniable signatures cannot be verified without online interaction with the original signer (though the verification protocol does not provide transferable proof).Effectively, the signer can "disavow" a past signature by refusing to verify it, meaning signatures are effectively deniable until avowed.This is somewhat similar to the goal of proofs with retroactive avowal, although (among other differences) we are working in a two-party setting and support public avowal.
Deniability allows users to convince a judge that they never had such a conversation.It works by providing an easy mechanism for a third-party to generate a forgery that a judge would be unable to distinguish from a legitimate transcript.
Deniability is of particular interest because it directly contrasts with the otherwise desired property of non-repudiabiliy-like past work on franking, our contribution suggests that in the context of secure messaging, both properties may be desirable depending on local context.
Early work explored potential deniable protocols [12,13,47,48] but lacked a corresponding formalism.Di Raimondo et al. [30] formally introduced the notion of deniable authenticated key exchange protocol (DAKE).Deniability now spans an independent line of research [34,35,44,71] and is a standard feature for secure messaging applications, such as Signal and OTR.Considerable work has gone into improving the performance characteristics of DAKEs [30,33,43,55,63,66,70].Finally we point to two works that we particularly draw on for our extensions: Walfish [69] who devised a DAKE protocol which provides deniability, forward secrecy, adaptive secure, and without a trusted third party, and Unger [66] who presented protocols enhanced against insider threats and compatible with group messaging.

BUILDING BLOCKS 3.1 Notations
Let  be a prime and G be a cyclic group of order .We use  and ℎ to denote two independently sampled generators of G (that is, the discrete log relationship of  and ℎ is unknown).Suppose Alice holds a pair of identity keys, the corresponding public key  and private key  are denoted as   = (  ,   ).For -ℎ round key exchange protocol, we denote      to be secrets independently chosen by each party and      to be the corresponding public exponents to the base ℎ.We denote the secret for avowal as  and  respectively.
We write a uniform random number  sampled from set  as  $ ←  .We use  ←  to denote X being set to Y and ≈  to denote computational indistinguishibility.Our security parameter overall is denoted as .We use || to denote message concatenation, as in  1 || 2 .Finally,  denotes a signature and  denotes an established symmetric key.

Designated Verifier Proofs
To develop our construction we start with Jakobsson, Sako, and Impagliazzo's idea of designated verifier (DV) proofs.They used a disjunctive statement to provide deniability [42]. 1 To illustrate this notion we introduce two parties, Alice (the prover) who possesses a statement , and a Judge, Judy (the verifier).
Given a statement  to be proven to a verifier in zero knowledge, Jackobsson et al. proposed issuing a proof of the modified statement: We will abbreviate this construction here: A proof of the compound statement  ′ is only convincing to Judy: If Judy is confident that nobody else knows her private key   (and that she did not compute the proof), then she knows the second clause is false and therefore  is true.
For anyone other than Judy, it is unclear which side of the disjunction is true-it is possible that either  is true or that Judy herself created a valid proof of  ′ by satisfying the second clause.
Therefore, the prover has deniability-the prover can always claim to an outsider that Judy generated the proof whether or not  is true, and the outsider will be unable to tell.

Avowable designated verifier proofs
We build on DV proofs to introduce what we believe is a novel tool: avowable designated verifier proofs (ADV proofs).We later use this to develop NOTRY, however ADV proofs may be of independent interest for other applications.
Given a statement , an ADV proof π is a proof of a modified statement S with two key properties: (1) at time  0 no party, not even the judge, can ascertain the truth of  from S alone and (2) at some future time  1 , the generator of the proof can complete a protocol such that the judge can validate that S attests to the truth of .
Note that it is not enough to merely provide an unconditional (non-designated-verifier) or direct proof that  is true.Providing an unconditional proof would not preclude that previous proofs of  were created as forgeries.
A one-time ADV scheme: A strawman approach would be to prove that nobody knows Judy's private key.Assume that Judy's public key is a group element of the form   =   and Judy's private key is   = .If Judy chooses her public key pseudorandomly as   =  () for some pre-image , then under the discrete-log assumption revealing  proves that nobody knows the corresponding private key   and therefore any proofs issued to   were genuine.However, this scheme means that Judy must use a new key for every proof, and the key must be chosen by the prover in the case of genuine proofs.
A candidate scheme: Instead, we allow the prover to create a new proof-specific statement  which can later be easily proven to be true or false.Given such an auxiliary statement , our ADV proof scheme works by creating a proof of the following statement: Revealing the veracity (or falsehood) of  then makes it clear which half of the disjunction was satisfied and hence whether such a proof was created by an honest prover or by Judy.Note that in either case, the proof creator must choose  and retain a witness to either prove  (in the case of the honest prover) or prove ¬ (in case of the forger).The construction symmetrically enables both avowing an honestly created proof and avowing a forgery.
Based on the candidate scheme, we provide a formal definition of the security properties of an ADV in Section 3.4 and proofs in Section 5.4.1 (deferring them for overall clarity of exposition).

ADV
Functions.An ADV proof scheme consists of the following five functions: Setup() generates public parameters which can be used concurrently and repeatedly for multiple ADV proofs.Separately, we assume a PKI to establish public/private key pairs for all parties and a designated judge.
Gen( S, W ) outputs an ADV proof π of the disjunction S with the witness W ∈ {(,   ), (  ,  P )}, where  for the statement ,   for the knowledge of Judge's private key, and   for the statement  whereas  P for ¬.
Avow(,  ) generates the avowal proof π ′ by (dis)proving an auxiliary statement  for telling which clause in S was proved.The witness   can either be   to avow S was satisfied via  or  P to avow  was satisfied via the knowledge of   .
Verify( π, S) asserts that an ADV proof π is a valid proof for an accompanying ADV statement S.
Judge( π ′ , ) verifies the avowal proof π ′ and asserts the validity of the avowal claim.

Constructing ADV Proofs.
Discrete-log ADV construction: For Σ-protocols, a compelling choice for  is knowledge of the discrete log  of a value  =   (in an appropriate group).There is a classic Schnorr Σ-protocol for proving knowledge of this discrete-log relationship [64] that one can combine with Σ-OR proofs [26] to create an efficient proof of  ′ .The Schnorr protocol does not permit us to directly prove ¬ in a cyclic group: given the construction of  (raising the base  to the power of ) it is clear that group element  has a unique discrete log to the base .Instead, we utilize another generator ℎ sampled independently, ensuring that nobody knows the discrete log relationship between  and ℎ. 2 Proving knowledge of the discrete log of  to the base ℎ suffices to show that the discrete log of  to the base  is unknown.If the discrete log of  was known to both bases  and ℎ, this would enable easily computing the discrete log of  to the base.This yields an efficient candidate for  when constructing Σ-protocols: proof of knowledge of an element  to either the base  (equivalent to proving ) or to the base ℎ (equivalent to proving ¬).
Alternately, if  and ℎ are known to generate subgroups of a group  which are disjoint modulo the identity element, and the subgroup membership problem is assumed to be hard, then proving knowledge of the discrete log of  to the base  is an unconditionally sound proof that the discrete log of  to the base ℎ is unknown (since it will not exist).However, the discrete log assumption is still required for privacy.
Hash-based ADV construction: An alternative, simple construction that might offer efficiency benefits in some circuit-based proof systems utilized preimages of a collision-resistant hash function.Specifically,  might state that given a value , there exists a preimage  =  () under hash function  such that  has odd parity.The corresponding ¬ simply states that  has even parity.This statement can be proven true or false by revealing  (or if necessary this could be proved in zero-knowledge).Note that if two values  and  ′ are known such that  =  () =  ( ′ ) (possibly with differing parity), this would be a hash collision.Thus, only one of , ¬ will be provable assuming the hash function remains collision-resistant.

Mutual ADVs
Finally, the full NOTRY protocol requires an extension to ADV proofs which enables mutual avowal, in which both Alice and Bob's cooperation is needed to avow the proof.We term such a proof a mutual-ADV proof or MADV.
The security goal of MADV avowal proof is to convince the Judge that Alice and Bob together do have the witness  to an ADV statement S while revealing no more information to the Judge.This means that MADV proof avowal is a zero-knowledge proof of knowledge (ZKPoK).Since this paper centers on avowal proofs, security definitions and corresponding proofs of ADV proofs are deferred to appendix A.
Definition: Formally, a secure MADV avowal proof π ′ against the MADV proof π and statement S consists of a triple of algorithms (Setup, Avow, Judge) with the following properties: (1) Completeness: Any prover who generated an MADV proof π can construct the corresponding MADV proof avowal π ′ such that: Completeness indicates that Judge always accepts the MADV avowal proof π ′ from an honest prover.(2) Knowledge Soundness: There exists a PPT extractor E which, given two transcripts of avowal proof generation T 1 and T 2 , can extract a valid witness: where  ′  is the extracted witness.Special soundness implies that any party who generates a valid ADV proof π must gain the knowledge of   to .
(3) Avowal Soundness: For any PPT adversary A, given a MADV proof π, it is unable to produce a valid avowal proof: where negl is a negligible function.(4) Honest Verifier Zero-Knowledge: There exists a  simulator S that generates an MADV avowal proof π ′ S without knowledge of the witness  such that 1 ← Judge( π ′ S ).π ′ S holds that: After defining a secure MADV avowal, we proceed to provide an MADV construction.Based on our discrete-log ADV construction, our construction of MADV begins with Alice and Bob generating a value  = ℎ  + .The value  +  is a shared secret between Alice and Bob; let  and  be individual secrets belonging to Alice and Bob respectively.Generating the shared secret is easy: Alice generates  randomly and sends  = ℎ  to Bob, who generates  randomly and sends  = ℎ  back to Alice.Both sides can compute Recall that proving non-knowledge of a discrete log to base  is achieved by demonstrating knowledge of the discrete log of the same value to another base ℎ where  and ℎ are two independently sampled generators of G. Let ℎ be the generator used to produce the shared secret.Thus, Alice and Bob can use the mutually created  as the value in our ADV construction, making it an MADV as avowal will require both Alice and Bob's participation to prove knowledge of the discrete log of  to the base.
Note that if either party is malicious, they can permanently prevent future avowal.For example, Alice can choose  =   for a random , which will prevent ever avowing that the discrete log of  to the base ℎ is known.This simple attack could be prevented if both sides include a zero-knowledge proof of ,  respectively to the base ℎ (possibly a designated verifier proof for the other party), but this doesn't prevent either party from deleting their avowal share ( or ) immediately after the handshake completes.
We foreshadow that in NOTRY, Alice and Bob each generate an MADV proof attesting to knowledge of their own secret key.Specifically, Alice and Bob provide proof of the below statements, respectively: To see why this is convincing, take Alice's statement (Equation 3.8).For an honest Bob, who has sampled  = ℎ  , he can be sure Alice could not prove dlog ℎ , and hence Alice must know dlog ℎ .This means that dlog   is unknown, and hence Alice must know both dlog    (authenticating her) and dlog ℎ  (meaning her contribution to the avowal secret is well-formed).A symmetric argument applies to Alice's reasoning about Bob's proof.
Observe that this construction is still deniable-a forger can first randomly generate  = ℎ  , then  =   for a random  and derive  = /.This forger can then satisfy both Equation 3.8 and Equation 3.9 by proving dlog ℎ  on the left side (using knowledge of  and dlog   on the right side (using knowledge of ).Note that this forger does not need to know either secret key.
Conversely, avowal works by the parties jointly proving knowledge of dlog ℎ , using the shared secret value  + .This rules out that the simulator was used, as the simulator (having chosen  with a known discrete log to the base ), cannot prove knowledge of dlog ℎ .
There are two possible flavors of avowal: public and designated verifier avowal.Depending on different applications, parties can choose to avow to a designated Judege for partial deniability (avowed transcripts are still deniable for anyone other than the Judge) or publicly avow and completely give up deniability.Constructions are similar for both types of avowal, using either an unconditional proof-of-knowledge of dlog ℎ  for public avowal or its corresponding designated verifier version for designated-verifier avowal.

Signatures of Knowledge
Mutual ADVs alone are not sufficient to build an avowable key exchange protocol, as they are vulnerable to meddler-in-the-middle (MITM) attacks.A standard solution to address MITM attacks in key exchange protocol is to ask parties to include signatures on their messages.However, classic digital signatures will undermine deniability as they provide non-repudiable evidence that a specific private key was used to sign.
To build a deniable authenticated key exchange protocol with retroactive avowal (DAKEA) defending against MITM attack, we instead use signatures of knowledge [23].Unlike classical digital signature schemes which require a specific secret key, computing a signature of knowledge (SoK) requires knowing a witness  for some statement  ∈  for an NP language .Specifically, NOTRY requires parties to compute a signature of knowledge using a witness for the MADV proof statement, like eq. (3.8), on a message which commits to all the public information and the prefix of the transcript.Definition 1.A signature of knowledge scheme for message space M and an NP language  decided by a Turning Machine   is defined by three polynomial-time algorithms (Setup, Sign, Verify) Setup() → pp: produces a set of public parameters pp.Sign(, , , ) → : generates a SoK  on message  by (, , , ) with  if   decides  for statement  ∈  such that   (, ) = 1, otherwise outputting ⊥.
Verify(, , , ) → Accept/Reject: verifies the signature  on message  for statement  with .
A signature of knowledge has three following security properties: Correctness: If a signature  is produced using a valid witness, then it should be accepted by a verifier with overwhelming probability.Simulatability: By checking a signature, a verifier learns nothing beyond that the message is signed properly and the statement is true.This means that the signature of knowledge reveals nothing about the witness which is utilized to generate the signature.Extraction: guarantees that a party who can create a valid signature must "know" a witness  for the statement , in the sense that an extractor exists which can output a witness given access to the signer.In other words, a signature of knowledge is also a proof of knowledge issued by a signer which indicates that she knows the witness to the target statement.
We use this primitive by setting the message  to be signed as the corresponding key exchange protocol messages and letting the statement  be the ADV disjunction S. Therefore, by using the discrete-log ADV construction in Section 3.3.2,a concrete SoK can be constructed.Each ADV prover generates a Schnorr Signature [64] with its secret key and sets the message  to be an instantiation of the ADV statement S.

DESIGN OF NOTRY
Our NOTRY protocol consists of two sub-protocols: NOTRY-Kex and NOTRY-Avow.Like other (D)AKEs, we design our NOTRY-Kex around the Diffie-Hellman protocol with signatures for authentication.We also include a ratcheting scheme in NOTRY-Kex-Ratchet to enable future secrecy in the context of ongoing messaging-typical among secure messaging protocols [12].

NOTRY-Kex
Based on the above constructions and primitives we propose our NOTRY DAKEA key exchange protocol NOTRY-Kex.Before starting NOTRY-Kex, we assume that the authority properly sets up public parameters and identity tokens.Initially, Alice and Bob register their key pairs with a server (similar to Signal's coordinating server or a CA).NOTRY-Kex depicted in Figure 1 proceeds as follows: First, Alice starts the protocol by randomly selecting an ephemeral secret  ∈ Z  .She sends Bob the public exponent  ← ℎ  as with DH protocol.Second, Bob chooses his ephemeral secret  ∈ Z  and computes  ← ℎ  .He generates the ADV proof  to the statement S defined in eq.(3.8) with the knowledge of ephemeral secret  and his secret key   .Based on  he generates a signature of knowledge,   on message  ← (, ).Bob sends   and  back to Alice.
Third, Alice verifies the   from Bob with his public key   and .She aborts if   is invalid.Alice computes her signature of knowledge   on the statement S in eq.(3.9), with knowledge of her private key   and  on message  ← (, ,   ).In parallel, Alice is able to derive the DH key  ←   .Alice can now generate the session key   which is generated by a KDF that takes as input: the two SoKs   ,   , the DH key , and DH transcripts , .Finally, Alice masks her ephemeral secret with the digest  of the session key concatenated with the message "avow" to produce her avowal witness .(Alice now erases  and ).To finish NOTRY-Kex, Alice sends her SoK,   , to Bob.
At last, Bob verifies   from Alice and aborts if the verification fails.Next, Bob computes his DH key  ←   .Bob generates an identical session key to Alice,   , following the same process.Bob gets his avowal witness  in such a way that  +  equals the addition of two ephemeral secrets  +.Finally, Bob securely deletes temporary secrets , .
Note that the SoK statement in NOTRY-Kex is actually consistent with Equation 3.8.Take Alice as an example-she demonstrably does not know  ℎ .Therefore, she is unable to prove both clauses involving  but to prove knowledge of her own ephemeral secret  ←  ℎ  and her private key   ←     .
Forging key exchange transcripts.Using the simulator algorithm NOTRY-Kex-Sim, defined in Figure 3, anyone, including Alice and Bob, is able to generate indistinguishable NOTRY-Kex transcripts, which are , ,   ,   .The core idea of constructing the simulator is to generate ,  ← ℎ  ,   where ,  is sampled from Z  .The simulator generates  ← /.Therefore, the simulator is able to produce a valid ADV-based SoK by proving clauses    ∧  ℎ .
NOTRY-Kex-Ratchet.In most cases, a conversation between Alice and Bob consists of multiple messages.Therefore, a stream of keys is needed to secure a complete conversation consisting of a stream of messages between the two parties.To ensure future secrecy across an ongoing conversation we therefore introduce a ratcheted [59] version of our protocol, NOTRY-Kex-Ratchet.By sending a new SoK each time Alice and Bob update a key, we can extend NOTRY-Kex.As shown in Figure 2, NOTRY-Kex-Ratchet works as follows: • For their first session key  0,0 , parties follow NOTRY-Kex as expected.

NOTRY-Avow
Up to this point, our protocol allows Alice and Bob to establish a secure channel with NOTRY-Kex protocol and to deny a transcript using NOTRY-Kex-Sim.We now introduce the retroactive avowal routine within NOTRY protocol to support retroactive avowal.Recall that to avow, Alice and Bob aim to 'revoke' deniability.Deniability arises from the first AND clause in Equation 3.8 and 3.9, which proves knowledge of dlog ℎ   dlog ℎ  and dlog  ().The avowal procedure works by proving that the proof statement was generated through the second clause (involving the private key), i.e. by giving evidence that the first clause is false.
In a genuine conversation, Alice and Bob are incapable of proving knowledge of dlog   but can prove knowledge of dlog ℎ () -noting that this relies on the absence of a known relationship between  and ℎ.The Judge can therefore be persuaded that the first clause is false by receiving dlog ℎ ().Note that Equation 3.8 and 3.9 both contain dlog  , proving non-knowledge of dlog   indicating both statements are proven via their second clauses.That shows the two SoK signatures   ,   were generated with knowledge of sk  , sk  .
Recall that two styles of avowal are possible, here we choose to give a construction for the designated verifier avowal where public avowal can be trivially derived by excluding the designated clause.Essentially, the designated verifier avowal proves non-knowledge of the discrete log to the designated verifier Judge.Therefore, the Alice now encrypts with hash-ratcheted  sess 10 Bob now encrypts with hash-ratcheted  sess 11 Alice now encrypts with hash-ratcheted  sess 21 . . .final avowal statement to be proven is: As the dlog   is separately held by Alice () and Bob (), we, therefore, devise a two-party Σ proof generation by asking the two to generate their corresponding proof-of-knowledge of their secrets with Σ-OR Schnorr and exchange their proofs.The ultimate ADV avowal proof is an aggregation of the two proofs.Note that the statement  (¬) in eq.(3.3) is instantiated with dlog   (dlog ℎ ).
As shown in Figure 4, NOTRY-Avow works as follows: (1) NOTRY-Avow begins by both parties executing NOTRY-Kex to get a session  rel to communicate securely for the course of the avowal protocol.Note that a simpler deniable key exchange could also be used here to produce a session key for the avowal protocol, for simplicity, we assume we reuse NOTRY-Kex.

SECURITY
We will analyze three algorithms of NOTRY for our security proof.NOTRY-Kex is an authenticated key exchange (AKE) protocol.Parties in NOTRY-Kex, named Alice and Bob, after finishing NOTRY-Kex, generate a shared secret key and learn each other's identity.A secure AKE protocol ensures that they established the key with their intended partner and the key is a fresh secret.The key exchange protocol's transcript, T  , is the concatenation of all the messages exchanged between the two.The simulator algorithm NOTRY-Kex-Sim, depicted in Figure 3, produces a transcript T  without any secret keys to establish plausible deniability as anyone running the simulator could output a transcript T which is indistinguishable from the genuine transcript T .For a UC-secure NOTRY, we are going to prove that continuous key agreement NOTRY-Kex-Ratchet preserves AKE and deniability under that UC framework.
NOTRY-Avow, our construction of MADV avowal proof needs to be a ZKPoK protocol.Second, for the interactive avowal generation, a UC-secure NOTRY requires a UC-secure NOTRY-Avow.
The remainder of this section is organized as follows: Section 5.1 overviews proof techniques that will be used for our proof, Section 5.2 defines desired security properties of NOTRY, and Section 5.3 demonstrates the functionality of NOTRY in our proof, Section 5.4 overviews our UC-secure proof of NOTRY.We defer the remainder of the proofs to appendices.

NOTRY Proof Overview
We proved the security of NOTRY with the Universally Composable Security (UC-secure) [16] framework.A UC-secure protocol is guaranteed to maintain security in an environment where different protocol instances run concurrently, even if the protocol is composed with arbitrary protocols.
Following [33,[66][67][68], we prove NOTRY is UC-secure under the external-subroutine universal composability framework (EUC) [33].EUC is an extended generalized universal composability (GUC) framework [3,17].The GUC framework grants every entity in the model access to all the functionalities across composited protocol sessions.Therefore, it is regarded as a more convincing and accurate model of real-world settings.In addition, the GUC framework more naturally allows us to express the deniability property.GUC-based proofs can be simplified by constraining shared functionalities to a single common functionality G, in the EUC model.Canetti et al. [17] proved that security under the EUC model is equivalent to proving it under the GUC model.
The key observation of our proof strategy is that NOTRY-Kex and NOTRY-Avow are not necessarily sequential.Parties can start avowal even if they haven't exchanged any keys.Of course, this attempt will either fail (generate an invalid proof) or be unconvincing (by not having any corresponding transcript to be avowed).Therefore, after defining ideal functionalities for NOTRY-Kex and NOTRY-Avow separately, proving NOTRY is secure requires proving NOTRY-Kex and NOTRY-Avow are UC-secure respectively.This special flavor of UC is called multi-protocol UC [15].

NOTRY Security Goals
NOTRY has the following security properties.We note that the first four are standard security notions for secure messaging and key exchange, whereas the fifth (mutually-agreed avowal) is novel to our setting: (1) Universally composable AKE [22]: NOTRY-Kex-Ratchet realizes the ideal AKE functionality F  in the Ideal World in the UC framework [16].UC-secure NOTRY-Kex-Ratchet enables the protocol to acquire arbitrary composability beyond the standard notions of an AKE protocol, which are mutual authentication, key privacy and freshness [7,22].(2) Deniability [30,33,39]: Transcripts in NOTRY-Kex can be efficiently forged with access only to the public parameters.
Obviously, this deniability property demolishes the dependability of transcripts as proof of genuine key exchange protocol executions.A stronger notion of deniability, online deniability [33] guarantees that even a corrupted protocol participant (sometimes called an informant) cannot convince others of the authenticity of a transcript.NOTRY provides online deniability since NOTRY-Kex-Sim works without using Alice or Bob's long-term secret key.(3) Future secrecy and post-compromise secrecy [6]: The exposure of long-term secret key(s) cannot undermine the confidentiality of past or future session key(s) respectively (following recovery by the protocol).We achieve future secrecy through ratcheting with NOTRY-Kex-Ratchet, in which both parties update their contribution to   generation.The Output   ,   ,   ,   ,   ,   ,   ,  rel , NOTRY-Kex-Sim transcript, Enc ( rel , (  ,   ,   )) , Enc ( rel , (  ,   )).4) Post-specified peer [21]: Instead of specifying the identity of the intended peer when initiating NOTRY-Kex, parties learn the identity of their peers during protocol execution.The key observation is that Alice starts the protocol without involving any identity information about Bob.Bob's response is not related to   either.Instead, Alice learns she was talking to Bob after she got the SoK of Bob.(5) Mutually-agreed avowal: Transcripts based on session keys from NOTRY-Kex-Ratchet can be avowed by the two parties using NOTRY-Avow.Specifically, NOTRY-Avow is a twoparty secure computation protocol that outputs a MADV avowal as a designated verifier (Judge) proof.

UC Security functionalities
In this section we outline our UC security functionalities, deferring full specifications to Appendix B. Our proof involves three ideal functionalities: • F  , which runs key exchange in the absence of avowal.
The two major functions of F  are to deliver shared session keys and to emulate multiple rounds of a continuous key agreement protocol.
• F avow .For clarity and simplicity, we separate F avow into two major functions, an ideal functionality for avowal proof generation and another one for avowal proof verification.

• G 𝜑,𝑛,G,𝑞,ℎ,𝑔 𝑘𝑟𝑘𝑟𝑜
, which models miscellaneous key registeration with knowledge (krk) PKI and random oracles (ro).It's parameterized by a set of protocols interacting with P, a number of random oracles , a group G of order  with two independently sampled generators ℎ, .This is closely based on the global shared functionality defined in [68].
Ideal Functionality F  To prove NOTRY is UC-secure within the EUC-framework, we compile an ideal functionality F  to emulate NOTRY-Kex-Ratchet which captures all the security properties and features of this protocol.In addition to F  , shown in Algorithm 1, in the EUC-framework, there is an external environment Z, intended to distinguish between a simulator S in the Ideal World attacking the F  and a Real World adversary A attacking the real protocol.We denote dummy parties in the Ideal World as P, the corresponding real parties in the Real World as P, and parties simulated by S for A as P S .
Interactions between different entities in the context of EUCframework are summarized as follows.First, Z is allowed to communicate with P (or P) and to write the inputs to every party P (in the Ideal World) or P (in the Real World) and read their outputs.Likewise, A controls all the communication between every party P (or P S ), whereas S is permitted to interact with F  under prescribed rules.Third, S and A are allowed to corrupt parties while Z will be immediately notified of this corruption.Finally, the ideal functionality F  , S, A, P, P are able to interact with global shared functionality G ,,G,,ℎ,  .We model ratcheting by additionally introducing a round id .NOTRY-Kex-Ratchet is guaranteed to execute in rounds even in the general concurrent operation since NOTRY-Avow checks the consistency of  before setting the shared key.
Ideal functionality F avow For clarity and simplicity, taking advantage of the composability theorem, we defined a separate modular ideal functionality of avow F avow .F avow consists of two major functions: Avow and Judge.Note that, since Judge can be anyone to whom parties intend to avow, we therefore, consider Judge as part of F avow .So the primary task to initialize F avow is to register a Judge and then publish her public key.This models that parties know the identity of the Judge in the Real World.Naturally, as F avow plays as Judge, it runs NOTRY-Avow-Sim Judge to produce transcripts for the simulator S in the Ideal World.
Ideal functionality G ,,G,,ℎ, , depicted in Algorithm 4, is defined to model publicly accessible features/functions like PKI or CA.The Share functionality models three primary cross-session states.First is PKI since we assume that each party learns the other's long-term public key, as well as the key of the designated verifier judge   .Second, a random oracle is needed for KDF functions, signatures-ofknowledge, avowal, and secret sharing in NOTRY-Kex.Essentially, G ,,G,,ℎ,  combines the idea of G  key registration of knowledge, from Dodis et al. [33] to distribute public keys and reveal private keys to corresponding corrupted party.In addition, we also integrated the shared random oracle G  defined in Walfish [69] into G ,,G,,ℎ,  for our proof working on EUC-framework.
The non-information oracle functionality is defined to ensure our ideal F  is relizeable.Since F  outputs a random key in the Ideal World, even classic DH key exchange does not securely realize F  under an adaptive attacker.Z can easily distinguish when a corrupted party's secret state is leaked to Z because there is no way for S to generate the counterpart's transcript to match the random output key and leaked secret.To handle adaptive adversarial corruptions, Canetti and Krawczyk [22] proposed a special non-information oracle.N as part of F  .N emulates a round of key exchange and exposes the secret state of the uncorrupted party to S once corruption happens.This helps S properly simulate a consistent key exchange under an adaptive adversary.
To capture online-deniability, Dodis et al. [33] observed that by relaxing the notion of fully adaptive adversaries to semi-adaptive adversaries we can achieve an online-deniable authentication given the PKI model.Semi-adaptive adversaries are restricted to corrupting a party only at the beginning of a protocol or at the end of it, but they can arbitrarily abort the protocol.After aborting, S gets the corresponding un-simulatable information from an incriminate procedure.This notion of deniability is known as key exchange with incrimination abort (KEIA), which assures deniability once the protocol is terminated by outputting a shared key.Note that if a protocol is executed without abort, it also implies perfect forward secrecy.This is because the session key is chosen randomly and it is independent of any information, including the protocol transcript.

UC-security proof sketch
Finally, we state our main security theorems and a proof sketch, deferring full details to Appendix C and Appendix D. We show a key lemma, that NOTRY-Avow is a ZKPoK scheme, in Section 5.4.1.Upon all the functionalities discussed above, we define UC-secure NOTRY-Kex and UC-secure NOTRY-Avow as following.Proof sketch To show that NOTRY-Kex-Ratchet actually EUCrealizes the F  is to show that for any PPT A attacking NOTRY in the Real World, there exists a corresponding PPT S in the Ideal World attacking F  such that the environment Z under the hybrid G ,,G,,ℎ,  model is unable to distinguish whether it's in the Real World or Ideal World (Theorem 2, proof in Appendix C ).The security proof (Appendix B) of Theorem 3 follows the same paradigm described above.5.4.1 NOTRY-Avow is a secure MADV avowal.We now present our proof that our NOTRY-Avow is a ZKPoK scheme, a key component of proving Theorem 3. Lemma 1. NOTRY-Avow is a secure avowal of MADV proofs under Decisional Diffie-Hellman (DDH) in the random oracle model.Remark 1.For simplicity, here we discuss single-message avowal rather than multi-message avowal.But our argument still holds in the latter case.
We divide proof of Lemma 1 into the following three lemmas: Lemma 2. NOTRY-Avow MADV avowal proof is complete.
Proof.We argue the correctness of MADV avowal by examining the verification process.Since   is the simulator's output, Judge can simply recompute it again to get the identical value.For   , first observe that ℎ   can be expanded to ℎ   ( +)+  +  and    equals to ℎ ( +)  .After dividing ℎ   with    , Judge gets ℎ   +  , which is identical to   ×  , for   ← ℎ   ,   ← ℎ   .The random oracle will output an equivalent value as Judge and provers request with the same values.Therefore, verification will always pass for correctly generated proofs.□ Lemma 3.There exists a PPT extractor E for NOTRY-Avow MADV avowal can extract a valid witness while A is unable to get the witness from a genuine ADV proof π.
Proof.We construct a knowledge extractor to demonstrate how to get secrets ,  with the forking lemma [60].Note that E works the same way to extract both secrets.Suppose that E can rewind a verifier in the NOTRY-Avow to have the challenge  in two proofs.
The extractor E will run NOTRY-Avow twice to extract .In the first round, upon observing that Alice outputs her partial proof   , the E records the partial proof   and rewinds Bob to compel him to output the same .In this case, Alice will generate two proofs for the same challenge .With two partial proofs   , z received from Alice, to get secret , E first collects two common challenge values running NOTRY-Avow   ,   .Now E can derive  by dividing   − z with   −   .Observe that   − z = (   +   ) − (   +   ) equals to    −   .So  ← (  − z )/(  −   ).
Avowal soundness can be trivially satisfied for NOTRY-Avow.Even though the witness of avowal proof serves as a partial witness to the ADV proof, A learns nothing about the ADV witness from a zero-knowledge ADV proof π. □ Remark 2. To illustrate the idea, we follow the classical way of constructing the extractor E with the rewinding technique.However, since rewinding is impermissible in the UC model, straight-line compilers, which are extensively studied in the literature [37,40,45,54,62], can be directly applied to NOTRY-Avow to transform this special Σ-OR proof to a UC-secure one.
Remark 3. A global random oracle is not enough to enable a straight-line compiler in the UC model [18].To extract the witness, a knowledge extractor E without rewinding gets a special power: oberserving all requests to the random oracle and their responses.We, therefore, adopt restricted observable global random oracles [19].Also, note that since we apply the Fiat-Shamir transform to get a non-interactive protocol, this special flavor of random oracle is also needed for special-soundness for both π and π ′ .
Proof.Since it is a designated verifier proof, Judge can easily simulate a correct transcript.Note that this doesn't damage generalization because anyone can serve as a Judge.Therefore, we can construct a simulator NOTRY-Avow-Sim Judge (abbreviate it to S   ), shown in Figure 6, that outputs indistinguishable transcripts of NOTRY-Avow.The information that the simulator takes advantage of is  and   .Basically, the idea used to construct S   is to prove the second clause of the statement Equation (4.1) and then generate the proof.First, S   picks   and samples   ,   from Z  .Set   ←   −   ,   ← ℎ   /()   .Select a random   and set   ←   /  .In this way,   will always be coherent to the verification of NOTRY-Judge.Second, S   moves to prove knowledge of sk  .Getting a random pair (  ,   ) for computing the Fiat-Shamir challenge value .Set   ←  ⊕   and the response value   ←   sk  +   .Third, S   secretly shares   and   to simulate the way they are generated in NOTRY-Avow.Finally, after simulating a correct ADV proof, S   emulates the rest of the communication by running NOTRY-Kex-Sim, selecting a random   to set up   , and compiling two ciphertexts ( c1 , c2 ) ← (Enc( rel , (  ,   ,   )), Enc( rel , (  ,   ))).
It's trivial to test the correctness of the simulated proof.As    =    sk  +  , when it divides pk    we get    , which matches the check.
To show indistinguishability between the simulated transcript and the original transcript, we first observe the output of the simulator is ( π,   ,   ,   , c1 , c2 ).The partial simulated proof (  ,   ) ∈ π is randomly sampled, while   ∈ π is masked by random values   , and   is shadowed by a random oracle output  and random value   .Thus, as each proof element of π = (  ,   ,   ,   ) is either random or masked with a random value, we conclude that π is indistinguishable from random.The same argument can also be applied to prove that  is also indistinguishable from random.Therefore a simulated proof π is indistinguishable from .
Two ciphertexts c1 , c2 are indistinguishable from  1 ,  2 in NOTRY-Avow since the encryption scheme is semantic secure.The   ,   both are generated from random values while   is masked by   , which implies all three values share the identical distribution to their counterparts in NOTRY-Avow.□

REAL WORLD EVALUATION
We designed our protocol for use in real-world systems and accordingly developed a proof-of-concept implementation, which we evaluate here.An anonymized review-ready copy of our code is available at https://github.com/xxsqwe/notry.Our NOTRY implementation is based on the official Rust implementation of Signal [53] and is designed to achieve an equivalent security level (128 bits).In particular, we use the same Curve 25519 [9] as Signal.Our implementation extends the Signal implementation to support both single-and multiple-message transcript avowal.All experiments were performed on an Intel 12th generation core i7-12700K pinned to 3.6GHz with 32GB RAM.
Our goal in evaluation is to determine the performance penalty incurred by implementing NOTRY over a non-avowable secure messaging protocol.We, therefore, compare it against Signal, which represents the best-in-class for secure messaging with deniability.Additional overhead is paid for a UC-secure Signal [10].Therefore, we implement NOTRY without a straight-line compiler for a fair comparison.

Results
First, we profile the computation and communication overhead in the key exchange stage.This gives an indication of the overhead that NOTRY would exhibit in regular use.
As session keys in Signal are generated by the X3DH protocol, which employs double ratcheting with its accompanying performance costs, we implement a similarly ratcheted NOTRY key exchange.We collected our performance results from 10,000 experimental evaluations on our NOTRY-Kex implementation and Signal benchmarks, summarized in Table 1.While NOTRY incurs an approximately 4× communication and 8× computational overhead as compared with the Signal protocol, the absolute time taken per key exchange (∼ 1ms) is still negligible -demonstrating that the protocol may be sufficiently performant for eventual use in production systems.
We also evaluate the cost of performing avowal, both for the communicating parties and for the Judge.Our protocol is designed to allow any server to play the role of a Judge and the cost of verification is therefore not a bottleneck for the protocol.
We measured the cost of running the avowal with 1, 10, 100, and 1000 transcripts respectively, and tabulate our results in Figure 7.We find that the communication and performance costs to the communicating parties are roughly constant, and scales linearly for the Judge.While it is unsurprising that the computational burden falls to the Judge the overall performance costs are both small and linear in the number of transcripts to avow, and therefore pose a lesser deployment concern.

DISCUSSION AND CONCLUSIONS
We identified an interesting potential weakness with existing deniable messaging applications: sometimes both participants in a conversation initially meant to be deniable may genuinely wish to remove deniability and avow the conversation at a later time.
To overcome this limitation, we developed a novel notion, ADV proofs, and applied a practical ADV proof construction to construct NOTRY.To the best of our knowledge, this is the first DAKEA protocol that retains all the critical security properties of DAKE protocols.Our evaluation shows that NOTRY protocol is also a reasonably efficient DAKEA protocol in practice.Some of the techniques in our work may be of interest to other application areas.In particular, our construction of avowable designated verifier proofs may have other applications for systems aiming to provide some flavor of revocable deniability.There also may be other constructions possible for ADV proofs with efficiency advantages in some settings, such as the hash-based constructions we suggested.Constructing efficient ADV proofs under different security assumptions is an interesting research direction.
We would especially like to see the following work that constructs an efficient DAKEA protocol that is quantum-resistant.More generally, this intuition might be extended or equivalent to a new zero-knowledge paradigm, that is, can we prove not owning the witness to an NP statement by proving knowing a witness to a polynomial-time reduction to another statement?The two statements are inverse to each other.
Finally, our work raises interesting questions for deniable messaging.The real-world value of deniability remains an open question, leaving the value of revocable deniability in question as well.There are also many open questions about building NOTRY into a practical system, in particular with handling revocation secrets and providing an acceptable user interface for avowal.
A MADV PROOFS π A.1 Secure MADV proofs π Definition 4. A secure MADV proof π consists of a triple of algorithms (Setup, Avow, Judge) with the following properties: (1) Completeness: Any prover who generated an MADV proof π with knowledge of W satisfies: Completeness indicates that Judge always accepts the MADV avowal proof π ′ from an honest prover.(2) Special Knowledge Soundness: There exists a PPT extractor E which, given two transcripts of avowal proof T 1 and T 2 , can extract a valid witness: Schnorr AND Proof: proving an AND clause via Schnorr protocol is to generate two proofs for the two clauses respectively.For example, to prove dlog ℎ  ∧ dlog    , Alice generates the Schnorr proof to dlog ℎ  as we discussed before.Second, in the same way, Alice generates the Schnorr proof ( ā, z) to dlog    .Alice sends two proofs ((, ),( ā, z)) to Bob who verifies two proofs individually as the basic scheme.
Schnorr OR Proof: [28]   π and π are simulated proofs.It's trivial to tell that all four proofs will pass verification as each proof is a Schnorr proof.
Special soundness: Two accepting proofs with the same first commitment are enough to retrieve the knowledge under the Schnorr protocol.With rewinding, the knowledge extractor E works similarly as the E in NOTRY-Avow.The only distinction in Schnorr-OR proofs is that E is supposed to output an additional bit to indicate which clause was proved.Taking dlog ℎ  ∨ dlog ℎ  as an example, E rewinds Alice to the point where she asks the random oracle to generate two accepting proofs: (  ,   ,   ), (  ,   ,   ) and (  ,  ′  ,  ′  ), (  ,  ′  ,  ′  ).If   ≠  ′  , E outputs 0 to indicate that dlog ℎ  is proved and derives  from π , π ′  the same way as the E in Lemma 3.
On the other hand, consider applying the straight-line compiler to MADV avowal proofs in Remark 4, E will get to search all the queries that Alice made to the random oracle.Since rewinding is not allowed in the UC model.observerable random oracle, defined in Algorithm 4, exposes an additional interface observer-RO to E for extracting the witness.After receiving { π }  ∈ [ ] from Alice, E first parses (  ,   ,   )  ∈ [ ] ← π and sets a = (  )  ∈ [ ] .Second, E sends observe-RO(Alice) to the random oracle and gets back all the requests Alice made.Finally, E finds two requests ,  that share the a but   ≠   and   ≠   and pass Schnorr-OR verification.By the forking lemma [60], E extracts the witness  from (  −  )/(  −  ).
Honest verifier zero-knowledge: we give a simulator S  that simulates indistingsuiable proofs from really proof π.For s , note that the Schnorr proof is just a concatenation of two Schnorr-OR proofs.Therefore, we briefly describe the simulator for Schnor-OR proof.Given ,  ← dlog ℎ , Simulator S  first samples  ,S ,  ,S ,  ,S $ ← Z  , sets  ,S ← ℎ  ,S ,  ,S ← ℎ  ,S /  ,S .Now S  derives  S ←  ( ,S || ,S ||||, ℎ), so  ,S ←  S ⊕  ,S , finally generates  ,S ←  ,S +  ,S .It's trivial to tell that simulated proof shall pass the verification.Note that the special power the S  gets is knowledge of dlog ℎ  which is unknown to Alice.
We proceed with showing that the simulated proof πS is indistinguishable from the MADV proof π, πS ≈  π.
Hybrid 0. : starting with πS = ( ,S ,  ,S ,  ,S ), ( ,S ,  ,S ,  ,S ) .Hybrid 1. : consider a proof π1 S = (  ,   ,   ), ( ,S ,  ,S ,  ,S ) .It is easy to see that the simulated proof π,S is distributed identically to the real π .On the one hand  ,S depends on  ,S and  ,S where both  ,S and  ,S are uniform in Z  .On the other hand, since  is uniform so does   because   ← ℎ  .So any PPT A will be unable to distinguish the uniform  ,S from the uniform   .Also, as  ,S is uniform in Z  ,  is indistinguishable from a random value under a random oracle model,  ,S wil lbe indistinguishable from   which is masked by the random .Finally, because   depends on , , , where ,  are uniform, it will hold that   is uniform as well.Therefore, given  ,S is sampled from Z  , A is incapable of distinguishing two uniform values   ,  ,S from each other.In conclusion, we have π1 S ≈  πS .Hybrid 2. : consider a proof π2 S = (  ,   ,   ), (  ,  , ,   ) .With  ,S depends on  ,S , where  ,S is sampled from Z  , so  ,S is uniform.Applying the same argument to   , we know that the uniform   is indistinguishable from  ,S .,  S is uniform because they are outputs of the random oracle.Therefore,   , which is masked by , is indistinguishable from  ,S , which is masked by  S .  , sampled from Z  , has identical distribution with  ,S which masked a uniform value  ,S .Therefore, we finalize hybrid 2 with π2 S ≈  π1 S .With hybrid proof πS 1

B FUNCTIONALITIES
To prove our NOTRY in the UC model is to construct a simulator S that emulates all the possible transcript a Real World adversary A can produce.Note that S executes A internally.Therefore, any message exchanged between A and Z is through a communication channel by S. Also, messages S received from Z are copied to A. For a party P in the Ideal World, S simulates a corresponding party P S in the Ideal World for A. A is a fully adaptive adversary with arbitrary behaviors.S will compromise P accordingly after A corrupts a simulated party P S .Algorithm 1 shows the Ideal functionality constructed for NOTRY-Kex-Ratchet.Parties join the NOTRY-Kex-Ratchet by Z sending them init or responde message.A party with init message is called initiator  and the one repondes is the responder .Before joining

Figure 1 :
Figure 1: NOTRY-Kex.Alice and Bob follow the Key exchange protocol and store the masked secrets ,  for future avowal.

Figure 3 :
Figure 3: NOTRY-Kex-Sim.Anyone can run the simulator to generate an indistinguishable transcript to deny.

1 Figure 7 :
Figure 7: Avowal Overhead of a Party and the Judge
,   , and   as his proof of the ADV proof avowal.Bob proceeds with getting   ← ℎ   and sending it with encrypted   ,   .
ℎ   ℓ   .Observe that after three-more message exchanges both Alice and Bob will have acquired all of s, s, and s.Both Alice and Bob are then capable of generating the next stage of the avowal proof by setting  ←   ⊕   ,   ←   +   ,   ←     .After that, the simulated proof of   is   ←    / Shamir-based random challenge  of the disjunction proof is generated by hashing the message   ||  .The final challenge   , required to prove dlog ℎ  (which is jointly generated Alice and Bob) is   ←  ⊕   .(6)Respectively,AliceandBobgenerate the last piece of the avowal proof   ←    +   with their partial witness  ∈ [, ].They complete NOTRY-Avow by exchanging The designated Judge verifies  by checking whether it proves the knowledge dlog ℎ  or not.As shown in Figure5, after parsingJudge π ′ , dlog ℎ  ∨ dlog  pk    ,   ,   ,   ← π ′   ← ℎ   /()     ←    /pk    Accept if   ⊕   = H   ||   || • • • , else RejectFigure 5: NOTRY-Judge.Verifying an avowal proof π ′ to the statement (dlog ℎ  ∨ dlog  pk  ) the  from parties Judge recovers   ← ℎ   /()   and   ←    /    .Judge declares a successful avowal if and only if   ⊕  =  (  ||  ).If the formula does not hold, Judge announced that the avowal failed.Avowing Multiple Messages.Alice and Bob may wish to simultaneously avow multiple messages, claiming ownership of an extended conversation.We can extend NOTRY-Avow to support this capability.Suppose Alice with Γ ← [ 1 , • • • ,   ] and Bob with Δ ← [, • • • ,   ] intend to avow  messages.Parties roughly follow the original NOTRY-Avow protocol while integrating all avowal evidence Γ(Δ) into their partial proof   respectively.Specifically,   ←   Γ +   for Alice.As the Judge now receives aggregated avowal proofs  and [ 1 , • • • ,   ] as inputs, we adjust the Judge's verification procedure: Judge computes   ← ℎ   /  =0 (  )   .The rest of the verification follows as per NOTRY-Judge.

Table 1 :
NOTRY and Signal performance evaluation for key exchange 2)where  ′  is the extracted witness.Special soundness implies that any party who generates a valid ADV proof π must gain the knowledge of the witness   to the statement .(3)HonestVerifier Zero-Knowledge: There exists a  simulator S that generates an MADV proof πS without knowledge of the witness  such that 1 ← Judge( πS ).πS holds that:Here, we detail the proof generation and verification protocol.Note that MADV proofs are designed under the context of Signature of Knowledge in NOTRY-Kex, so we instantiate the Signature of Knowledge with the Schnorr identification scheme and the Schnorr signature scheme. and computes  =    .Next, she applies the Fiat-Shamir transform to get a non-interactive proof, setting  =  (||||ℎ).Last, she sends the proof (,  =  +) to Bob. Bob verifies the proof by first reconstructing the random challenge  ′ =  (||||ℎ), then checking if ℎ  ?=  •   ′ .Remark 4. Challenge  will be generated in another way when applying a straight-line compiler to bootstrap the protocol to a UCsecure one.Briefly, given a hash function   , Bob only accepts a proof iff the   (|| ||||||ℎ) starts with  bits long leading zeros and passes verification.In this case, given a commitment , Alice is supposed to try multiple potential challenges until she gets a valid challenge .Also, since   outputs  long digest, where  •  = , so to achieve the -bit level of security, Alice has to generate  proof transcripts {(  ,   )}  ∈ [ ] and ensure that the corresponding hash of every proof   (a||  ||  ||||ℎ) has  leading zeros, where a = ( 1 , • • • ,   ).Alice wraps (, , ) up as the Schnorr proof under the straight-line compiler.
$← Z for the OR clause, i.e. dlog ℎ  ∨ dlog ℎ , since Alice has non-knowledge of dlog ℎ , she will simulate a proof for dlog ℎ .To get a simulated proof, Alice first samples   ,    , then she finalizes simulation with   ←    /   .For the proof to dlog ℎ , Alice generates   ,   as the basic Schnorr scheme.Second, she gets the challenge value  ←  (  ||  ||||||ℎ), computes her really challenge   ←  ⊕   and completes the proof with   ←  +    as the basic scheme.Alice sends two proofs (  ,   ),(  ,   ) to Bob.The verifier Bob first reconstructs  ′  ←    /   ,  ′  ←    /   .Bob accepted a proof if   ⊕   =  ( ′  || ′  ||||||ℎ), otherwise rejects it.A.3 MADV proofs in NOTRY are ZKPoK Lemma 5.The instantiation of the MADV proof in NOTRY-Kex is complete, special sound, and zero-knowledge under DDH/RO assumption.Remark 5. Every security property of an SoK scheme is captured by its corresponding property of MADV proofs defined in Appendix A. Correcteness is defined via Completeness, Simulatability is defined by Zero-knowledge, and Extraction is defined via Special Knowledge Soundness.