A quantum-safe circuit-extension handshake for Tor

John Schanck, William Whyte, and Zhenfei Zhang

Security Innovation, Wilmington, MA 01887

{jschanck,wwhyte,zzhang}@securityinnovation.com

Abstract. We propose a method for integrating NTRUEncrypt into the ntor key exchange protocol
as a means of achieving a quantum-safe variant of forward secrecy. The proposal is a minimal change
to ntor, essentially consisting of an NTRUEncrypt-based key exchange performed in parallel with the
ntor handshake. Performance figures are provided demonstrating that the client bears most of the
additional overhead, and that the added load on the router side is acceptable.
We make this proposal for two reasons. First, we believe it to be an interesting case study into the
practicality of quantum-safe cryptography and into the difficulties one might encounter when transi­
tioning to quantum-safe primitives within real-world protocols and code-bases. Second, we believe that
Tor is a strong candidate for an early transition to quantum-safe primitives; users of Tor may be jus­
tifiably concerned about adversaries who record traffic in the present and store it for decryption when
technology or cryptanalytic techniques improve in the future.

1 Introduction such as [12,23], as well as some Diffie-Hellman proto­

cols like ntor [8].
A key exchange protocol allows two parties who share
no common secrets to agree on a common key over Forward secrecy. A protocol achieves forward secrecy
a public channel. In addition to achieving this ba­ if the compromise of any party’s long-term key ma­
sic goal, key exchange protocols may satisfy various terial does not affect the secrecy of session keys de­
secondary properties that are deemed important to rived prior to the compromise. This property is typi­
security in particular settings. Modern key exchange cally achieved by mixing long-term key material with
protocols typically satisfy some of the following prop­ ephemeral, single-use, keys. It is an essential require­
erties: ment for some applications, particularly those where
an attacker may be able to store encrypted data
One-way or mutual authentication. A protocol for long periods of time until legal, technological, or
achieves mutual authentication if both parties exe­ cryptanalytic means become available for revealing
cuting it can be assured of their peer’s identity. Pro­ keys.
tocols such as [4], [13], and [14] must assume that each This feature is more and more desirable with the
party possesses a certified copy of their peer’s pub­ advent of quantum computers, through which crypt-
lic key in order to achieve this goal. While desirable, analytic compromise of long-term keys may become
mutual authentication is often difficult to achieve in a real possibility rather than mostly theoretical con­
practice, and the weaker property of one-way authen­ cern. There are currently no widely deployed key-
tication, in which only one party is authenticated, is exchange mechanisms capable of resisting quantum
more common. adversaries.

Anonymity. One-way authentication is well suited (Forward) quantum-resistance. A protocol is

for networks, such as Tor [6], that aim to provide quantum-resistant (or quantum-safe) if it remains
their clients with strong anonymity guarantees. In secure under the assumption that the adversary can
such systems, one party (usually the server) pub­ perform polynomial time quantum computations.
lishes a long-term identity key that may be used for There are no widely deployed quantum-safe key
authentication, while the other party (the client) re­ exchange protocols in use today. All methods based
mains anonymous. One-way anonymity is provided on discrete log (Diffie-Hellman, ECDH) and integer
by some Key Encapsulation Mechanisms (KEMs) factorization (RSA) can be broken in polynomial
time using quantum Fourier sampling techniques protocol, so incorporating our handshake into Tor
[19,20]. would not be entirely trivial and would require ei­
There are several proposals for quantum-safe key ther the definition of a new control message, or an
exchange mechanisms in the literature, including sev­ increase in cell size.
eral direct constructions of Diffie-Hellman-like proto­ Furthermore, since we have avoided heavy cryp­
cols from problems thought to be hard for quantum tographic methods such as quantum-resistant signa­
computers [10,16,3]. Another approach, the one taken tures, our protocol does not provide security against
here, is to instantiate a key-encapsulation mechanism active quantum adversaries. Fully quantum-resistant
with a quantum-safe encryption primitive such as key exchange may be required in some settings, but
NTRUEncrypt [9,25]. An example of such an instan­ we believe that a security model that includes pas­
tiation was proposed in [23]. sive, but not active, quantum adversaries is realistic
In order for these schemes to be fully quantum- for the near future.
resistant they would need to maintain their secondary
attributes in the presence of quantum adversaries. Paper Organization In the next section, we review
For instance, authentication could be achieved us­ the background necessary for this paper. In Section
ing a pre-shared symmetric key or a quantum-safe 3, we review the building blocks of our protocol. The
signature scheme, however both approaches present protocol will be presented in Section 4 and its security
practical challenges. In the short term it seems rea­ will be analyzed in Section 5. In Section 6, we com­
sonable to investigate key exchange mechanisms that pare the performance of our protocol with ntor, and
do not provide quantum-safe authenticity, but that in Section 7 we explore the feasibility of integrating
otherwise resist active classical adversaries and pas­ our handshake into the production Tor environment.
sive quantum adversaries. We will call such schemes
forward quantum-resistant. The scheme presented in
[3] and the one presented here both achieve this prop­ 2 Background
erty.
2.1 Notation
Disaster-resistance. We say that a protocol is
disaster-resistant if its security rests on a heteroge­In the rest of the paper, G is always a cyclic group
neous set of assumptions in such a manner that the of known prime order q, and g is a fixed generator
failure of any one assumption would not compromise of G. We use multiplicative notation for group oper­
the security of the entire scheme. This is an especially
ations. Sampling the uniform distribution on a set X
desirable property when deploying new cryptographic is denoted by x ←R X. We freely associate any ob ject
primitives. with a bitstring representing it, for instance Hash(g x )
is presumed to be well defined and unambiguous. The
1.1 Our contribution concatenation of the strings a and b is denoted by a|b.
The protocols we will discuss involve two honest
We demonstrate how to incorporate NTRUEn­ parties who we will call Alice and Bob. Their iden­
crypt into the ntor protocol as a means of achieving tities are represented by Aˆ and B. ˆ In a client-server
forward quantum-resistance. The resulting scheme is scenario, Bob is the server and Alice is the client.
easily seen to inherit the forward secrecy and one-way Party Pˆ has access to a memory M in which they
Pˆ
anonymity properties of ntor. can store session state. The state for session Ψ is de­
We propose an instantiation of our scheme at the noted M [Ψ ].
Pˆ
128-bit security level that uses ntruees439ep1 in ad­
dition to the primitives present in the production in­
stantiation of ntor. We have implemented our pro­ 2.2 Cryptographic primitives
posal within the existing Tor codebase, and have
made our implementation freely available [26]. Public key primitives The protocols described
The primary disadvantage of our scheme is the in­ below involve both Diffie-Hellman and NTRUEn­
creased byte-size of the handshake messages; NTRU- crypt operations and thus make use of the follow­
Encrypt keys and ciphertexts at the recommended ing PPT algorithms. Relevant parameters, G, q, g for
security level are approximately 600 bytes. Unfortu­ Diffie-Hellman and M for NTRUEncrypt, are implic­
nately this exceeds the 512-byte cell size for the Tor itly defined as functions of the security parameter λ.
 Â : B̂ : (b, B)
(x, X) ← DHGen(1λ ) (y, Y ) ← DHGen(1λ )
(pkN , skN ) ← NTRUGen(1λ )
X, pkN
−−−−−−−−−→
s1 = X y |X b
s2 ←R M
c ← NTRUEnc(s2 , pkN )
(vk, K) = H(s1 |B̂|X|Y |s2 |pkN )
auth = Hmac (vk|B̂|Y |X|c|pkN )
Y, c, auth
←−−−−−−−−−−−
s1 = Y x |B x
s2 = NTRUDec(c, skN )
(vk, K) = H(s1 |B̂|X|Y |s2 |pkN )
ensure auth = Hmac (vk|B̂|Y |X|c|pkN )

Fig. 1. The proposed protocol: ntrutor

• DHGen(1λ ) : Let x ←R [1, q − 1], and X = g x . definition captures the idea that the output of a
Outputs the Diffie-Hellman keypair (x, X), where KDF should be indistinguishable from a uniform £
x is the private key and X is the public key. bit string so long as that the conditional min-entropy
• NTRUGen(1λ ) : Outputs an NTRUEncrypt key- of the keying material, given the naturally leaked in­
pair (sk, pk) where sk is the secret key and pk is formation, is at least m bits.
the public key. The KDF appearing in our protocol is assumed to
• NTRUEnc(m, pk) : Takes as input a message m ∈ be λ-entropy secure.
M, and an NTRUEncrypt public key pk. Outputs
a ciphertext c.
• NTRUDec(c, sk) : Takes as input a ciphertext c, 2.3 Related work
and an NTRUEncryptsecret key sk. Outputs a
message m ∈ M. From Diffie-Hellman to ntor. Two parties, Alice
and Bob, who have publicly agreed on parameters –
namely a generator g of a group G of prime order q –
Key derivation functions A Key Derivation Func­ may derive a shared secret in the presence of passive
tion (KDF) [22,1] is a function that takes three inputs eavesdroppers using the Diffie-Hellman protocol [5].
and outputs a string of £ bits. The three inputs are: Alice selects x in [1, q − 1] and sends X = g x to
a sample from a source of keying material, K ∈ K; Bob. Similarly, Bob selects y in [1, q − 1] and sends
a sample from a set of possible salt values, S ∈ S; Y = g y to Alice. They arrive at the common value
and a bitstring specifying additional, or contextual, g xy by computing Y x and X y respectively.
information, I. It is understood that the source from
The security of this protocol requires that the
which the keying material is derived leaks some in­
decisional Diffie-Hellman assumption holds for the
formation to the environment1 , so the role of a key
group G. That is, given g, g x , g y ∈ G, the element
derivation function is to ensure that, despite this in­
g xy is indistinguishable from an element chosen
evitable leakage, the £ output bits are uniformly ran­
uniformly at random from G. This is one of the core
dom.
assumptions of modern cryptography; its apparent
Krawczyk presented an instantiation of a KDF
validity with respect to non-quantum distinguishers
based on a Hash-based Message Authentication Code
for some cyclic groups has enabled many crypto­
(HMAC) in [11] and provided a formal definition of
graphic schemes.
security for KDFs called m-entropy security. This
1
For instance, a Diffie-Hellman handshake might use g xy The authenticated version of the Diffie-Hellman
as keying material and leak g x , g y and the group pa­ protocol presented in Figure 2 was formally analyzed
rameters to the environment. by Shoup in [21], although it was likely known prior
 reveal a long-term secret, is not authenticated, and
 : (a, A) B̂ : (b, B) is allowed to remain anonymous. As detailed in Fig­
(x, X) ← DHGen(1λ ) (y, Y ) ← DHGen(1λ ) ure 4, the parties derive two shared secrets, the first
σA = Signa (X|B̂) σB = Signb (Y |Â) g xy combines the parties’ short-term key material,
X, σA and the second g bx mixes Alice’s short-term key with
−−−−−−−−→
Y, σB Bob’s long-term key. The latter value ensures that
←−−−−−−−− Alice maintains the ability to authenticate Bob, and
K =Yx K = Xy
the former provides forward secrecy against leakage
of Bob’s long-term key.
Fig. 2. The signed Diffie-Hellman key exchange pro­
tocol.
 : B̂ : (b, B)
to that analysis. It is sometimes referred to as the (x, X) ← DHGen(1λ ) (y, Y ) ← DHGen(1λ )
X
signed Diffie-Hellman protocol. −−−−−→
In this protocol each party must produce a signa­ s1 = X y |X b
ture on their public group element and their peer’s (vk, K) = H1 (s1 |B̂|X|Y )
identity. By verifying Alice’s signature, Bob is con­ auth = H2 (vk|B̂|Y |X)
vinced that the group element he received has come Y, auth
←−−−−−−−−−
from Alice, and vice versa. s1 = Y x |B x
Signed Diffie-Hellman suffers from several short­ (vk, K) = H1 (s1 |B̂|X|Y )
comings, the most troubling being that leakage of an ensure auth = Hash1 (vk|B̂|Y |X)
ephemeral key allows an adversary to impersonate
the leaked key’s owner in subsequent sessions.
Fig. 4. The ntor protocol

 : (a, A) B̂ : (b, B)
(x, X) ← DHGen(1λ ) (y, Y ) ← DHGen(1λ ) Key encapsulation mechanisms. Diffie-Hellman
X protocols are far from the only method by which two
−−−−−→
Y
←−−−−−
parties may derive a common key over a public chan­
K = Hash(Y a |B x |Â|B̂) K = Hash(Ay |X b |Â|B̂) nel. Among the many alternatives are Key Encapsu­
lation Mechanisms (KEMs).

Fig. 3. The KEA+ key exchange protocols

Aˆ : ˆ : (b, B)
B
m ←R M
This and other weaknesses are addressed in the c ← EncryptB (m)
KEA+ protocol of Lauter and Mityagin [14]. KEA+ c
−−−−→
avoids the aforementioned impersonation attack by m = DecryptB (c)
deriving the shared secret from a combination of long- K = KDF(m) K = KDF(m)
and short-term key material contributed by both par­
ties (see Figure 3). Specifically, the parties derive two Fig. 5. The key encapsulation mechanisms
shared secrets g ay , and g bx where a, b are long-term
secrets and x, y are short-term secrets. These values
are hashed, along with the identities of both parties, In a KEM, Alice encrypts a random message to
produce the final key. The inclusion of the identities is Bob using Bob’s long-term public key. Bob then de­
crucial for preventing unknown key share attacks[14]. crypts the received ciphertext and the parties derive
Finally, we have arrived at ntor [8], the one-way a shared secret from Alice’s message using a Key
authenticated key exchange protocol that is used in Derivation Function (KDF). Such a KEM provides
recent versions of Tor [6]. The ntor protocol can be one-way authentication and one-way anonymity: Al­
seen as a variant of KEA+ in which Alice does not ice may remain anonymous during the execution of
the protocol, as the shared secret does not depend and X is a public label for x (often the corresponding
on any value linked to her identity; and Alice is able public key).
to authenticate Bob, as she has an authentic copy of Parties communicate with each other via activation
his public key and only he can decrypt her message. requests. These requests are created either directly by
Forward secrecy, however, is notably lacking. If Bob’s the adversary or in response to previous requests from
long-term key is compromised then confidentiality is the adversary. The parties are assumed to execute the
lost for every session previously established. protocol honestly, but the adversary can record, mod­
ify, delete, or attempt to forge requests made by other
parties. A session is started when the adversary re­
3 Security model quests that a party initiate a protocol with another
party of the adversary’s choosing. Each party partic­
The ntor protocol was analyzed in a variant of the ex­ ipating in a session ascribes a locally unique session
tended Canetti-Krawczyk (eCK) model with support identifier, ΨP̂ , to the session. Session identifiers are
for one-way authentication [8]. For continuity with known to the adversary.
this work we will use essentially the same model, but After running their respective parts of the protocol,
we must make a slight modification in order to argue the participating parties output either an error sym­
for quantum-safe forward-secrecy. Fortunately most bol, ⊥, or a tuple of the form (sk, pid, v, u). Once all
of the machinery needed for this was developed in parties have produced an output the session is consid­
[15], which proposed an extension to the model of [8] ered completed. Prior to completion a session is called
for the purpose of analyzing authenticated quantum active.
key expansion protocols. In the model of [15] (here­ The values in a party’s output tuple,2
after MSU) all parties, including the adversary, have (sk, pid, v, u), respectively identify: the session
access to a quantum Turing machine capable of exe­ key, the identity of the peer with whom the session
cuting algorithms with runtime bounded by tq (λ) and key is believed to have been established, a nested list
memory bounded by mq (λ). The inclusion of explicit of the public values used to derive sk, and a nested
bounds allows us to more accurately model the types list of the public values used for authenticating the
of quantum computations which are feasible today peer pid. If the peer was unauthenticated (anony­
and in the near future. mous) during the execution of the protocol then the
token ® is used for pid and the list u will be empty.
The following activation requests are defined:3
3.1 Communication and adversary model
• Req(id, command, arguments, protocol): This ac­
In the MSU model a party is an interactive classical
tivation request directs the intended recipient
Turing machine. A party has access to a memory, a
(specified by id) to perform the action speci­
random tape, and a bounded time/memory quantum
fied by command using arguments as input. The
Turing machine.
protocol is included to ensure that the command
Each party has a public identifier represented by is well defined. This is the only request type that
ˆ These identifiers
a capital letter with a hat (e.g. A).
are used for routing communication and for register­ 2
The output tuple was introduced in [8] as an enhance­
ing certificates. There is a privileged party, labeled ment to traditional AKE security models where the
by Ĉ, that serves the role of certificate authority and adversary-learnable values must be specified at the
with whom all communication is guaranteed to be model level. The output tuple encodes which values are
authentic. As in the eCK model, parties do not prove learnable at the protocol level, and thereby allows for
knowledge of a private key when registering a public the comparison of protocols that would have been in­
key with the certificate authority. This allows the ad­ comparable in earlier AKE models.
3
versary to bind an arbitrary public key to an identity Several more requests are defined in the full MSU
model; for simplicity we have omitted requests for de­
they control, even if that public key is owned by an­
scribing quantum communication and the requests de­
other party. The adversary cannot, however, register scribing the interaction of classical and quantum Tur­
a public key for a party that they do not control. ing machines. We have also merged the two variants of
Parties may have several asymmetric value pairs the SendC request from MSU into our Req request, and
in memory at any given time. These are denoted by added id parameters where they were implicit in MSU.
(x, X ) where x is a secret value, such as a private key, These are purely syntactic changes.
 ordinary parties can issue, the rest may only be Security will be defined with respect to a game
issued by the adversary. the adversary plays after making some (polynomial
• RevealNext(id, type) → X: This request allows in λ) number of activation requests and observ­
the adversary to learn the public value of the spec­ ing/manipulating the honest parties’ results. The ad­
ified type that the party id will use next. For in­ versary starts the game by issuing the following query
stance, RevealNext(A,ˆ DH) causes  to generate to an oracle:
a new Diffie-Hellman key (x, X ) ← DHGen and
to return X to the adversary. The pair (x, X ) • Test(id, Ψ ) → {0, 1}λ : If the party specified by id
is marked as unused and the next time Aˆ would has not output a vector for session Ψ the oracle re­
call DHGen (in response to a request other than turns ⊥. Otherwise, the oracle chooses b ← {0, 1}
RevealNext) it will retrieve (x, X ) instead. Suc­ uniformly. If b = 1 it returns the session key cor­
cessive RevealNext queries allow the adversary to responding to Ψ . If b = 0 it returns a uniform
learn the next k public values of any type that random string in {0, 1}λ .
the party will use. The adversary may only issue one Test query.
• Partner(id, label) → x: This request allows the ad­
versary to learn the secret value associated with Definition 3 (Fresh session [15]). A session Ψ
the given public label. For instance, in response owned by an honest party Pˆi is fresh if all of the fol­
to Partner(A,ˆ X ) the Turing machine  returns lowing occur:
x. The session key is labeled by the session ID its
owner ascribes to it, i.e. the adversary can learn 1. For every vector v j , in P̂i ’s output for session Ψ ,
the key for a session Ψ owned by the party Aˆ by there is at least one element X in v j such that
querying Partner(Â, Ψ ). the adversary is not a partner to X.
2. The adversary did not issue Partner(P̂j , Ψ ' ) to
The adversary can issue any number of these requests any honest party P̂j for which Ψ ' has the same
in any order. public output vector as Ψ (including the case
Partnering to a value is a very important concept where Ψ ' = Ψ and P̂j = P̂i .
in this model. 3. At the time of session completion, for every vec­
tor uj , in P̂i ’s output for session Ψ , there was at
Definition 1 (Partnering). If (x, X ) is a value
ˆ then the adversary is said to least one element X in uj , such that the adver­
pair owned by A,
sary was not a partner to X.
be a partner to X if and only if it has queried
Partner(Â, X ). Note that the session is not fresh if either v or u is
empty. In particular sessions established with anony­
The structure of honest parties’ output vectors, i.e.
mous peers are not fresh.
the segregation of labeled values into those associated
with keying material, v, and those associated with Definition 4 (Security [15]). Let λ be a security
authentication, u, allows for fine grained control over parameter. An authenticated key exchange protocol is
which values the adversary may learn through part­ secure (or (tc (λ), tq (λ), mq (λ))-secure) if, for all ad­
nering as well as when the adversary may them. With versaries A with classical runtime bounded by tc (λ),
the exception of the session key, labeled values that quantum runtime bounded by tq (λ), and quantum
appear in neither v nor u are not able to be learned memory bounded by mq (λ), the advantage of A in
by the adversary through partnering. guessing the bit b used in the Test query of a fresh ses­
sion is negligible in the security parameter; in other
3.2 Security definitions words, the probability that A can distinguish the ses­
sion key of a fresh session from a random string of
We now give the security definitions that will be used the same length is negligible in λ.
in our security arguments in Section 5.
Freshness delineates the situations in which secu­
Definition 2 (Correctness [15]). A key exchange rity is relevant. Note that with these definitions of
protocol is said to be correct if, when all protocol mes­ freshness and security the adversary can partner to
sages are relayed faithfully, without changes to con­ some of the keying material from each v i , and pre­
tent or ordering, the peer parties output the same ses­ serve the freshness of the session, either while the
sion key K and vector v. session is active or after the session is complete, but
cannot partner to all values in any v i at any time. 4 Protocols
The adversary is similarly limited in the ui compo­
nents to which it can be partnered while a session is 4.1 The ntor protocol
active, but is allowed to partner to the entire u vector
after completion. The general outline of ntor was provided in the Sec­
tion 2.3. So as to fully illustrate our method, we first
present the construction from [8] using the model of
Definition 5 (Forward-secrecy). An authenti­ [15] before presenting our protocol.
cated key exchange protocol provides forward secrecy The protocol identifier ntor implicitly defines a se­
if it is secure under Definition 4 and for every fresh curity parameter, λ, Diffie-Hellman parameters, and
session Ψ the following conditions are met: two hash functions:
Hmac : {0, 1}∗ → {0, 1}λ
1. Every long-term value used by an honest party
during the execution of session Ψ is labeled by at H : {0, 1}∗ → {0, 1}λ × {0, 1}λ
least one component of u. Under normal operation the ntor protocol can be
2. If the adversary is not partnered to any compo­ modeled by the following sequence of activation re­
nent of v, then Ψ would remain fresh if the ad­ quests involving the parties A, ˆ B ˆ and the certificate
versary partnered to every component of u. authority C:ˆ

1. Req(Bˆ , “init server”, (∅), ntor),

2. Req(Â, “f etch certif icates”, (∅), ntor),
Definition 6 (Quantum-resistance). An authen­ ˆ “start”, (B),
ˆ ntor),
3. Req(A,
ticated key exchange protocol provides quantum- ˆ ˆ B,
ˆ X ), ntor)),
4. Req(B , “respond”, (ΨAˆ , A,
resistance if it is (tc (λ), tq (λ), mq (λ))-secure for poly­ ˆ “f inish”, (Ψ , Y , auth), ntor).
5. Req(A,
nomially bounded tc (λ) = tq (λ) = mq (λ). Â

At each step the parties’ behavior is governed by the

In analogy with the definition of long-term security following rules:
provided in [15] we propose the following definition
ˆ
of forward quantum-resistance. This definition aims 1. On Req(B, “init server”, (∅), ntor) B̂:
to capture the possibility of an adversary who, in an • Generates a long-term keypair,
attempt to win the Test game, passes a transcript of (b, B) ← DHGen(1λ ).
observed activation requests to a collaborator that • Issues Req(Cˆ , “register”, (B, B),ˆ ntor).
has access to a more powerful quantum Turing ma­
chine. 2. On Req(A,ˆ “f etch certif icates”, (∅), ntor) Â:
• Retrieves a list of all registered certificates
Definition 7 (Forward quantum-resistance). from C.ˆ
Let π be a (tc (λ), tq (λ), mq (λ))-secure authenticated • Stores the received certificates in memory,
key exchange protocol. Let A be an adversary as in MAˆ [“certs”] ← (cert1 , . . . , certn ).
Definition 4, let κ ∈ {0, 1}λ be the result of A’s
query, Test(Pˆ , Ψ ), on a fresh session Ψ . Finally ˆ “start”, (B̂), ntor) Â:
3. On Req(A,
let T be a transcript of classical and quantum bits
• Searches MAˆ [“certs”] for a valid certificate
output by A after a (tc (λ), tq (λ), mq (λ))-bounded
for Bˆ or outputs ⊥ if none is found.
computation.
• Creates a new session, ΨÂ .
We say π is forward quantum-resistant with re­
• Generates an ephemeral DH keypair
spect to A if, for al l quantum Turing machines M
'
with runtime bounded by tq = tc (λ) and memory (x, X ) ← DHGen(1λ ).
'
bounded by mq = tc (λ), the advantage of M, given • Stores MAˆ [ΨAˆ ] ← (B̂, (x, X ), ntor).
(T , κ), in guessing the bit b that was used in the Test • Issues Req(B,ˆ “respond”, (Ψ , A, ˆ B̂, X ), ntor)).
Â
query is negligible in λ.
We say that π is forward quantum-resistant if it is 4. On Req(B, ˆ “respond”, (Ψ ˆ , A, ˆ X ), ntor)) B:
ˆ B, ˆ
A
forward quantum resistant with respect to all adver­ • Verifies X ∈ G, or outputs ⊥.
saries A meeting the above criteria. • Creates a new session, ΨB̂ .
 • Generates an ephemeral DH keypair • Issues Req(Cˆ , “register”, (B, B),
ˆ ntrutor).
(y, Y ) ← DHGen(1λ ).
ˆ “f etch certif icates”, (∅), ntrutor) Â:
2. On Req(A,
• Sets s1 = X y |X b .
• Retrieves a list of all registered certificates
• Sets (vk, K ) = H(s1 |B|X|Y |ntor). ˆ
from C.
• Sets auth = Hmac (vk|B|Y |X|ntor|“Server”).
ˆ “f inish”, (Ψ , Y, auth), ntor). • Stores the received certificates in memory,
• Issues Req(A, Â
• Deletes y, s1 . MÂ [“certs”] ← (cert1 , . . . , certn ).
• Outputs (K, ®, ((X), (Y , B)), ((∅))).
ˆ “start”, (B̂), ntrutor) Â:
3. On Req(A,
ˆ “f inish”, (Ψ ˆ , Y , auth), ntor) Â:
5. On Req(A, A • Searches MAˆ [“certs”] for a valid certificate
• Verifies MAˆ [ΨAˆ ] exists or outputs ⊥. ˆ or outputs ⊥ if none is found.
for B
• Verifies Y ∈ G and that c is a valid ciphertext
• Creates a new session, ΨÂ .
or outputs ⊥.
• Generates an ephemeral DH keypair
• Sets s1 = Y x |B x .
• Sets (vk, K ) = H(s1 |B|X|Y |ntor). (x, X ) ← DHGen(1λ ).
• Ensures auth = • Generates an ephemeral NTRU keypair
Hmac (vk|B|Y |X|ntor|“Server”) (skN , pkN ) ← NTRUGen(1λ ).
or outputs ⊥. • Stores
• Deletes MAˆ [ΨAˆ ] and s1 . ˆ (x, X ), (skN , pkN ), ntrutor).
MAˆ [ΨAˆ ] ← (B,
• Outputs (K, B̂, ((X), (Y, B)), ((B))). ˆ “respond”, (Ψ ˆ , A, ˆ X, pkN ), ntrutor)).
ˆ B,
• Issues Req(B, A
If either party outputs ⊥, it is assumed that both
parties abort the protocol and delete all temporary 4. On Req(B,ˆ “respond”, (Ψ ˆ , A,
ˆ B,
ˆ X, pkN ), ntrutor))
A
state. B̂:
• Verifies X ∈ G and that pkN is a valid
4.2 The proposed protocol NTRUEncrypt key, or outputs ⊥;
• Creates a new session, ΨB̂ .
The protocol identifier ntrutor implicitly defines a se­ • Generates an ephemeral DH keypair
curity parameter, λ, a DH group G, and two hash (y, Y ) ← DHGen(1λ ).
functions:
• Samples s2 ←R {0, 1}λ .
Hmac : {0, 1}∗ → {0, 1}λ • Encrypts s2 under pkN :
H : {0, 1}∗ → {0, 1}λ × {0, 1}λ c ← NTRUEnc(s2 , pkN ).
It additionally specifies a λ-bit secure NTRUEncrypt • Sets s1 = X y |X b .
parameter set. • Sets (vk, K ) = H(s1 |B|X|Y |s2 |pkN |ntrutor).
Under normal operation the ntrutor protocol can • Sets auth =
be modeled by the following sequence of activation
Hmac (vk|B|Y |X|c|pkN |ntrutor|“Server”).
requests involving the parties Â, B̂ and the certificate
ˆ
authority C: • Issues
ˆ “f inish”, (Ψ , Y , c, auth), ntrutor).
Req(A, Â
1. Req(B̂, “init server”, (∅), ntrutor), • Deletes y, s1 and s2 .
2. Req(Â, “f etch certif icates”, (∅), ntrutor), • Outputs (K, ®, ((X, pkN ), (Y, B, pkN )), ((∅))).
3. ˆ “start”, (B),
Req(A, ˆ ntrutor),
4. ˆ
Req(B, “respond”, (ΨAˆ , A,ˆ B ˆ , X, pkN ), ntrutor)), ˆ “f inish”, (Ψ ˆ , Y, c, auth), ntrutor) Â:
5. On Req(A, A
5. ˆ
Req(A, “f inish”, (ΨÂ , Y, c, auth), ntrutor). • Verifies MAˆ [ΨAˆ ] exists or outputs ⊥.
• Verifies Y ∈ G and that c is a valid ciphertext
At each step the parties’ behavior is governed by the
or outputs ⊥.
following rules:
• Decrypts c using skN and sets
ˆ “init server”, (∅), ntrutor) B̂:
1. On Req(B, s2 = NTRUDec(c, skN ).
• Generates a long-term keypair,
• Sets s1 = Y x |B x .
(b, B) ← DHGen(1λ ) • Sets (vk, K ) = H(s1 |B|X|Y |s2 |pkN |ntrutor).
 • Ensures auth = Theorem 1. If there exists an algorithm A that
Hmac (vk|B|Y |X|c|pkN |ntrutor|“Server”) breaks the security of ntrutor when KDF is instanti­
ated with a random oracle, then one can construct an
or outputs ⊥.
algorithm B that solves the gap Diffie-Hellman prob­
• Deletes MAˆ [ΨAˆ ], s1 and s2 .
• Outputs lem in G with non-negligible probability, or breaks the
ˆ ((X, pkN ), (Y , B, pkN )), ((B), (X))). semantic security of NTRUEncrypt.
(K, B,
If either party outputs ⊥, it is assumed that both Proof. Suppose that Ψ is a fresh ntrutor session owned
parties abort the protocol and delete all temporary by party Pˆ and Test(Pˆ , Ψ ) does not return ⊥. The
state. party Pˆ is necessarily an initiator (by definition of
Test), and has output a tuple of the form
4.3 Comparison (K, B̂, ((X, pkN ), (Y, B, pkN ), ((B), (X)))).
ˆ
In ntor the initiating party, A, outputs Since the KDF is modeled as a random oracle, the
(K, B̂, (v 0 = (X), v 1 = (Y, B)), (u0 = (B))). Test challenge is indistinguishable from a uniform
random λ-bit string unless A has queried the oracle
Since the output vector dictates the conditions under
with exactly the same input as P̂ , specifically4 :
which a session is deemed fresh, and freshness is a
necessary precondition for security, we can read A’s ˆ CDH(X, Y ) | CDH(X, B) | NTRUDec(c, skN ).
output as specifying the scenarios that would defi­ The algorithm B is given black-box access to A
nitely compromise an ntor session. Clearly each party and simulates the environment with which A inter­
must contribute some non-compromised keying mate­ acts. B takes as input a CDH instance (U, V ) and an
rial in order for the session to be secure. Consequently instance of the semantic security game for NTRUEn­
we see that the component v 0 dictates that the adver­ crypt, specifically a pair of messages m0 , m1 , a public
sary must never partner to the initiator’s ephemeral key pk, k and a ciphertext C c promised to be an encryp­
key, and v 1 dictates that the adversary must never tion of either m or m under pk.
0 1
k
partner to both B and Y . Likewise, an ntor session
Let n = poly(λ) be the number of parties A will
cannot possibly be secure if the authenticated party’s
initialize in the responder role and let ki = poly(λ)
longterm key was compromised prior to or during the
for i ∈ [1, n] be the number of sessions in which Pˆi
session; and so, u0 requires that the adversary does
will participate.5
not partner to B prior to session completion.
The algorithm B begins by selecting distinct party
In ntrutor the initiating party outputs
indices i, j ∈ [1, n], session indices £ ∈ [1, ki ], m ∈
(K, B̂, ((X, pkN ), (Y , B, pkN )), ((B), (X))). [1, kj ], and a bit r uniformly at random. We denote
By a similar reading, we see that the adversary may by P̂1 and P̂2 the parties indexed by i and j; similarly
partner to Y or pkN at any time, but must not part­ we let Ψ1 and Ψ2 denote the sessions involving P̂1 and
ner to X or B while the session is active. After the P̂2 indexed by £ and m respectively.
session is completed the adversary may partner to any Having fixed these values B begins the simulation
subset (or all) of the DH values provided it does not and handles A’s activation requests in accordance
partner to pkN , or it may partner to pkN provided it with the ntrutor protocol with the following excep­
does not partner to X. Collectively these rules model tions6 :
the claim that ntrutor is secure against the failure
of either the Diffie-Hellman or the NTRU assump­ 4 Here we have rearranged the inputs and omitted public
tion after session completion, but that it relies on the values such as the parties’ public keys and the string
Diffie-Hellman assumption while the session is active. ntrutor for compactness
5
It is also worth pointing out that, to achieve better We fix these quantities for convenience, B could search
efficiency, we do not rely on one-time signatures to 6 for the correct values with polynomial overhead.
bind s1 and s2 . See Appendix A for more details. Not included in this list, but still important to note,
ˆ
is that if r = 1 then B does not know P1 ’s long-term
secret and is unable to handle any “respond” requests
5 Security involving Pˆ1 honestly. However since B simulates all of
the parties it can use the initiator’s ephemeral secret
In this section we give an argument for the Definition to produce s1 as X y |B x and can, otherwise, still follow
4 security of ntrutor in the random oracle model. the protocol in these situations.
 1. If r = 1, then in response to “init server” request the initator’s ephemeral DH key, and is partner to at
number i, B registers V as the longterm public most one of the responder’s DH keys depending on r.
key of Pˆ1 . We show that B can extract a CDH solution from A.
2. We assume that “start” request number £ involv­ Suppose r = 0. The initator’s output is
ing Pˆ1 is directed at an anonymous party, Aˆ1 (K, P̂1 , ((U, pkN ), (V , B , pkN ), ((B), (U )))),
(otherwise B aborts). In response to this request,
B simulates Aˆ1 by performing the normal input and since A has not issued partner requests for U
validation, session creation, and NTRUGen rou­ or V it cannot distinguish this output from an hon­
tines, but skips DHGen and inserts U into the out­ estly generated one. Recall that in the random oracle
going “respond” request in place of an ephemeral model A wins the Test challenge iff it queries
DH key. CDH(U, V ) | CDH(U, B ) | NTRUDec(c, skN ).
If r = 0 then B simulates the response of Pˆ1 by B uses the DDH oracle to recognize this query among
generating c honestly, selecting K and auth uni­ all of the those made by A, and in doing so extracts
formly at random, and inserting V into the out­ the solution CDH(U, V ) to its input.
going “finish” request instead of the ephemeral Now suppose r = 1. The initator’s output is
DH key.
If r = 1 then B simulates the response of Pˆ1 by (K, P̂1 , ((U, pkN ), (Y , V , pkN ), ((V ), (U )))),
generating both c and Y honestly, and selecting and again A cannot distinguish this output from an
K and auth uniformly at random. honestly generated one. As above, B is able to extract
Finally B simulates the response of Â1 to the “fin­ CDH(U, V ) from A’s random oracle query by checking
ish” request by outputting each query with the DDH oracle.
(K, P̂1 , ((U, pkN ), (V, B, pkN )), ((B), (U )))
in the r = 0 case and Case 2. A has queried Test on session Ψ2 . Since B did
not abort, A has not issued a Partner query for the
(K, P̂1 , ((U, pkN ), (Y, V, pkN )), ((V ), (U ))) initator’s ephemeral NTRU key, but may be partner
in the r = 1 case. to any or all of the DH values. We show that B can
3. We assume that “start” request number m involv­ break the semantic security of NTRUEncrypt.
ing P̂2 is directed at an anonymous party, Â2 . In The initiator’s output is
response to this request, B simulates Aˆ2 by per­
forming the normal input validation, session cre­ (K, P̂2 , ((X, pk),
k (Y , B, pk),
k ((B), (X)))).
ation, and DHGen routines, but skips NTRUGen Without loss of generality assume NTRUDec(C c, sk)
k =
and inserts pk into the outgoing “respond” re­
k m 0 . Then A wins the Test challenge iff it queries
quest in place of an ephemeral NTRU key. CDH(X, Y ) | CDH(Y , B) | m0 .
B simulates the response of Pˆ2 by selecting K
Such queries are easily identified and, with all but
and auth uniformly at random, and inserting C c
negligible probability, A does not make a similar
into the “finish” request. The simulated output
query containing m1 . As such, by examining A’s
of Aˆ2 in response is
queries, B can break the semantic security of NTRU-
(K, P̂2 , ((X, pk),
k (Y , B, pk)),
k ((B), (X))). Encrypt.
4. If B cannot simulate one of A’s activation re­
quests, for instance a Partner query involving U , Recall that we assume A wins the Test challenge
then B aborts the simulation. with non-negligible advantage in a non-simulated en­
vironment. By the freshness condition it can do so
Suppose that B has not aborted the simulation and
either by partnering to the test session’s ephemeral
A queries Test on some session. Since B chose the ses­
NTRU key and at most one of the DH values, or
sions to modify uniformly at random, and A cannot
without partnering to the ephemeral NTRU key. A
distinguish these sessions from the others, there is
cannot detect when it is in the simulated environ­
a non-negligible probability that A selects either Ψ1
ment, so its advantage carries over. If it succeeds af­
or Ψ2 for its Test query. There are now two cases to
ter partnering to the ephemeral NTRU key, then by
consider.
case 1 above B solves its GDH instance with non-
Case 1. A has queried Test on session Ψ1 . Since B negligible probability. Otherwise, by case 2, B breaks
did not abort, A has not issued a Partner query for the semantic security of NTRUEncrypt. D
5.1 Related security concerns Those assumptions are adequate for encryptions
since it is quite usual for different encrypted blocks
One-way anonymity The one-way anonymity (as de­ to be transmitted via different links, and assuming
fined in [8]) of our protocol follows immediately from that some of the links are compromised is quite nat­
the one-way anonymity of ntor as proven in [8]. In­ ural. While in a key agreement protocol, those set­
tuitively, the only additional information in an ntru­ tings appear to be unnecessarily strong: the attacker
tor transcript is a set of ephemeral NTRUEncrypt pub­ is allowed to query each encryption scheme on its
lic keys, and these are non-identifying. For a full challenge ciphertext, just not at the same time. In
proof, Partner(·, pkN ) queries must be forbidden in other words, the attacker can query PartialReveal on
addition to Partner(·, X ) queries. both s1 and s2 without compromising the freshness
of a session - which violates the 1-AKE freshness of
Forward Secrecy Our protocol clearly meets the cri­ our model.
teria for forward secrecy in Definition 5. The respon­ Nevertheless, we remark that our protocol is weak
der’s certified key, B, is the only long-term value ap­ Multiple CCA secure. Indeed, a proper security
pearing in the protocol, and B is included in a u model for our protocol with respect to MCCA lies
component of the initiator’s output. Furthermore, the in between weak MCCA and normal MCCA. See the
adversary who does not partner to X, Y or pkN may Appendix for more details.
partner to B after session completion without violat­
ing freshness.
6 Implementation and performance
Quantum resistance Our protocol is not quantum- characteristics
resistant under Definition 6, as a fully quantum ad­
versary can compute the discrete logarithm of a long-
term authentication key and use it to violate the au­
thenticity of new sessions. TAP ntor ntrutor
client → server bytes 186 84 693
Forward quantum-resistance Our protocol is forward server → client bytes 148 64 673
client computation (stage 1) 280 µs 84 µs 272 µs
quantum-resistant under Definition 7. We model
server computation 771 µs 263 µs 307 µs
cryptanalytic attacks on DH components as Partner
client computation (stage 2) 251 µs 180 µs 223 µs
queries. If an adversary uses a quantum computer to total computation time 1302 µs 527 µs 802 µs
solve the relevant CDH instances they are partner to % client 40.8% 50.1% 61.7%
X, Y , and B. This precludes them from partnering Table 1. Performance comparison of TAP, ntor, and
to pkN without violating the freshness of the session. ntrutor
By Theorem 1, since the attacker is not partner to
pkN , violating the security of ntrutor implies break­
ing the semantic security of NTRUEncrypt. Since this
is assumed to be hard even for quantum adversaries, We have implemented our protocol [18] with
the protocol is forward quantum-resistant. curve25519, ntruees439ep1 and sha256 and integrated
it into Tor-0.2.5.6-alpha [17]. This parameteriztation
Multiple Encryptions In [7], Dodis and Katz pre­ provides an estimated λ = 128 bit security level
sented the notion of CCA security of multiple en­ against both active classical adversaries and passive
cryptions. quantum adversaries.
In a multiple encryption setting, one party splits a Benchmarks comparing our instantiation’s perfor­
message into many blocks, and encrypts each block mance with that of ntor and that of the legacy Tor
using a (different) ciphersuit. The other party then handshake (TAP) are presented in Table 1. The data
decrypts those ciphertext and combines the blocks was gathered using Tor’s internal benchmarking util­
to recover the message. It is observed in [7] that al­ ity on an Intel Core i7-2640M CPU at 2.80GHz with
though individual ciphersuits are secure, combining TurboBoost disabled. RSA and Z∗p Diffie-Hellman op­
them together may leak information. In such scenar­ erations for TAP were provided by OpenSSL 1.0.1i.
ios, depending on the security level, an attacker is The elliptic curve DH operations for ntor and ntru­
given different powers. We provide more details in tor were performed by the donna c64 implementa­
the Appendix. tion of curve25519 from NaCL-20110221 [2]. The
ntruees439ep1 operations were provided by the NTRU 7. Yevgeniy Dodis and Jonathan Katz. Chosen-
reference code from Security Innovation [24] compiled ciphertext security of multiple encryption. In Joe
with SSSE3 support. Kilian, editor, TCC, volume 3378 of Lecture Notes
in Computer Science, pages 188–209. Springer, 2005.
8. Ian Goldberg, Douglas Stebila, and Berkant Us­
7 Conclusion and future work taoglu. Anonymity and one-way authentication in
key exchange protocols. Des. Codes Cryptography,
67(2):245–269, 2013.
We have presented a key exchange protocol that 9. Jeffrey Hoffstein, Jill Pipher, and Joseph H. Silver-
satisfies reasonable definitions of security, one-way man. NTRU: A ring-based public key cryptosystem.
authenticity, forward secrecy, quantum forward- In Joe Buhler, editor, ANTS, volume 1423 of Lecture
resistance. We have also demonstrated that the Notes in Computer Science, pages 267–288. Springer,
scheme is practical, and compares favorably with pro­ 1998.
tocols that are currently widely deployed. 10. David Jao and Luca De Feo. Towards quantum-
Our proposal inherits all of the security properties resistant cryptosystems from supersingular elliptic
of the original ntor protocol, but also enjoys forward curve isogenies. In Bo-Yin Yang, editor, Post-
quantum-resistance due to NTRUEncrypt. We leave Quantum Cryptography, number 7071 in Lecture
Notes in Computer Science, pages 19–34. Springer
the development of a protocol satisfying our notion
Berlin Heidelberg, January 2011.
of quantum-resistance (Definition 6), as well as the 11. Hugo Krawczyk. Cryptographic extraction and key
definition of a model in which disaster-resistance can derivation: The hkdf scheme. In Tal Rabin, editor,
be considered, to future work. While it would be rel­ CRYPTO, volume 6223 of Lecture Notes in Computer
atively straightforward to define a quantum-resistant Science, pages 631–648. Springer, 2010.
authenticated key exchange protocol using available 12. Kaoru Kurosawa and Yvo Desmedt. A new paradigm
quantum-safe authentication mechanisms, more re­ of hybrid encryption scheme. In Matthew K.
search needs to be done into making these mecha­ Franklin, editor, CRYPTO, volume 3152 of Lecture
nisms efficient before a fully quantum-resistant au­ Notes in Computer Science, pages 426–442. Springer,
thenticated key exchange protocols are practical. 2004.
13. Brian A. LaMacchia, Kristin Lauter, and Anton
Mityagin. Stronger security of authenticated key ex­
change. In Willy Susilo, Joseph K. Liu, and Yi Mu,
References
editors, ProvSec, volume 4784 of Lecture Notes in
Computer Science, pages 1–16. Springer, 2007.
1. Carlisle M. Adams, Guenther Kramer, Serge Mis­ 14. Kristin Lauter and Anton Mityagin. Security analy­
ter, and Robert J. Zuccherato. On the security of sis of kea authenticated key exchange protocol. In
key derivation functions. In Kan Zhang and Yuliang Moti Yung, Yevgeniy Dodis, Aggelos Kiayias, and
Zheng, editors, ISC, volume 3225 of Lecture Notes in Tal Malkin, editors, Public Key Cryptography, volume
Computer Science, pages 134–145. Springer, 2004. 3958 of Lecture Notes in Computer Science, pages
2. Daniel J. Bernstein, Tanja Lange, and Peter 378–394. Springer, 2006.
Schwabe. NaCL: Networking and Cryptography Li­ 15. Michele Mosca, Douglas Stebila, and Berkant Us­
brary. http://nacl.cr.yp.to/, 2011. taoglu. Quantum key distribution in the classical
3. Joppe W. Bos, Craig Costello, Michael Naehrig, and authenticated key exchange framework. In Philippe
Douglas Stebila. Post-quantum key exchange for the Gaborit, editor, Post-Quantum Cryptography - 5th
tls protocol from the ring learning with errors prob­ International Workshop, PQCrypto 2013, Limoges,
lem, August 2014. France, June 4-7, 2013. Proceedings, volume 7932 of
4. Ran Canetti and Hugo Krawczyk. Analysis of key- Lecture Notes in Computer Science, pages 136–154.
exchange protocols and their use for building secure Springer, 2013.
channels. In Birgit Pfitzmann, editor, EUROCRYPT, 16. Chris Peikert. Lattice cryptography for the internet,
volume 2045 of Lecture Notes in Computer Science, January 2014.
pages 453–474. Springer, 2001. 17. The Tor Project. Tor’s source code, 2014.
5. Whitfield Diffie and Martin E. Hellman. New direc­ 18. John Schanck, William Whyte, and Zhen­
tions in cryptography. IEEE Transactions on Infor­ fei Zhang. ntru-tor reference implementation.
mation Theory, 22(6):644–654, 1976. https://github.com/NTRUOpenSourceProject/ntru­
6. Roger Dingledine, Nick Mathewson, and Paul F. tor, 2014.
Syverson. Tor: The second-generation onion router. 19. Peter W. Shor. Algorithms for quantum computation:
In Matt Blaze, editor, USENIX Security Symposium, Discrete logarithms and factoring. In FOCS, pages
pages 303–320. USENIX, 2004. 124–134. IEEE Computer Society, 1994.
20. Peter W. Shor. Polynomial-time algorithms for prime normal setting, the adversary cannot query individ­
factorization and discrete logarithms on a quantum ual decryption oracles, i.e., he needs to submit the
computer. SIAM J. Comput., 26(5):1484–1509, 1997. query in the form of C.
21. Victor Shoup. On formal models for secure key ex­
change, November 1999. Definition 8 (Multiple CCA Security). A pro­
22. Victor Shoup. A proposal for an iso standard for pub­ tocol is weak/standard/strong Multiple CCA (w/­
lic key encryption. IACR Cryptology ePrint Archive, /sMCCA) secure if their is no adversary who can win
2001:112, 2001. the following game with a probability more than 12 +ε,
23. Martijn Stam. A Key Encapsulation Mechanism for
where ε is negligible in λ.
NTRU. In Nigel P. Smart, editor, IMA Int. Conf.,
volume 3796 of Lecture Notes in Computer Science, • For two messages M0 and M1 , the challenge ran­
pages 410–427. Springer, 2005.
domly pick b ∈ {0, 1} and encrypts Mb and obtain
24. William Whyte, Mark Etzel, and Pe­
a ciphertext C and send M1 , M2 and C to the ad­
ter Jenney. NTRUOpenSourcePro ject.
https://github.com/NTRUOpenSourceProject/ntru­ versary;
crypto, 2014. • the adversary has access to the following oracles
25. William Whyte and Jeffrey Hoffstein. NTRU. In • for any input M an encryption oracle OE
Henk C. A. van Tilborg and Sushil Jajodia, editors, generates corresponding C;
Encyclopedia of Cryptography and Security (2nd Ed.), • for any input mi an encryption oracle Oei
pages 858–861. Springer, 2011. generates corresponding ci ;
26. J. Schanck Z. Zhang, W. Whyte. Ntrutor source code, • (wMCCA) for any input C ' = C, a decryp­
July 2014. tion oracle OH returns corresponding hashed
value s' ;
A Multiple Encryption • (MCCA) the above oracles, plus for any in­
put C ' = C, a decryption oracle OD returns
To suit the definition of multiple encryption, we re­ corresponding M ' ;
write our protocol in terms of dual encryption as fol­ • (sMCCA) the above oracles, plus, for any in­
lows: put ci a decryption oracle Odi returns mi ;
• the attacker outputs b.
• KeyGen: It takes as input a security parame­
ter λ and outputs two key pairs (sk1 , pk1 ) and The adversary wins the game if he guess b correctly.
(sk2 , pk2 ), where sk1 = {x, y} and pk1 = {g};
Our protocol satisfies the requirement of wMCCA,
(sk2 , pk2 ) is a NTRUEncrypt key pair.
since our construction follows the Dodis-Katz frame­
• Encrypt: It takes as input the public key and
work for wMCCA secure multiple encryption: s1 and
a message M = (m1 , m2 ), where m1 = N U LL
s2 are transmitted via two different ciphersuits, and
and m2 = s2 it outputs C = (c1 , c2 ) where
a cryptographic hash function is applied to combine
c1 = (g x , g y ) and c2 = c.
them together.
• Decrypt: It takes as input the secret key and a
Finally, we argue that a proper model for the dual
ciphertext, it outputs s1 = g xy and s2 .
key exchange lies in between wMCCA and MCCA:
• Combine: It takes as input the m1 and m2 , it
the attacker is allowed to compromise most of the ci­
outputs a secret seed s ← H(m1 |m2 ), where H is
phersuits, but there exist at least one ciphersuit that
a cryptographic hash function.
remains secure; in the MCCA setting, this means for
For the multiple encryption, there exists three lev­ n different encryption schemes, the attacker is given
els of CCA security: the weak multiple CCA secu­ decryption oracles Oei for as many as n − 1 schemes.
rity (wMCCA), the standard multiple CCA security
(MCCA) and the strong multiple CCA security (sM-
CCA). When the attacker is challenged with an ci­
phertext C, for the first notion, there exists a oracle
such that given any C ' = C it replies with the secret
s' ; for MCCA, the oracle replies s' as well as m'1 and
m'2 ; for the strongest notion, their exist additional
oracles such that given c'i it replies with m'i . The dif­
ference between the last two notions is that in the