arX

iv:1

507.

0572

4v1

[cs.

CR

] 21

Jul

201

5

HORNET: High-speed Onion Routing at the Network Layer

Chen Chenchenche1@cmu.edu

CMU/ETH Zürich

Daniele Enrico Asonidasoni@student.ethz.ch

ETH Zürich

David Barreradavid.barrera@inf.ethz.ch

ETH Zürich

George Danezisg.danezis@ucl.ac.uk

UCL

Adrian Perrigadrian.perrig@inf.ethz.ch

ETH Zürich

ABSTRACTWe present HORNET, a system that enables high-speed end-to-endanonymous channels by leveraging next generation network archi-tectures. HORNET is designed as a low-latency onion routingsys-tem that operates at the network layer thus enabling a wide rangeof applications. Our system uses only symmetric cryptographyfor data forwarding yet requires no per-flow state on intermediatenodes. This design enables HORNET nodes to process anonymoustraffic at over 93 Gb/s. HORNET can also scale as required, addingminimal processing overhead per additional anonymous channel.We discuss design and implementation details, as well as a perfor-mance and security evaluation.

1. INTRODUCTIONRecent revelations about global-scale pervasive surveillance pro-

grams have demonstrated that the privacy of Internet users world-wide is at risk. These revelations suggest massive amounts of pri-vate data, including web browsing activities, location information,and personal communications are being harvested in bulk by do-mestic and foreign intelligence agencies. The surveillance-pronedesign of the Internet accompanied by the decreasing cost ofdatastorage have enabled mass-surveillance, through indiscriminate datacollection and storage [12, 8].

To protect against these and other surveillance threats, severalanonymity protocols, tools, and architectures have been proposed.Among the most secure schemes for anonymous communicationsare mix networks [28, 36, 20, 21], which are useful for cases wherehigh-latency asynchronous messaging can be tolerated. Onion rout-ing networks (most notably Tor [23]), offer a balance between se-curity and performance, enabling low-latency anonymous commu-nication suitable for typical Internet activities (e.g., web browsing,instant messaging, etc.). Tor is the system of choice for over 2 mil-lion daily users [13], but its design as an overlay network suffersfrom performance and scalability issues: as more clients use Tor,more relays must be added to the network. Additionally, Tor’s de-sign requires per-connection state to be maintained by intermediatenodes, limiting the total number of concurrent anonymous connec-tions that can take place simultaneously.

The scalability and performance limitations of anonymous net-works have been partially addressed by building protocols into thenetwork layer rather than implementing them as overlays. Amongthese high-performing schemes are LAP [29] and Dovetail [42],which offer network-level low-latency anonymous communicationon next-generation network architectures. The high performanceof both schemes, however, results in significantly degradedsecu-rity guarantees; endpoints can be de-anonymized if the adversary

has global data collection abilities, and payload protection relieson upper layer protocols which increases complexity.

In this paper, we present HORNET (High-speed Onion Routingat the NETwork layer), a highly-scalable anonymity system thatleverages next-generation Internet architecture design.HORNEToffers payload protection by default, and can defend against someglobal observation attacks. HORNET is designed to be highlyef-ficient: instead of keeping state at each relay, connection state (in-cluding, e.g., onion layer decryption keys) is carried within packetheaders, allowing intermediate nodes to quickly forward traffic forlarge numbers of clients.

While this paper proposes and evaluates a concrete ano-nymitysystem, a secondary goal herein is to broadly re-think the designof low-latency anonymity systems by envisioning networks whereanonymous communication is offered as an in-network service toall users. For example, what performance trade-offs exist betweenkeeping anonymous connection state at relays and carrying state inpackets? If routers perform anonymity-specific tasks, how can weensure that these operations do not impact the processing ofregu-lar network traffic, including in adversarial circumstances? And ifthe network architecture should provide some support for anony-mous communication, what should that support be? Throughoutthe paper we consider these issues in the design of our own system,and provide intuition for the requirements of other network-levelanonymity systems.

Specifically, our contributions are the following:• We design and implement HORNET, an anonymity system

that uses source-selected paths and shared keys between end-points and routers to support onion routing. Unlike otheronion routing implementations, HORNET routers do not keepper-flow state or perform computationally expensive opera-tions for data forwarding, allowing the system to scale as newclients are added.

• We analyze the security of our system, showing that it candefend against passive attacks, and certain types of activeattacks. Our system provides stronger security guaranteesthan existing network-level anonymity systems.

• We evaluate the performance of our system, showing thatanonymous data processing speed is comparable to that ofLAP and Dovetail (up to 93.5 Gb/s on a 120 Gb/s softwarerouter). Each HORNET node can process traffic for a practi-cally unlimited number of sources.

2. PROBLEM DEFINITIONWe aim to design a network level anonymity system to frustrate

adversaries with mass surveillance capabilities. Specifically, an ad-versary observing traffic traversing our system should be unable tolink (at large scale) pairs of hosts communicating over the network.

1

This property is known as end-to-end unlinkability [39].We definesender anonymityas a communication scenario where

unlinkability is guaranteed for the source, but the destination’s lo-cation is public (e.g., web sites for The Guardian or Der Spiegel).We definesender-receiver anonymityas a scenario where the un-linkability guarantee is extended to the destination (e.g., a hid-den service that wishes to conceal its location). Sender-receiveranonymity therefore offers protection for both ends, implying senderanonymity. Depending on users’ needs, HORNET can support ei-ther sender anonymity or sender-receiver anonymity.

Since our scheme operates at the network layer, network locationis the only identity feature we aim to conceal. Exposure of networklocation or user identity at upper layers (e.g., through TCPsessions,login credentials, or browser cookies) is out of scope for this work.

2.1 Network ModelWe consider that provisioning anonymous communication be-

tween end users is a principal task of the network infrastructure.The network’s anonymity-related infrastructures, primarily routers,assist end users in establishing temporaryanonymous sessionsforanonymous data transmission.

We assume that the network layer is operated by a set of nodes(e.g., ASes). Each node cooperates with sources to establish anony-mous sessions to the intended destinations, and processes anony-mous traffic within the created sessions. We require that routingstate allows each node to determine only the next hop. In particu-lar, the destination is only revealed to the last node and no others.This property can be satisfied by IP Segment Routing [10], FutureInternet Architectures (FIAs) like NIRA [46] and SCION [48], orPathlets [26].

We assume the underlying network architecture provides a mech-anism for a source to obtain a path to a destination. This pathis thecombination of routing state of all nodes between the sourceand theintended destination. Additionally, we assume that the same mech-anism allows the source to fetch the public keys and certificates1 ofon-path nodes. The source retrieves the above information anony-mously using one of two methods: 1) using unprotected queriesto retrieve the necessary information to reach a public pathlookupserver and then creating an anonymous session to the server;or 2)using any form of Private Information Retrieval (PIR), as was re-cently proposed for Tor [35]. In Section 7.1, we briefly sketch howto obtain this information anonymously in selected FIAs. While ageneral solution represents an important avenue for futurework, itremains outside of our present scope.

We assume that end hosts and on-path nodes have public keysaccessible and verifiable by all entities. End hosts can retrieve thepublic keys of other end hosts through an out-of-band channel (e.g.,websites) and verify them following a scheme like HIP [37], inwhich the end hosts can publish hashes of their public keys astheirservice names. Public keys of on-path nodes are managed througha public-key infrastructure (PKI). For example, the sourcenode canleverage Resource Public Key Infrastructure (RPKI) [16] toverifythe public keys of on-path nodes.

2.2 Threat ModelWe consider an adversary attempting to conduct mass surveil-

lance. Specifically, the adversary collects and maintains alist of“selectors” (e.g., targets’ network locations, or higher-level proto-col identifiers), which help the adversary trawl intercepted trafficand extract parts of it for more expensive targeted analysis[8]. An

1Depending on the underlying PKI scheme, the source might needto fetch a chain of certificates leading to a trusted anchor toverifyeach node’s public key.

anonymity system should provide no way for such an adversarytoleverage bulk access to communications to select traffic that be-longs to the targets. Thus an adversary will have to collect and an-alyze all traffic and cannot reliably select traffic specific to targetsunless it has access to the physical links next to the targets.

We consider an adversary that is able to compromise a fractionof nodes on the path between source and destination. For senderanonymity, the adversary can also compromise the destination. Forsender-receiver anonymity, the adversary can compromise at mostone of the two end hosts.

By compromising a node, the adversary learns all keys and set-tings, observes all traffic that traverses the compromised node, andis able to control how the nodes behave including redirecting traffic,fabricating, replaying, and modifying packets. However, like otherlow-latency schemes, we do not solve confirmation attacks basedon the analysis of flow dynamics [43, 31, 38] and active packettag-ging [40]. Resisting such attacks using dynamic link padding [45]is no more difficult than in onion routing, although equally expen-sive.

2.3 Desired PropertiesHORNET is designed to achieve the following anonymity and

security properties:1. Path information integrity and secrecy. An adversary should

not be able modify a packet header to change path withoutdetection. The adversary should not learn forwarding infor-mation of uncompromised nodes, node’s positions, or the to-tal number of hops on a path.

2. No cross-link identification. An adversary that can eaves-drop on multiple links in the network cannot correlate two ormore packets on those links by observing the bit patterns inthe packet headers or payloads.

3. Session unlinkability. An adversary cannot link packetsfrom different sessions, even between the same set of sourcesand destinations.

4. Payload secrecy and end-to-end integrity. Without com-promising end hosts, an adversary cannot learn any informa-tion from the data payload except for its length and timingamong sequences of packets.

3. HORNET OVERVIEWThe basic design objectives for HORNET arescalabilityandeffi-

ciency. To enable Internet-scale anonymous communication, HOR-NET intermediate nodes must avoid keeping per-session state (e.g.,cryptographic keys and routing information). Instead, session stateis offloaded to end hosts, who then embed this state into packetssuch that each intermediate node can extract its own state aspart ofthe packet forwarding process.

Offloading the per-session state presents two challenges. First,nodes need to prevent their offloaded state from leaking informa-tion (e.g., the session’s cryptographic keys). To address this, eachHORNET node maintains a local secret to encrypt the exportedper-session state. We call this encrypted state aForwarding Seg-ment(FS). The FS allows its creating node to dynamically retrievethe embedded information (i.e., next hop, shared key, session expi-ration time), while hiding this information from unauthorized thirdparties.

The second challenge in offloading the per-session state is tocombine this state (i.e., the FSes) in a packet in such a way that eachnode is able to retrieve its own FS, but no information is leakedabout the network location of the end hosts, the path length,or aspecific node’s position on the path. Learning any of this informa-tion could assist in de-anonymization attacks (see Section5.5). To

2

address this challenge, the source constructs ananonymous header(AHDR) by combining multiple FSes, and prepends this header toeach packet in the session. AnAHDR grants each node on thepath access to the FS it created, without divulging any informa-tion about the path except for a node’s previous and next nodes(see Section 4.4.1).

For efficient packet processing, each HORNET node performsone Diffie-Hellman (DH) key exchange operation once per sessionduring setup. For all data packets within the session, HORNETnodes use only symmetric cryptography to retrieve their state, pro-cess theAHDR and onion-decrypt (or encrypt) the payload. To re-duce setup delay, HORNET uses only two setup packets within asingle round trip between the source and the destination. Therefore,session setup only incursO(n) propagation delay in comparison toO(n2) by the iterative method used in Tor (wheren is the numberof anonymity nodes traversed on the path). While for Tor the de-fault value ofn is 3, for HORNETn might be as large as 14 (and4.1 in the average case [7]), which emphasizes the need to optimizesetup propagation delay in our protocol.

3.1 Sender AnonymityAnonymous sessions between a source and destination require

the source to establish state between itself and every node on thepath. The state will be carried in subsequent data packets, enablingintermediate nodes to retrieve their corresponding state and forwardthe packet to the next hop. We now describe how the state is col-lected without compromising the sender’s anonymity, and how thisstate is used to forward data packets.Setup Phase.To establish an anonymous session between a sourceS and a public destinationD, S uses a single round of Sphinx [21],a provably secure onion routing protocol (an overview of Sphinx isgiven in Section 4.3.1). This round consists of two Sphinx packets(one for the forward path and one for the backward path) each ofwhich will anonymously establish shared symmetric keys betweenS and every node on that path. For HORNET, we extend the Sphinxprotocol to additionally anonymously collect the forwarding seg-ments (FSes) for each node. Our modified Sphinx protocol protectsthe secrecy and integrity of these FSes, and does not reveal topol-ogy information to any node on the path. We note that using Sphinxalone for data forwarding would result in low throughput duetoprohibitively expensive per-hop asymmetric cryptographic opera-tions. Therefore, we use Sphinx only for session setup packets,which are amortized over the subsequent data transmission pack-ets. We explain the details of the setup phase in Section 4.3.Data Transmission Phase.Having collected the FSes, the sourceis now able to construct a forwardAHDR and a backwardAHDR

for the forward and backward paths, respectively.AHDRs carry theFSes which contain all state necessary for nodes to process andforward packets to the next hop. When sending a data packet, thesource onion-encrypts the data payload using the session’ssharedsymmetric keys, and prepends theAHDR. Each node then retrievesits FS from theAHDR, onion-decrypts the packet and forwards it tothe next hop, until it reaches the destination. The destination usesthe backwardAHDR (received in the first data packet2) to send databack toS, with the only difference being that the payload is en-crypted (rather than decrypted) at each hop. We present the detailsof the data transmission phase in Section 4.4.

3.2 Sender-Receiver AnonymitySender-receiver anonymity, where neitherS nor D know each

other’s location (e.g., a hidden service), presents a new challenge:

2If the first packet is lost the source can simply resends the back-wardAHDR using a new data packet (see Section 4.4).

sinceS does not knowD’s location (and vice versa),S cannotretrieve a path toD, precluding the establishment of state betweenS and nodes on the path toD as described in Section 3.1.

A common approach to this problem (as used by Tor, LAP, andDovetail) is for the destination to advertise a path (or similar) backto itself through a known, publicrendezvous point(RP). Sourcesestablish anonymous sessions to the RP, who in turn forwardstrafficto the destination while keepingS andD’s location hidden fromeach other. This solution would also work for HORNET. However,it requires the RP to maintain per-session state between sources anddestinations, which increases complexity, bounds the number ofreceivers, and introduces a state exhaustion denial of service attackvector.Nested a-headers.Our proposal for sender-receiver anony-mityrequires no state to be kept at the RP by nesting theAHDRs fromthe source to the rendezvous and from the rendezvous to the desti-nation. Briefly, to establish a HORNET session betweenS andDkeeping both parties hidden from each other,D selects a public ren-dezvous pointR and completes a HORNET session setup betweenD andR. D publishesAHDRR→D to a public directory. Note thatthis AHDR leaks no information aboutD’s location and can only beused to send data toD throughR within a specific time window.

WhenS wants to send traffic toD, S retrieves (from a publicdirectory)AHDRR→D. S then establishes a HORNET session be-tweenS andR and constructs a nestedAHDR with AHDRR→D

inside AHDRS→R. S includesAHDRR→S in the data payload toD, allowingD to create a return path toS.

One of the advantages of our scheme is that any node on the net-work can serve as a rendezvous point. In fact, multiple points canbe selected and advertised, allowing the source to pick the RP clos-est to it. Moreover, once a HORNET session has been established,S andD can negotiate a better (closer) RP (e.g., using private setintersection [25]). A disadvantage of the nestedAHDR technique isthat it doubles the size of the header.

For space reasons, the formal protocol details and evaluation sec-tions focus on sender anonymity only. Details of sender-receiveranonymity can be found in the full paper [5].

3.3 Packet StructureHORNET uses two types of packets:setup packetsand data

packets(see Figure 1). Both types of packets begin with a commonheader which describes the packet type, the length of the longestpath that the session supports, and a type-specific field. Forses-sion setup packets, the type-specific field contains a valueEXPwhich indicates the intended expiration time of the session. Fordata packets, the specific value is a random nonce generated by thesender used by intermediate nodes to process the data packet.

Session setup packets include a nested Sphinx packet and an FSpayload. Data packets carry anAHDR and an onion-encrypted datapayload. We explain each field in detail in Section 4.

4. FORMAL PROTOCOL DESCRIPTIONWe now describe the details of our protocol, focusing on sender

anonymity. We first list the information required by the source tostart an anonymous communication (Section 4.2), and then presentthe specification of the setup phase (Section 4.3) and of the datatransmission phase (Section 4.4).

4.1 NotationLet k be the security parameter used in the protocol. For evalua-

tion purposes we considerk= 128.G is a prime order cyclic groupof orderq (q ∼ 22k), which satisfies the Decisional Diffie-HellmanAssumption.G∗ is the set of non-identity elements inG andg is a

3

HORNET Session Setup Packet

hopstype

HORNET Data Packet

hopstype

Sphinx Header

Sphinx Payload

FS Payload

AHDR

Data Payload

nonceEXP

Figure 1: HORNET packet formats.

generator ofG.Let r be the maximum length of a path, i.e., the maximum num-

ber of nodes on a path, including the destination. We denote thelength of an FS aslFS and the size of anAHDR block, containingan FS and a MAC of sizek, asc= lFS +k.

HORNET uses the following cryptographic primitives:• MAC : {0,1}k×{0,1}∗→{0,1}k : Message Authentication Code

(MAC) function.• PRG0,PRG1 : {0,1}k→{0,1}r(c+k); PRG2 : {0,1}k→{0,1}rc :

Three cryptographic pseudo-random generators.• PRP : {0,1}k ×{0,1}a →{0,1}a : A pseudo-random permuta-

tion, implementable as a block cipher. The value ofa will beclear from the context.

• ENC : {0,1}k × {0,1}k × {0,1}mk → {0,1}mk : Encryptionfunction, with the second parameter being the Initialization Vec-tor (IV) (e.g., Stream cipher in counter mode).m is a variableinteger parameter.

• DEC : {0,1}k × {0,1}k × {0,1}mk → {0,1}mk : Decryptionfunction to reverseENC.

• hop : G∗ → {0,1}k : a family of hash functions used to keyop,with op ∈ {MAC,PRG0,PRG1,PRP,ENC,DEC}.

We denote byRAND(l) a function that generates a new uniformlyrandom string of lengthl.

Furthermore, we define the notation for bit strings. 0l stands fora string of zeros of lengthl. |x| is the length of the bit stringx.x[a...b] represents a substring ofx from bit a to bit b, with sub-indexa starting from 0;x[a...end] indicates the substring ofx frombit s till the end.ε is the empty string.x‖y is the concatenation ofstringx and stringy.

In the following protocol description, we consider a sourceScommunicating with a destinationD using forward pathpf travers-ingnf0 ,n

f1 , . . . ,n

f

lf−1 and backward pathpb traversingnb0,nb1, . . . ,n

blb−1,

with lf , lb ≤ r, wherenf0 andnblb−1 are the nodes closest to the

source. Without loss of generality, we let the last node on the for-ward pathnf

lf−1 = D and refer to the destination by these twonotations interchangeably. In general we usedir ∈ {f,b} as super-scripts to distinguish between notation referring to the forward andbackward path, respectively. Finally, to avoid redundancy, we use{symdir

i } to denote{symdiri |0≤ i ≤ l

dir −1}, wheresym canbe any symbol.

4.2 InitializationSuppose that a sourceS wishes to establish an anonymous ses-

sion with a public destinationD. First, S anonymously obtains(from the underlying network) paths in both directions: a forwardpathpf = {Rf

0 ,Rf1 , · · · ,R

f

lf−1} and a backward pathpb= {Rb0,R

b1, · · · ,R

f

lb−1}.

Rdiri denotes the routing information needed by the nodendiri to

forward a packet.S also anonymously retrieves and verifies a set ofpublic keysg

xndiri for the nodendiri on pathpdir (see Section 2.1).

Note thatgxD is also included in the above set (asnflf−1 = D).

Finally, S generates a random DH key pair for the session:xSandgxS . The per-session public keygxS is used by the source tocreate shared symmetric keys with nodes on the paths later inthe

setup phase.S locally stores{

(xS ,gxS ) ,

{

gxndiri

}

,pdir}

, and

uses these values for the setup phase.

4.3 Setup PhaseAs discussed in Section 3, in the setup phase, HORNET uses

two Sphinx packets, which we denote byP➊ andP➋, to traverseall nodes on both forward and backward paths and establish per-session state with every intermediate node, without revealing S’snetwork location. ForS to collect the generated per-session statefrom each node, both Sphinx packets contain an empty FS payloadinto which each intermediate node can insert its FS, but is not ableto learn anything about, or modify, previously inserted FSes.

4.3.1 Sphinx OverviewSphinx [21] is a provably-secure onion routing protocol. Each

Sphinx packet allows a source node to establish a set of symmet-ric keys, one for each node on the path through which packets arerouted. These keys enable each node to check the header’s in-tegrity, onion-decrypt the data payload, and retrieve the informa-tion to route the packet. Processing Sphinx packets involves ex-pensive asymmetric cryptographic operations, thus Sphinxalone isnot suitable to support high speed anonymous communication.

Sphinx Packets.A Sphinx packet is composed of a Sphinx headerSHDR and a Sphinx payloadSP. The SHDR contains a group ele-mentyidir that is re-randomized at each hop. Eachyidir is usedasS’s ephemeral public key in a DH key exchange with nodendiri .From this DH exchange nodendiri derives a shared symmetric keysndir

i, which it uses to process the rest of theSHDR and mutate

theyidir. The rest of theSHDR is an onion-encrypted data struc-ture, with each layer containing the routing information todecidethe next node to forward the packet and a per-hop MAC to pro-tect the header’s integrity. The Sphinx payloadSPallows end hoststo send confidential content to each other. Each intermediate nodeprocessesSPby using a pseudo-random permutation.

Sphinx Core Functions.We abstract the Sphinx protocol into thefollowing six functions:• GEN_SPHX_HDR. The source nodes uses this function to gen-

erate two Sphinx headers,SHDRf and SHDRb, for the forwardand backward path, respectively. It also outputs a series ofDHpublic-private key pairs

{(

xidir,yi

dir)}

(ephemeral keys of thesource), and the symmetric keys{sndir

i}, each established with

the corresponding node’s public keygxndiri .

• GEN_SPHX_PL_SEND. The function allows the source to gener-ate an onion-encrypted payloadSPf encapsulating confidentialdata to send to the destination.

• UNWRAP_SPHX_PL_SEND. The function removes the last en-cryption layer added byGEN_SPHX_PL_SEND, and allows thedestination to decrypt theSPf .

• GEN_SPHX_PL_RECV. The function enables the destination tocryptographically wrap a data payload intoSPb before sending itto the source.

• UNWRAP_SPHX_PL_RECV. The function allows the source torecover the plaintext of the payload that the destination sent.

4

• PROC_SPHX_PKT. Intermediate nodes use this function to pro-cess a Sphinx packet, and establish symmetric keys shared withthe source. The function takes as inputs the packet(SHDR,SP),and the node’s DH public keyg

xndiri . The function outputs the

processed Sphinx packet(SHDR′,SP′) and the established sym-metric keysndir

i.

4.3.2 Forwarding SegmentWe extend Sphinx to allow each node to create an FS and add it

to the FS payload. An FS contains a node’s per-session state,whichconsists of a secret keys shared with the source, a routing segmentR, and the session’s expiration timeEXP. To protect these contents,the FS is encrypted with a PRP keyed by a secret valueSV knownonly by the node that creates the FS. A node seals and unseals itsstate using two opposite functions:FS_CREATEandFS_OPEN. Weintroduce only the form ofFS_CREATEas follows:

FS = PRP(hPRP(SV );{s‖R‖EXP}) (1)

4.3.3 FS PayloadAt the end of each HORNET setup packet is a data structure

we call FS payload (see Figure 1). The FS payload is an onion-encrypted construction that allows intermediate nodes to add theirFSes as onion-layers.

Processing the FS payload leaks no information about the path’slength or about an intermediate node’s position on the path.AllFS payloads are padded to a fixed length, which is kept constantby dropping the right number of trailing bits of the FS payloadbefore an FS is added to the front. Moreover, new FSes are alwaysadded to the beginning of the FS payload, eliminating the need forintermediate nodes to know their positions in order to process FSpayloads.

An FS payload also provides both secrecy and integrity for theFSes it contains. Each node re-encrypts the FS payload afterin-serting a new FS and computes a MAC over the resulting structure.Only the source, with symmetric keys shared with each node onapath, can retrieve all the FSes from the FS payload and verifytheirintegrity.

Functions. There are three core functions for the FS payload:INIT _FS_PAYLOAD, ADD_FS, andRETRIEVE_FSES.

INIT _FS_PAYLOAD. A node initializes a FS payload by using apseudo-random generator keyed with a symmetric keys to gener-atesrd random bits:

PFS = PRG1(hPRG1(s))[0...rd−1] (2)whered is the size of a basic block of the FS payload (cf. Line 2 inAlgorithm 2).

ADD_FS. Each intermediate node usesADD_FS to insert its FSand other meta-dataMD into the payload, as shown in Algorithm 1.First, the trailingd bits of the current FS payload, which are paddingbits containing no information about previously added FSes, aredropped, and then the FS andMD are prepended to the shortenedFS payload. The result is encrypted using a stream cipher (Line 3)and MACed (Line 5). Note that no node-position information is re-quired inADD_FS, and verifying that the length of the FS payloadremains unchanged is straight-forward.

RETRIEVE_FSES. The source uses this function to recover allFSes{FSi} and MDs {MDi} inserted into an FS payloadPFS .RETRIEVE_FSESstarts by recomputing the discarded trailing bits(Line 4) and obtaining a complete payloadPfull. Afterwards, thesource retrieves the FSes andMDs fromPfull in the reverse orderin which they were added byADD_FS (see lines 7 and 10).

4.3.4 Setup Phase Protocol Description

Algorithm 1 Adding FS into FS payload.1: procedure ADD_FS

Input: s, FS , MD, Pin

Output:Pout

2: d← |FS|+ |MD|+k

3: Ptmp←{

FS ‖MD ‖Pin [d..(r−1)d]

}

⊕PRG0(hPRG0(s))[k..end]4: α←MAC(hMAC(s);Ptmp)5: Pout← α‖Ptmp

6: end procedure

Algorithm 2 Retrieve FSes from FS payload

1: procedure RETRIEVE_FSES

Input: PFS , s, {si}Output:{FSi}, MDi

2: d← lFS + |MD|+k3: Pinit← INIT _FS_PAYLOAD(s)4: ψ← Pinit [(r−l)d..rd−1]

⊕PRG0(hPRG0(s0))[(r−l+1)d..end] ‖0d

⊕PRG0(hPRG0(s1))[(r−l+2)d..end] ‖02d

· · ·⊕PRG0(hPRG0(sl−2))[(r−1)d..end] ‖0(l−1)d

5: Pfull = PFS ‖ψ6: for i← (l−1), . . . ,0 do7: checkPfull [0..k−1] =

MAC(hMAC(si);Pfull [k..rd−1])

8: Pfull← Pfull⊕ (PRG0(hPRG0(si))‖0(i+1)d)9: FS i← Pfull [k..k+lFS−1]

10: MDi← Pfull [k+lFS..d−1]11:12: Pfull← Pfull [d..end]

13: end for14: end procedure

Source Processing.With the input

I ={

(xS ,gxS ) ,

{

gxndiri

}

,pdir}

the source nodeS bootstraps a session setup in 5 steps:1. S selects the intended expiration timeEXP for the session and

specifies it in the common headerCHDR.2. S generates the send and the reply Sphinx headers by:

{SHDRf ,SHDRb}= GEN_SPHX_HDR(I,CHDR) (3)The common headerCHDR (see Figure 1) is passed to the func-tion to extend the per-hop integrity protection of Sphinx overit. GEN_SPHX_HDR also produces a series of keys: symmetrickeys shared with each node on both paths{sndir

i}, and the DH

key pairs{(xdiri ,ydiri )}.3. In order to enable the destinationD to reply,S places the reply

Sphinx headerSHDRb into the Sphinx payload:SP= GEN_SPHX_PL_SEND({s

nfi

},SHDRb) (4)

4. S creates an initial FS payloadPFS = INIT _FS_PAYLOAD(xS).5. S composesP➊ = {CHDR‖SHDRf ‖SP‖PFS} and sends it to

the first node on the forward pathnf0 .

Intermediate Node Processing.An intermediate nodenfi receiv-ing a packetP➊ = {CHDR‖ SHDRf ‖ SP‖PFS} processes it asfollows:1. nfi first processesSHDRf andSP in P➊ according to the Sphinx

5

protocol (usingPROC_SPHX_PKT). As a resultnfi obtains the

processed header and payload(SHDRf′,SP′) as well as the rout-

ing informationRfi , S’s DH public keyyfi , and the established

symmetric keysnfi

shared withS. During this processing the

integrity of theCHDR is verified.

2. nfi obtainsEXP from CHDR and checks thatEXP is not expired.

nfi also verifies thatRf

i is valid.3. To provide forward secrecy, the shared keys

nfi

is not used for

the data transmission phase, sincesnfi

depends onnfi ’s long-

term DH key. Instead,nfi generates an ephemeral DH key pair

(x′nfi

,y′nfi

) and derivessfi by

sfi = (yfi )

x′nfi (5)

This is the symmetric key that is included innfi ’s FS and usedduring the data transmission phase.

4. nfi generates its FSFSfi by using its local symmetric keySVi

to encryptsfi ,Rfi , andEXP:

FSfi = FS_CREATE(SVi,{s

fi ‖R

fi ‖EXP}) (6)

5. nfi adds itsFSfi andMD = y′

nfi

into the FS payloadPFS .

PFS′ = ADD_FS(s

nfi

,FSfi ,y

′nfi

,PFS) (7)

Adding y′nfi

as the meta-data into the FS payload allowsS to

later retrievey′nfi

and derive the symmetric keysfi shared with

nfi for the session. The MAC computed usings

nfi

shared be-

tweenS andnfi (Line 5 in Algorithm 1) allowsS to authenticatethe DH public keyy′

nfi

.

6. Finally nodenfi assembles the processed packetP➊= {CHDR‖

SHDRf′‖ SP′ ‖PFS

′} and routes it to the next node accordingto the routing informationRf

i .

Destination Processing.As the last node on the forward path,DprocessesP➊ in the same way as the previous nodes: it processesthe Sphinx packet inP➊ and derives a symmetric keysD sharedwith S; it generates a new DH key pair(x′D,y

′D) and derives a

second shared keys′D; it encrypts per-session state includings′DintoFSD and insertsFSD into the FS payload.

After these operations, however,D moves on to create the sec-ond setupP➋ as follows:1. D retrieves the Sphinx reply header using the symmetric keysD:

SHDRb = UNWRAP_SPHX_PL_SEND(sD,SP) (8)2. D places the FS payloadPFS of P➊ into the Sphinx payload

SPb of P➋ (this will allow S to get the FSes{FSfi }):

SPb = GEN_SPHX_PL_RECV(sD,PFS) (9)Note that sinceD has no knowledge about the keys{sfi } exceptfor sD,D learns nothing about the other FSes in the FS payload.

3. D creates a new FS payloadPFSb = INIT _FS_PAYLOAD(sD)

to collect the FSes along the backward path.4. D composesP➋ = {CHDR‖ SHDRb ‖ SPb ‖PFS

b} and sends itto the first node on the backward path,nb0.The nodes on the backward path processP➋ in the exact same

way nodes on the forward path processedP➊. FinallyP➋ reachesthe sourceS with FSes{FS b

i} added to the FS payload.

Post-setup Processing.OnceS receivesP➋ it extracts all FSes,i.e.,{FSf

i } and{FS bi}, as follows:

1. S recovers the FS payload for the forward pathPFSf from SPb:

PFSf = UNWRAP_SPHX_PL_RECV({sbi},SPb) (10)

2. S retrieves the FSes for the nodes on the forward path{FS fi }:

{FS fi }= RETRIEVE_FSES({sfi },PFS

f ) (11)

3. S directly extracts fromPFSbthe FSes for the nodes on the

backward path{FS bi}:

{FS bi}= RETRIEVE_FSES({sbi},PFS

b) (12)

With the FSes for all nodes on both paths,{

FSfi

}

and{

FSbi

}

,S is ready to start the data transmission phase.

4.4 Data Transmission PhaseEach HORNET data packet contains an anonymous headerAHDR

and an onion-encrypted payloadO as shown in Figure 1. Figure 2demonstrates the details of anAHDR. TheAHDR allows each inter-mediate node along the path to retrieve its per-session state in theform of an FS and process the onion-encrypted data payload. Allprocessing of data packets in HORNET only involves symmetric-key cryptography, therefore supporting fast packet processing.

RS

0 8

Shared Key

16

EXP

Forwarding Segment (FS)0

FS

Anonymous Header

48*hops

Blinded FSes

Onion Encrypted

MAC48

32

Encrypted

Figure 2: Format of a HORNET anonymous header with de-tails of a forwarding segment (FS).

At the beginning of the data transmission phase,S creates twoAHDRs, one for the forward path (AHDRf ) and one for the back-ward path (AHDRb), by using FSes collected during the setup phase.AHDRf enablesS to send data payloads toD. To enableD to trans-mit data payloads back,S sendsAHDRb as payload in the first datapacket. If this packet is lost, the source would notice from the factthat no reply is seen from the destination. If this happens the sourcesimply resends the backwardAHDR using a new data packet.

4.4.1 Anonymous HeaderLike an FS payload, anAHDR is an onion-encrypted data struc-

ture that contains FSes. It also offers similar guarantees,i.e., se-crecy and integrity, for the individual FSes it contains, for theirnumber and for their order. Its functionalities, on the other hand,are the inverse: while the FS payload allows the source to collectthe FSes added by intermediate nodes, theAHDR enables the sourceto re-distribute the FSes back to the nodes for each transmitted datapacket.

Functions.The life cycle ofAHDRs involves two functions:GET_FS

andCREATE_AHDR. GET_FS allows each intermediate node to re-trieve its FS from the inputAHDR and compute theAHDR for thenext hop (see Algorithm 3).CREATE_AHDR enablesS to createtwo AHDRs, AHDRf andAHDRb (see Algorithm 4).

4.4.2 Onion PayloadHORNET data payloads are protected by onion encryption. To

send a data payload to the destination, the source adds a sequenceof encryption layers on top of the data payload, one for each nodeon the forward path (including the destination). As the packet isforwarded, each node removes one layer of encryption, untilthedestination removes the last layer and obtains the originalplaintext.

6

Algorithm 3 ObtainFS from AHDR

1: procedure GET_FS

Input: SV , AHDR

Output:FS, AHDR

2: {FS ‖γ ‖β} ← AHDR

3: s← FS_OPEN(FS ,SV )[0..k]4: checkγ =MAC(hMAC(s);β ‖0c)5: β′← {β ‖0c}⊕PRG2(hPRG2(s))[0...rc]6: AHDR← β′

7: end procedure

Algorithm 4 Anonymous header construction1: procedure CREATE_AHDR

Input: {si}, {FSi}Output:(FS0,γ0,β0)

2: φ0← ε3: for i← 1, · · · , l−1 do4: φi← (φi−1 ‖0c)

⊕{

PRG2(hPRG2(si−1))[(r−i)c..rc]

}

5: end for6: βl←

{

RAND(c(r− l))‖φl−1}

7: for i← (l−1), . . . ,0 do

8: βi←{

FS i+1 ‖γi+1 ‖βi+1[0..c(r−1)−1]

}

⊕PRG2(hPRG2(si))9: γi←MAC(hMAC(si);FS i ‖βi)

10: end for11: end procedure

To send a data payload back to the source, the destination addsonly one layer of encryption with its symmetric key shared withthe source. As the packet is forwarded, each node on the backwardpath re-encrypts the payload until it reaches the source. With allthe symmetric keys shared with nodes on the backward path, thesource is capable of removing all encryption layers, thus obtainingthe original data payload sent by the destination.

Functions.Processing onion payloads requires two functions:ADD_LAYER

andREMOVE_LAYER.ADD_LAYER. The function’s full form is:

{O′,IV ′}= ADD_LAYER(s,IV,O) (13)Given a symmetric keys, an initial vectorIV , and an input onionpayloadO, ADD_LAYER performs two tasks. First,ADD_LAYER

encryptsO with s andIV :O′ = ENC(hENC(s);IV ;O) (14)

Then,ADD_LAYER mutates theIV for next node:IV ′ = PRP(hPRP;IV ) (15)

REMOVE_LAYER. The function is the inverse ofADD_LAYER.Without going into details, we only list its full form below:

{O′,IV ′}= REMOVE_LAYER(s,IV,O) (16)

4.4.3 Initializing Data TransmissionTo start the data transmission session,S generatesAHDRf and

AHDRb as follows:AHDRf = CREATE_AHDR({sfi },{FS

fi }) (17)

AHDRb = CREATE_AHDR({sbi},{FSbi}) (18)

S then sendsAHDRb toD as payload of the first data packet (whichusesAHDRf ), as specified in the following section.

4.4.4 Data Transmission Protocol Description

Source Processing.With the forwardAHDR (AHDRf ), the source

S can send a data payloadP with the following steps:1. S ensures that the session is not expired by checking that the

current timetcurr < EXP.

2. S creates an initial vectorIV . With {sfi }, sD, andIV , S onionencrypts the data payloadP .

{Olf ,IVlf }= ADD_LAYER(sD,IV,P ) (19){Oi,IVi}= ADD_LAYER(sD,IVi+1,Oi+1) i← (lf −1)..0

(20)3. S placesIV0 in the common headerCHDR.4. S sends out the resulting data packet{CHDR,AHDRf ,O0}.

Processing by Intermediate Nodes.Each intermediate nodenfion the forward path processes a received data packet{CHDR,AHDRf ,O}

with its local secret keySV fi as follows:

1. nfi retrieves its FSFSfi from AHDRf :

{FSfi ,AHDRf ′}= GET_FS(SV f

i ,AHDRf ) (21)

2. nfi extracts its per-session state, i.e., the symmetric keysfi shared

with S, the routing informationRfi , and the session’s expiration

time EXP, by decrypting FS withSV fi (cf. with Equation 1):

{sfi ,Rfi ,EXP}= PRP−1(hPRP(SV

fi );FSf

i ) (22)

3. nfi checks the session is not expired by verifying that the currenttime tcurr < EXP.

4. nfi obtainsIV from CHDR and removes one layer of encryptionfrom the data payload:

{O′,IV ′}= REMOVE_LAYER(sfi ,IV,O) (23)

5. nfi updates the IV field inCHDR with IV ′.

6. nfi sends the resulting packet{CHDR′,AHDRf ′,O′} to the next

node according toRfi .

The above procedures show that the intermediate node process-ing requires only symmetric-cryptography operations.

Destination Processing.D processes incoming data packets asthe intermediate nodes. Additionally, for the first data packet DretrievesAHDRb from the payload, and stores the{sD ,Rb

0,AHDRb}

locally so thatD can retrieveAHDRb when it wishes to send packetsback toS.

Processing for the Backward Path. Sending and processing aHORNET packet along the backward path is the same as that forthe forward path, with the exception of processing involving thedata payload. BecauseD does not possess the symmetric keysthat each node on the backward path shares withS, D cannotonion-encrypt its payload. Accordingly, intermediate nodes useADD_LAYER instead ofREMOVE_LAYER to process the data pay-load, and the source node recovers the data byREMOVE_LAYER.

4.5 Nested Anonymous Header ConstructionAs discussed in Section 3.2, the main difference of the protocols

between sender anonymity and sender-receiver anonymity isthatthe latter requires nestedAHDRs. We present in detail the processof composing anAHDR with a nestedAHDR in Algorithm 5.

Constructing a newAHDR based on a nestedAHDR A has es-sentially the same procedures as constructing a normalAHDR fromASes, except for the initialization process and the size of the re-sulted AHDR. For the AHDR initialization in Line 10 in Algo-rithm 5, the nestedAHDR A is perpended to the random bits gener-ated. Thus, when the last nodendirl (RP) decrypts theAHDR,A isrevealed to the node. For the size of the resultedAHDR, instead ofrfor a normalAHDR, the length of the generatedAHDR with a nestedAHDR is 2r, doubling the bandwidth cost incurred by the protocolheaders.

7

Algorithm 5 Creating anAHDR with a nestedAHDR.1: procedure CREATE_PADDING_STRING_NESTED

Input: {si}, rOutput:φl−1

2: φ0← ε3: for 0< i < l do4: φi← (φi−1 ‖0c)⊕

5:{

PRG0(hPRG0(si−1))[(2r−i)c..2rc]

}

6: end for7: end procedure8: procedure CREATE_ANONYMOUS_HEADER_NESTED

Input: {si}, {FSi},AOutput: (FS0,γ0,β0)

9: φl−1← CREATE_PADDING_STRING_NESTED({si})10: βl−1←

{

{A‖RAND(c(r− l))}

⊕PRG0(hPRG0(sl−1))[0..c(2r−l)−1]}

‖φl−111: γl−1←MAC(hMAC(sl−1);FS l−1 ‖βl−1)12: for i← (l−2), . . . ,0 do

13: βi←{

FS i+1 ‖γi+1 ‖βi+1[0..c(2r−1)−1]

}

⊕PRG0(hPRG0(si))[0..c(2r−l)−1]14: γi←MAC(hMAC(si);FS i ‖βi)15: end for16: end procedure

5. SECURITY ANALYSISIn this section, we first presents formal proofs showing thatHOR-

NET satisfies the correctness, security, and integrity properties de-fined by Camenisch and Lysyanskaya [17]. Then, we describeshow HORNET defends against well-known de-anonymization at-tacks, where an adversary actively or passively attempts torevealthe sender’s (and/or the receiver’s) network location. We also presentdefenses against denial of service attacks.

5.1 Formal Proof of Security for HORNET DataTransmission Phase

We prove HORNET’s data transmission phase realizes ideal onionrouting functionalities in the Universal Composability (UC) frame-work [18]. Conceptually, with an ideal onion routing protocol, ad-versaries have no access to the routing information or the messagewithin packets except for opaque identifiers that vary across links.

As demonstrated by Camenisch and Lysyanskaya [17], to provethat a protocol conforms to an ideal onion routing model, it is suf-ficient to show that the protocol provides four properties:correct-ness, integrity, wrap-resistance, andsecurity.3

5.1.1 CorrectnessProving the correctness property requires that HORNET proto-

col functions correctly in the absence of adversaries. A scrutiny ofprotocol description in Section 4 should suffice.

5.1.2 IntegrityTo prove the integrity property, we need to prove that an adver-

sary cannot forge a message that can traverse more thanN uncom-promised nodes, whereQ is a fixed upper bound for HORNET.Equivalently, we demonstrate that the adversary, with significantlyless than 2k computation, can only produce a requisite messagewith a negligible probability. In our proof, we chooseQ = r+1.

Suppose that an adversary can constructs an HORNETAHDR

(FS0,γ0,β0) that can succeed in traversingr+1 honest nodesn0,

3See definitions by Camenisch and Lysyanskaya [17].

n2, · · · , nr, without knowing secretsSV0, · · · , SVr. According toAlgorithm 4,FSr, βr, andγr satisfy:γr =MAC(hMAC(PRP−1(hPRP (SVr);FSr)[0..c]);βr) (24)

For convenience, fori ≤ j ≤ r−1, we introduce the followingnotations:

φ(SV,FS) = PRP−1(hPRP (SV ) ;FS) (25)

ρ(SV,FS) = PRG(hPRG (φ(SV,FS))) (26)

ρi = ρ(SVi,FS∗i ) (27)

ρFSi = {ρi}[c(r−1−i)..c(r−1−i)+lFS−1] (28)

ργi = {ρi}[c(r−1−i)+lFS ..c(r−i)−1] (29)

ρβi = {ρi}[0..c(i+1)−1] ||0

c(r−1−i) (30)

ρci,j = {ρi}[jc..(j+1)c−1] (31)whereFS∗i are defined recursively as follows:

FS∗0 = FS0 (32)

FS∗i = FSi⊕i−1⊕

j=0

{ρi}[c(j+i−1)..c(j+i−1)+lFS−1] (33)

We observe thatFS∗i is a function of{FSj | ∀0 ≤ j ≤ i} and

{SVj | ∀0 ≤ j ≤ i− 1}. Accordingly, ρFSi , ργi , andρβi are all

functions of{FSj | ∀0≤ j ≤ i} and{SVj | ∀0≤ j ≤ i−1}.With a detailed inspection into Algorithm 4, we can express

FSr, βr, andγr:

FSr =r−1⊕

i=0

ρFSi (34)

γr =r−1⊕

i=0

ργi (35)

βr =r−1⊕

i=0

ρβi (36)

(37)With Equation 34, 35, 36 and 24, we can prove the following

lemma:LEMMA 1. With less than2k work, an adversary can only dis-

tinguishMAC(hMAC (φ(SVr,FSr)[0..c]);βr) from a random or-acle with negligible probability.

Proof. (Sketch) We will show that an adversary could not find twosets of

(SV0, · · · ,SVr,FS0 · · · ,FSr−1) 6= (SV ′0, · · · ,SV′r,FS′0 · · · ,FS

r′−1)

that leads to the same value ofMAC(hMAC (φ(SVr,FSr)[0..c]);βr)

with significant less than 2k work.Assume that the adversary, with much less than 2k work, finds

two sets,(SV0, · · · ,SVr,FS0 · · · ,FSr) 6= (SV ′0, · · · ,SV

′r ,FS

′0 · · · ,FS

′r)

that results in the same value ofMAC(hMAC (φ(SVr,FSr)[0..c]);βr)

We will show the assumption leads to an contradiction.BecauseMAC is a random oracle, the only way for an attacker

to distinguish the target function from a random oracle withmuchless than 2k work is to ensure

φ(SVr,FSr)[0..c] = φ(SV ′r,FS′r)[0..c]

andβr = β′r. BecausePRP is a pseudo-random permutation andhPRP is collision resistant, we haveSVr = SV ′r.

Note that the lastc bits ofβr andβ′r areρcr−1,r−1 andρcr−1,r−1′

respectively. Therefore, we haveρcr−1,r−1= ρcr−1,r−1

′. Accordingto Equation 31, becausePRG is a pseudo-random generator, wehaveSVr−1 = SVr−1 andFS∗r−1 = FS∗r−1

′. Hence,ρcr−1,j =

ρcr−1,j′, ∀0≤ j ≤ r−1.

8

A careful calculation shows that thec bits before the lastc bitsin βr andβ′r areρcr−2,r−2⊕ρ

cr−1,r−2 andρcr−2,r−2

′⊕ρcr−1,r−2′.

Similarly, we haveSVr−2 = SVr−2′ andFS∗r−2 = FS∗r−2

′.Continuing the logic in the way above, we finally haveSVi =

SV ′i andFS∗i = FS∗i′, ∀0 ≤ i ≤ r− 1. However, given Equa-

tion 33, SVi = SV ′i , and FS∗0 = FS∗0′, we haveFSi = FS′i,

∀0≤ i≤ r−1. That says,

(SV0, · · · ,SVr,FS0 · · · ,FSr−1) = (SV ′0, · · · ,SV′r,FS′0 · · · ,FS

r′−1)

. Therefore, we obtain a contradiction.We can substitute Equation 34, 35, and 36 into Equation 24, and

rewrite the equation into:

ργ0 =MAC(hMAC (φ(SVr,FSr)[0..c]);βr)⊕

r−1⊕

i=1

ργi (38)

BecauseMAC is not used inργi , the right side of Equation 38 is arandom oracle with respect toSVi andFSi, ∀0≤ i≤ r−1.

We can further simplify the notation by denotingργ0 asf0(SV0,FS0)and the right side of Equation 38 as

f1(FS0, · · · ,FSr−1,SV0, · · · ,SVr−1). Bothf0 andf1 are random oracle with range{0,1}k . As a result,by creating aAHDR traversingr+ 1 honest nodes, the adversaryequivalently finds a solution to

f0(SV0,FS0) = f1(FS0, · · · ,FSr−1,SV0, · · · ,SVr−1)which obviously can only be solved with negligible probabilitywith significantly less than 2k work. That says, with much lessthan 2k work, the adversary can only generate a packet that tra-verser+1 hops with negligible probability.

5.1.3 Wrap-resistanceTo prove the wrap-resistance property, we show that given a data

packet(FS,γ,β,P ), an adversary, with significant less than 2k

work, cannot generate a message(FS′,γ′,β′,P ) so that process-ing (FS′,γ′,β′,P ) on an uncompromised node yields data packet(FS,γ,β,P ).

To succeed, it is necessary thatïijŽβ⊕{β′c..cr−1||0

c}= ρ(SV ′,FS′) (39)Consider the lastc bits of the left side of Equation 39, we have:

β[c(r−1)..cr−1] = ρ(SV ′,FS′)[c(r−1)..cr−1] (40)BecausePRG, PRP , hPRG, andhPRP are all random oracles,an adversary could generateFS′ andSV ′ that satisfy Equation 40only with negligible probability if the adversary performsmuchless than 2k work.

5.1.4 SecurityIn order to demonstrate the security property, we need to prove

that an adversary with controls over all nodes on a path except onenodeN , cannot distinguish among data packets enteringN . Theadversary is able to select paths for the packets traversingN andpayloads of the packets. The adversary can also observe packets en-tering and leaving nodeN except for packets whose headers matchthe challenge packets.

We construct the following gameG. The adversary picks twopaths(n0,n1, · · · ,nν−1) 0< ν ≤ r and (n′0,n

′1, · · · ,n

′ν ′−1) 0 ≤

ν ′ ≤ r, whereni = n′i ∀0≤ i ≤ j andnj = n′j = N . Note thatthe nodes afterN in both paths are not necessarily the same setof nodes, and the lengths of the paths can also be different. Theadversary chooses the public/private key pairs andSVi(SV ′i ) forall nodes exceptN and can arbitrarily select payloadM .

The challenger picks randomly a bitb and proceeds in one of thefollowing two ways:b = 0: The challenger creates anAHDR (FS0,γ0,β0) through

the HORNET setup phase using the path(n0,n1, · · · ,nν−1) anduses it to construct a data packet with onion encrypted payloadMe

from M . The challenger outputs(FS0,γ0,β0,Me), which could

be sent ton0.b = 1: The challenger creates anAHDR (FS0,γ0,β0) using the

alternative path(n′0,n′1, · · · ,n

′ν−1) instead and outputs

(FS0,γ0,β0,Me), which could be sent ton′0.

Given the output(FS0,γ0,β0), the adversary’s goal is to deter-mineb. The adversary can also input any messages(FS′,γ′,β′,Me ′)to the honest nodeN and observes the output messages as long as(FS′,γ′,β′) 6= (FSj ,γj ,βj).4

We define the adversary’s advantage as the difference between 12

and the probability that the adversary succeeds. We will show thatthe adversary’s advantage is negligible. That says, the adversaryhas no better chance to determineb than random guessing.

Proof. (Sketch) We adopt the method of hybrid games. First, weconstruct a modified gameG1 with exactly the same definition, ex-cept that we requirej = 0. An adversary who can winG can thusimmediately winG1. On the other hand, because the adversarycontrols nodes(n0, · · · ,nj−1) ((n′0, · · · ,n

′j−1)) and can thus emu-

late their processing, the adversary can also win gameG if he/shecan win gameG1. Therefore, the adversary can win gameG if andonly if the adversary can win gameG1.

We create a second gameG2, which is the same asG1 exceptthatFS0, β0, andγ0 are all randomly generated from their corre-sponding domains. If the adversary can distinguishG2 from G1,we have:

1. The adversary can distinguishFS0 = PRP (hPRP (SV0);R0||s0)

from randomness. Then it must be that the adversary is ableto tell the output of a pseudo-random permutation with a ran-dom key (hPRP (SV0)) from random bits. The probabilityof success for the adversary is negligible.

2. The adversary can distinguishβ0 = PRG(hPRG(SV0))⊕{FS1||γ1||β1}

from randomness. Then it must be the adversary is able todistinguish the output of a secure pseudo-random numbergenerator with a random key (hPRG(SV0)) from random-ness. The probability that the adversary succeeds is negligi-ble.

3. The adversary can distinguishγ0 =MAC(hMAC(SV0);β0)

from randomness. Then it must be the adversary is able todistinguish the output ofMAC with a random keyhMAC(SV0)from randomness. Under our random oracle assumption forMAC, the probability of success is negligible.

Therefore, the adversary cannot distinguishG2 fromG1.At last, because inG2, (FS0,γ0,β0) are all random, the adver-

sary’s advantage is 0. Moreover, in our chain of gameG→G1→G2, the adversary can only distinguish a game from its previousgame with negligible probability. As a result, the adversary’s ad-vantage in gameG is negligible.

5.2 Passive De-anonymizationSession linkage. Each session is established independently fromevery other session, based on fresh, randomly generated keys. Ses-sions are in particular not related to any long term secret oridenti-fier of the host that creates them. Thus, two sessions from thesamehost are unlinkable, i.e., they are cryptographically indistinguish-able from sessions of two different hosts.Forward/backward flow correlation . The forward and backwardheaders are derived from distinct cryptographic keys and therefore

4We follow the definition of security property in [17] and onlycareabout header uniqueness.

9

cannot be linked. Only the destination is able to correlate forwardand backward traffic, and could exploit this to discover the round-trip time (RTT) between the source and itself, which is common toall low-latency anonymity systems. Sources, willing to thwart suchRTT-based attacks from malicious destinations, could introduce arandom response delay for additional protection.Packet correlation. HORNET obfuscates packets at each hop toprevent an adversary observing two points on a path from linkingpackets between those two points using packets’ bit-patterns. Be-sides the use of onion encryption, we also enforce this obfusca-tion by padding header and payload to a fixed length, thwartingpacket-size-based correlation.5 While this does not prevent the ad-versary from discovering that the same flow is passing his observa-tion points using traffic analysis, it makes this process non-trivial,and allows upper layer protocols to take additional measures tohide traffic patterns. The hop-by-hop encryption of the payloadalso hides the contents of the communication in transit, protect-ing against information leaked by upper layer protocols that can beused to correlate packets.Flow-dynamics-based end-to-end correlation. In general it isdifficult even for high latency mix networks to resist such powerfuladversaries [34]. Low-latency anonymity systems are particularlyprone to these types of attacks [43, 30]. HORNET cannot protectagainst them, but as mentioned above, the use of packet obfuscationmakes these attacks more expensive and allows for potentialaddi-tional measures to be taken (e.g., padding), either by upperlayerprotocols or by extensions of HORNET. Mass surveillance basedon end-to-end confirmation attacks requires an adversary tomon-itor a large fraction of the nodes of the network and to store andprocess all intercepted traffic, so it falls outside our attacker model.

5.3 Active De-anonymizationSession state modification. The state of each node is included inan encrypted FS. During the session setup, the FSes are insertedinto the FS payload, which allows the source to check the integrityof these FSes during the setup phase. When the FSes are carriedin theAHDR, they are integrity-protected as well thanks to per-hopMACs computed by the source. This second case needs clarifi-cation, however, since it involves a particular construction. EachMAC protecting an FS is computed using a key contained in thatFS. This construction is secure because every FS is encrypted us-ing a PRP keyed with a secret value known only to the node thatcreated the FS: if the FS is modified, the authentication key thatthe node obtains after decryption is a new pseudo-random keythatthe adversary cannot control. Thus, the probability of the adversarybeing able to forge a valid MAC is still negligible.Path modification. Both HORNET data structures that hold paths,i.e., the FS payloads in the setup phase and theAHDRs, use chainedper-hop MACs to protect path integrity and thwart attacks like in-serting new nodes, changing the order of nodes, and splicingtwopaths. The source can check such chained per-hop MACs to detectthe modifications in the FS payload before using the modified FSpayload to constructAHDRs, and similarly intermediate nodes candetect modifications toAHDRs and drop the altered packets.Replay attacks. Replaying packets can facilitate some types ofconfirmation attacks. For example, an adversary can replay pack-ets with a pre-selected pattern, and have a colluding node iden-tify those packets downstream. HORNET offers replay protectionthrough session expiration. Replayed packets whose sessions haveexpired are immediately dropped. Replay of packets whose ses-

5An alternative for a more optimized bandwidth usage would betoallow two or three different payload sizes, at a cost of decreasedanonymity.

sions are not yet expired is possible, but the risk of misbehavingnodes being detected6 might deter an adversary from using replaysto conduct mass surveillance.Payload tagging or tampering. HORNET does not use per-hopMACs on the payload of data packets for efficiency and becausethe destination would not be able to compute such MACs. Thelack of integrity protection allows an adversary to tag payloads.Admittedly, by using tagging in conjunction with replay attacks,the adversary is able to improve the effectiveness of confirmationattacks. However, the end-to-end MACs protect the integrity of thedata, making such attacks (at a large scale) detectable.

5.4 Denial-of-Service (DoS) ResilienceComputational DoS. The use of asymmetric cryptography in thesetup phase makes HORNET vulnerable to computational DoS at-tacks, where adversaries can attempt to deplete a victim node’scomputation capability by initiating a large number of sessions throughthis node. To mitigate this attack, HORNET nodes should rate-limitthe number of session setup packets that are processed per neigh-bor.State-based DoS. HORNET is not vulnerable to attacks where ad-versaries maintain a large number of active sessions through a vic-tim node. One of HORNET’s key features is that all state is carriedwithin packets, thus no per-session memory is required on nodes orrendezvous points.

5.5 Topology-based AnalysisUnlike onion routing protocols that use global re-routing through

overlay networks (e.g., Tor [23] and I2P [47]), HORNET uses shortpaths created by the underlying network architecture to reduce la-tency, and is therefore bound by the network’s physical intercon-nection and ISP relationships. This is an unavoidable constraint foronion routing protocols built into the network layer [29, 42]. Thus,knowledge of the network topology enables an adversary to reducethe number of possible sources (and destinations) of a flow byonlylooking at the previous (and next) hop of that flow. For example,in Figure 3(a), assume that AS0 is controlled by a passive adver-sary. The topology indicates that any packet received from AS1must have originated from a source located at one of {AS1, AS2,AS3, AS4, AS5}.

We evaluate the information leakage due to the above topologyconstraints in the scenario where a single AS is compromised. Wederive AS-level paths from iPlane trace-route data [7]7, and useAS-level topology data from CAIDA [33]. For each AS on eachpath we assume that the AS is compromised and receives packetsfrom a victim end host through that path. We compute the endhost’s anonymity set size that the adversary learns according to thetopology. Similar to Hsiao et al. [29], we use the number of IPv4addresses to estimate the size of the anonymity set of end hosts.Figure 3(b) plots the CDF of the anonymity set size for differentdistances (in number of AS hops) between the adversary and thevictim end host. For adversarial ASes that are 4 hops away, theanonymity set size is larger than 231 in 90% of the cases. Note thatthe maximum anonymity set size is 232 in our analysis, because weconsider only IPv4 addresses.

Implications of path knowledge. Knowledge about the path, in-cluding the total length of the path and an adversarial node’s po-sition on the path, significantly downgrades the anonymity of endhosts. Considering again Figure 3(a), if the adversary controllingAS0 sees a packet incoming from AS1 and knows that it is 4 hops

6Volunteers and organizations might monitor the network, and hon-est ASes might control their own nodes as part of an IDS.7Traceroute data was generated on October 12, 2014

10

Sender

Sender

Sender

AS4

AS5

AS3

AS2 AS1 InternetAS0

(a)

0 5 10 15 20 25 30Anonymity set size (log2 )

0.0

0.2

0.4

0.6

0.8

1.0

CDF of anonymity set size

2 Hop3 Hop4 Hop5 Hop6 Hop7 Hop

(b)

0 5 10 15 20 25 30Anonymity set size (log2 )

0.0

0.2

0.4

0.6

0.8

1.0

CDF of anonymity set size

2 Hop3 Hop4 Hop5 Hop6 Hop7 Hop

(c)

Figure 3: a) An example AS-level topology with an adversarial AS (AS0); b) CDF of anonymity-set size when a position-agnosticAS on path is adversarial. “Hops” indicates the number of ASes between the adversarial AS and the victim end host. c) CDF ofanonymity-set size when an adversarial AS knows its own position on the path.

away from the source host, he learns that the source host is inAS4.Compared with the previous case, we see that the anonymity setsize is strongly reduced.

We quantify additional information leakage in the same settingas the previous evaluation. Figure 3(c) represents the CDFsof theanonymity set sizes of end hosts according to the distance tothecompromised AS. The anonymity set sizes are below 228 in 90%of the cases when the adversarial ASes are 4 hops away, with anaverage size of 223. This average size decreases to 217 for the caseswhere the adversarial ASes are 7 hops away from the target hosts.

Previous path-based anonymity systems designed for the net-work layer either fail to hide knowledge about the path [42] or onlypartially obscure the information [29]. In comparison, HORNETprotects both the path length and the position of each node onthepath, which significantly increases the anonymity-set sizeof theend hosts, as our analysis in this section showed.

6. EVALUATIONWe implemented the HORNET router logic in an Intel software

router using the Data Plane Development Kit (DPDK) [4]. To ourknowledge, no other anonymity protocols have been implementedin a router SDK. We also implemented the HORNET client inPython. Furthermore, we assembled a custom crypto library basedon the Intel AESNI crypto library [6], the curve25519-donnali-brary [3], and the PolarSSL libraries [9]. For comparison, we im-plemented the data forwarding logic from LAP, Dovetail, andL3Tor8 and Sphinx using DPDK and our crypto library. We use IPforwarding in DPDK as our performance baseline.

Our testbed contains an Intel software router connected to aSpirentTestCenter packet generator and analyzer [11]. The software routerruns DPDK 1.7.1 and is equipped with an Intel Xeon E5-2680processor (2.70 GHz, 2 sockets, 16 logical cores/socket), 64 GBDRAM, and 3 Intel 82599ES 40 Gb/s network cards (each with 410 Gb/s ports). We configured DPDK to use 2 receiving queues foreach port with 1 adjacent logical core per queue.

6.1 Data Forwarding PerformanceForwarding latency. We measure the CPU cycles consumed toforward a data packet in all schemes. Figure 5(a) shows the aver-age latency (with error bars) to process and forward a singledatapacket in all schemes when payload sizes vary. We observe thatdata forwarding in Sphinx is 3 orders of magnitude slower than that8For fair comparison, we only implement payload encryp-tion/decryption. We do not implemented SSL/TLS or L4 transportcontrol logic.

Scheme Header Length Sample Length (Bytes)LAP 12+2s ·r 236

Dovetail 12+s ·r 124Sphinx 32+(2r+2)s 296

Tor 3+11·r 80HORNET 8+3r ·s 344

Table 1: Comparison between the length of different packetheader formats in bytes.s is the length of symmetric elementsand r is the maximum AS path length. For the sample length,we selects= 16Bytes andr= 7. Analysis of iPlane paths showsthat more than 99% of all paths have less than7 AS hops.

of HORNET, L3 Tor, LAP, and Dovetail because Sphinx requiresper-packet asymmetric crypto operations. We further observe thatHORNET, even with onion encryption/decryption over the entirepayload and extensive header manipulation, is only 5% slower thanLAP and Dovetail for small payload (64 bytes). For large payloads(1200 bytes9), HORNET is 71% slower (about 400 nanosecondsslower per packet when using a single core) than LAP and Dove-tail. However, the additional processing overhead enablesstrongersecurity guarantees.

Header overhead.As a result of carrying anonymous session state(specifically cryptographic keys) within packet headers, HORNETheaders are larger than Sphinx, L3 Tor, LAP, and Dovetail headers(see Table 1). While larger headers reduce net throughput (i.e.,goodput), this tradeoff appears acceptable: compared to L3Tor,no state is required at relay nodes, enabling scalability; comparedto Sphinx, data processing speed is higher; compared to LAP andDovetail, HORNET provides stronger security properties.

Throughput. To compare the throughput of data forwarding, wemeasure the throughput of all schemes on a single CPU core on a10 Gb/s link with different payload sizes. The result is shown inFigure 6.1. We observe that all schemes except Sphinx can satu-rate the 10Gb/s link when the payload size is larger than 512 Bytes.When payload size is smaller than 256 Bytes, HORNET’s through-put is 20% - 30% smaller than LAP and Dovetail, whose through-put, in turn are 25% smaller than IP forwarding. Note, Tor’s smallthroughput at small payload sizes is mainly a reflection of its smallper-hop header size, as later proved in Figure 5(b). In comparison,Sphinx can only achieve 0.05Gb at its maximum when the packet

9Because LAP, Dovetail, and HORNET all have large packet head-ers of 300+ bytes, we limit the largest payload in our experimentsto be 1200 bytes.

11

size is 1500 Bytes because of its expensive data forwarding.

0 200 400 600 800 1000 1200 1400 1600

Payload Size [Bytes]

0

2

4

6

8

10

Thoughput [Gbps]

IP

LAP/Dovetail

Sphinx

Tor

HORNET

Figure 4: Data forwarding throughput on 10 Gb/s link

Goodput. We further compare all the schemes by goodput, whichexcludes the header overhead from total throughput. Goodput is acomprehensive metric to evaluate both the packet processing speedand protocol overhead. For example, a scheme where headers takeup a large proportion of packets yields only low goodput. On theother hand, a scheme with low processing speed also results in poorgoodput.

Figure 5(b) and Figure 5(c) demonstrate the goodput of all schemeson a 10Gb/s link when varying the number of hops, with 40-byteand 1024-byte payloads, respectively. We observe that Sphinx’sgoodput is the lowest in both cases because of its large packet head-ers and slow asymmetric-crypto-based packet processing.

When the payload size is small, the goodput of all protocolsremains stable. This is due to the fact that no scheme can sat-urate the link, and accordingly the goodput differences betweenthe three schemes mainly reflect the different processing latenciesamong them. Consequently, L3 Tor’s and HORNET’s goodput is32% less than that of LAP and Dovetail. On the other hand, whenthe payload size is large, all schemes except Sphinx can saturatethe 10Gb/s link. HORNET can reach 93% of LAP and Dovetail’sgoodput while providing stronger security guarantees.

6.2 Max Throughput on a Single RouterTo investigate how our implementation scales with respect to the

number of CPU cores, we use all 12 ports on the software router,generating HORNET data packets at 10 Gb/s on each port. Eachpacket contains a 7 AS-hop header and a payload of 512 bytes, andis distributed uniformly among the working ports. We monitor theaggregate throughput on the software router.

The maximal aggregate throughput of HORNET forwarding inour software router is 93.5 Gb/s, which is comparable to today’sswitching capacity of a commercial edge router [2]. When thenumber of cores is less than 5, our HORNET implementation canachieve full line rate (i.e., 10 Gb/s per port). As the numberof coresincreases to 5 and above, each additional port, with the two logicalcores binded to the port, adds an extra 6.8Gb/s.

6.3 Session-Setup PerformanceWe evaluate the latency introduced by processing setup packets

on each border router. Similar to measuring the latency of data for-warding, we also instrument the code to measure CPU cycles con-sumed to process packets in the session-setup phase. Table 2lists

the average per-node latency for processing the two setup packetsin HORNET’s session-setup phase. Due to a Diffie-Hellman keyexchange, processing the two setup packets in the session-setupphase increases processing latency (by about 240µs) compared todata packet processing. However, HORNET must only incur in thislatency once per session.

Packet Latency (K cycles) Latency (µs)P➊ 661.95± 30.35 245.17± 11.24P➋ 655.85± 34.03 242.91± 12.60

Table 2: Per-node latency to process session-setup packetswithstandard errors.

6.4 Network EvaluationDistribution of AS-level path length.. The bandwidth overhead ofa HORNET packet depends on the number of ASes traversed by thepacket. Figure 6 demonstrates the CDF of AS-level path lengths ofthe paths extracted from our data source. We observe that 99%ofthe paths have a path length smaller than 7, and the mean AS-levelpath length is 4.2. Thus, to achieve 128 bits of security, 48 bytesper AS hop are required, leading to an average overhead of 201.6bytes.

0 2 4 6 8 10 12 14AS-level path length

0.0

0.2

0.4

0.6

0.8

1.0

CDF

Figure 6: CDF of AS-level path length.

Non-scalability of a stateful design. We evaluate the memorycapacity needed to maintain state required by a stateful design tosupport Internet-scale anonymous communication. We considerthe design of Tor, one of the most popular onion routing systemstoday [23], and assume that each Tor node (onion routeror OR)would correspond to an autonomous system (AS), as proposed byLiu et al. [32]. Analyzing the CAIDA Internet Traces [1], we foundthat a 10 GbE backbone link handles about 1M new flows everyminute under normal operating conditions. Since the largest inter-AS links today have up to ten times that capacity (100 Gbps)10, thismeans that at the core of the network there are edge routers ofASesthat handle about 10M new flows per minute.

If we assume that half of these flows would use a Tor circuit,because of the default lifetime of circuits of 10 minutes11 we ob-tain that ORs on such edge routers would need to store state for

10E.g., seewww.seattleix.net/participants.htm.11We actually measured the number of flows taking this lifetimeintoaccount, in particular we expired flows only if no packets where

12

0 200 400 600 800 1000 1200 1400 1600Payload Size [Bytes]

101

102

103

104

105

106La

ten

cy [

Cy

cle

s]

IP

LAP/Dovetail

Sphinx

Tor

HORNET

(a)

4 6 8 10 12 14Number of AS hops

0

1

2

3

4

5

6

Goodput [Gbps]

IP

LAP

Dovetail

Sphinx

Tor

HORNET

(b)

4 6 8 10 12 14Number of AS hops

0

2

4

6

8

10

Goodput [Gbps]

IP

LAP

Dovetail

Sphinx

Tor

HORNET

(c)

Figure 5: a) Per-node data forwarding latency on a 10 Gbps link; b)Data forwarding goodput on a 10 Gbps link for small packets (40Bytes payload); c) Data forwarding goodput large packets (1024 Bytes payload). For a), lower is better; for others, higher is better.

approximatively 50M circuits at all times. Since Tor storesat least376 bytes per circuit, this translates to almost 20 GB of memory.This might still be acceptable for high-end devices, but there area number of additional factors that make keeping state unfeasible,even for ASes handling less traffic:• The growing number of user on the Internet and the increas-

ing number of devices per user result in an increasing numberof traffic flows;

• The state for each circuit would actually be larger, as for ac-tive circuits the ORs need to store the packets being trans-mitted until they are acknowledged by the next hop;

• A DDoS attack could force an OR to store much more stateby opening a large number of new circuits through that OR.

7. DISCUSSION

7.1 Retrieving Paths Anonymously in FIAsHORNET assumes that the source host can obtain a forward path

and a backward path to an intended destination host anonymouslyin FIAs. We briefly discuss how a source host using HORNET canretrieve such two paths in NIRA, SCION and Pathlet.

NIRA and SCION hosts rely on path servers to retrieve paths. Inboth architectures, each destination node registers its path to/fromthe network “core” on a centralized path server. A source onlyneeds to anonymously fetch the information registered by the desti-nation to form forward and backward paths, which could be done intwo ways. As a first method, the source can obtain the paths to/fromthe path servers from resolver configuration or local services simi-lar to DHCP and establish an anonymous HORNET session to theservers. Once the HORNET session is created, the source can pro-ceed to anonymously request a path to the destination. Alterna-tively, the source can leverage a PIR scheme to retrieve the pathanonymously from the path server.

In Pathlet routing, the situation is different because the routinginformation is disseminated through a path vector protocol. Thesource can keep a local database of pathlets and simply querythedatabase locally for the pathlets to a certain destination.

7.2 Composability with other protocolsHORNET operates at the network layer. As such, upper-layer

anonymity protocols may be used in conjunction with HORNET toprovide stronger anonymity guarantees. For example, to help mit-igate concerns of topology-based attacks (as seen in Section 5.5),

seen on them for over 10 minutes. Also note that in our settingitwould not be possible to have multiple streams per circuit, unlessthe destinations those streams are in the same AS.

a single hop proxy or virtual private network (VPN) could be usedto increase the size of the anonymity sets of end hosts. Similarsolutions could also protect against upper-layer de-anonymizationattacks, in particular fingerprinting attacks on the transport proto-col [44].

At lower layers, HORNET is also compatible with link-layerprotection such as link-level encryption. The role of link-level en-cryption in HORNET is comparable to SSL/TLS in Tor. Link en-cryption prevents an adversary eavesdropping on a link frombeingable to distinguish individual sessions from each other, thereforemaking confirmation attacks much harder for this type of adver-sary.

7.3 Targeted confirmation attacksWhen an adversary controls more than one node on a path, it

can launch confirmation attacks by leveraging flow-dynamicsanal-ysis, timing, and packet tagging, all of which can be furtherassistedby replay attacks. HORNET, like other low-latency onion routingschemes [23], cannot prevent such confirmation attacks targetingindividual users. However, HORNET raises the bar of deployingsuch attacks for secretive mass surveillance: the adversary mustbe capable of controlling a significant percentage of ISPs often re-siding in multiple geopolitical boundaries, not to mentionkeepingsuch massive activity confidential.

8. RELATED WORKAnonymity system using overlays.The study of anonymous com-munication began with Chaum’s proposal for mix relays [19].Anumber of message-based mix systems have been proposed anddeployed since [28, 36, 20, 21]. These systems can withstandanactive adversary and a large fraction of compromised relays, butrely on expensive asymmetric primitives, and message batchingand mixing. Thus, they suffer from large computational overheadand high latency.

Onion routing systems [41, 23] were proposed to efficiently sup-port interactive web traffic. Onion routing systems are vulnerableagainst end-to-end correlation attacks [31], and may fail to provideunlinkability when two routers on the path are compromised [27,30]. While these systems are generally intended as overlays, someproposals [14, 15] are closer to the network layer in that they useUDP (instead of TCP [23]) between pairs of onion routers. HOR-NET distinguishes itself from all of these systems in two ways: itdoes not store per-connection state on the nodes, and it requiresonly a single round trip to establish an anonymous path.

Anonymity systems in FIAs. Hsiao et al. [29] explored the de-sign space of efficient anonymous systems with a relaxed adversary

13

model. In their scheme, LAP, the adversary can compromise onlya single node, and the first hop must always be honest. Sankeyand Wright proposed Dovetail [42] (based on Pathlets [26] andSCION [48]) which has the same attacker model as LAP, exceptit allows the first hop to be compromised. Compared to HORNETand to onion routing, LAP and Dovetail do not offer protection tothe payload, and they allow nodes to learn their position on thepath.

The research community has also explored applying onion rout-ing to FIAs. Liu et al. [32] proposed Tor instead of IP as an FIAthat regards anonymity as the principal requirement for thenetworkarchitecture. However, details on how to scale Tor’s current design(requiring per-circuit state) to Internet scale were not addressed.

DiBenedetto et al. [22] proposed ANDaNA, to enable onion rout-ing in Named Data Networking (NDN). NDN focuses on contentdelivery and thus inherently different from the FIAs we considered.

9. CONCLUSIONIn this paper, we address the question of “what minimal mech-

anism can we use to frustrate pervasive surveillance [24]?”andstudy the design of a high-speed anonymity system supportedbythe network architecture. We propose HORNET, a scalable andhigh-speed onion routing scheme for future Internet architectures.HORNET nodes can process anonymous traffic at over 93 Gb/sand require no per-flow state, paving the path for Internet-scaleanonymity. Our experiments show that small trade-offs in packetheader size greatly benefit security, while retaining high perfor-mance.

10. REFERENCES[1] CAIDA UCSD Anonymized Internet Traces 2014.http://www.

caida.org/data/passive/passive_2014_dataset.xml.Retrieved on 2015.04.30.

[2] Cisco ASR-1000.http://www.cisco.com/c/en/us/products/routers/. Retrieved on 2015.04.28.

[3] curve25519-donna.https://code.google.com/p/curve25519-donna/. Retrieved on 2014.12.13.

[4] DPDK: Data Plane Development Kit.http://dpdk.org/.Retrieved on 2014.12.23.

[5] HORNET: High-speed Onion Routing at the Network Layer.anonymizedurl. Technical report.

[6] Intel AESNI Sample Library.https://software.intel.com/en-us/articles/download-the-intel-aesni-sample-library . Retrieved on2014.12.13.

[7] iPlane dataset.http://iplane.cs.washington.edu/data/data.html. Retrieved on 2014.12.23.

[8] NSA targets the privacy-conscious.http://daserste.ndr.de/panorama/aktuell/NSA-targets-the-privacy-conscious,nsa230.html. Retrieved on 2015.05.13.

[9] PolarSSL.https://polarssl.org/. Retrieved on 2014.12.13.[10] Segment Routing Architecture (IETF draft).https://

datatracker.ietf.org/doc/draft-ietf-spring-segment-routing/ . Retrieved on2015.05.13.

[11] Spirent TestCenter.http://www.spirent.com/Ethernet_Testing/Software/TestCenter. Retrieved on 2014.12.23.

[12] The crux of the NSA story in one phrase: ’collect it all’ .http://www.theguardian.com/commentisfree/2013/jul/15/crux-nsa-collect-it-all . Retrieved on 2014.12.13.

[13] Tor metrics.https://metrics.torproject.org. Retrieved on2015.05.13.

[14] Philippe Boucher, Adam Shostack, and Ian Goldberg. Freedomsystems 2.0 architecture, 2000. White paper, Zero KnowledgeSystems, Inc.

[15] Zach Brown. Cebolla: Pragmatic IP anonymity. InOttawa LinuxSymposium, 2002.

[16] R. Bush and R. Austein. The Resource Public Key Infrastructure(RPKI) to Router Protocol. IETF RFC 6810.

[17] Jan Camenisch and Anna Lysyanskaya. A formal treatmentof onionrouting. InCRYPTO, 2005.

[18] Ran Canetti. Universally composable security: A new paradigm forcryptographic protocols. InIEEE FOCS, 2001.

[19] David L. Chaum. Untraceable electronic mail, return addresses, anddigital pseudonyms.Communications of the ACM, 24(2), 1981.

[20] George Danezis, Roger Dingledine, and Nick Mathewson.Mixminion: Design of a type III anonymous remailer protocol. InIEEE S&P, 2003.

[21] George Danezis and Ian Goldberg. Sphinx: A Compact and ProvablySecure Mix Format. InIEEE S&P, 2009.

[22] Steven DiBenedetto, Paolo Gasti, Gene Tsudik, and Ersin Uzun.ANDaNA : Anonymous Named Data Networking Application. InNDSS, 2011.

[23] Roger Dingledine, Nick Mathewson, and Paul Syverson. Tor: TheSecond-Generation Onion Router. InUSENIX Security, 2004.

[24] S. Farrell and H. Tschofenig. Pervasive Monitoring Is an Attack.IETF RFC 7258.

[25] Michael J. Freedman, Kobbi Nissim, and Benny Pinkas. EfficientPrivate Matching and Set Intersection. InEUROCRYPT, 2004.

[26] P. Brighten Godfrey, Igor Ganichev, Scott Shenker, andIon Stoica.Pathlet routing.ACM SIGCOMM, 2009.

[27] David M. Goldschlag, Michael G. Reed, and Paul F. Syverson.Hiding routing information. InACM Information Hiding (IH)Conference, 1996.

[28] Ceki Gülcü and Gene Tsudik. Mixing email with babel. InNDSS,1996.

[29] Hsu Chun Hsiao, Tiffany Hyun Jin Kim, Adrian Perrig, AkiraYamada, Samuel C. Nelson, Marco Gruteser, and Wei Meng. LAP:Lightweight anonymity and privacy. InIEEE S&P, 2012.

[30] Aaron Johnson, Chris Wacek, Rob Jansen, Micah Sherr, and Paul F.Syverson. Users get routed: traffic correlation on tor by realisticadversaries. InACM CCS, 2013.

[31] Brian N. Levine, Michael K. Reiter, Chenxi Wang, and Matthew K.Wright. Timing attacks in low-latency mix-based systems. In FC,2004.

[32] Vincent Liu, Seungyeop Han, Arvind Krishnamurthy, andThomasAnderson. Tor instead of IP. InACM HotNets, 2011.

[33] P. Mahadevan, D. Krioukov, M. Fomenkov, B. Huffaker,X. Dimitropoulos, K. Claffy, and A. Vahdat. The Internet AS-LevelTopology: Three Data Sources and One Definitive Metric. InACMSIGCOMM, 2006.

[34] Nick Mathewson and Roger Dingledine. Practical trafficanalysis:Extending and resisting statistical disclosure. InPETS, 2004.

[35] Prateek Mittal, Femi Olumofin, Carmela Troncoso, Nikita Borisov,and Ian Goldberg. PIR-Tor: Scalable Anonymous CommunicationUsing Private Information Retrieval. InUSENIX Security, 2011.

[36] Ulf Möller, Lance Cottrell, Peter Palfrader, and Len Sassaman.Mixmaster Protocol v. 2. IETF Draft, 2003.

[37] R. Moskowitz and P. Nikander. Host Identity Protocol (HIP)Architecture. IETF RFC 4423.

[38] Steven J. Murdoch and Piotr Zielinski. Sampled traffic analysis byInternet-exchange-level adversaries. InPETS, 2007.

[39] Andreas Pfitzmann and Marit Köhntopp. Anonymity,unobservability, and pseudonymity - a proposal for terminology. InPETS, 2001.

[40] Ryan Pries, Wei Yu, Xinwen Fu, and Wei Zhao. A new replay attackagainst anonymous communication networks. InIEEE ICC, 2008.

[41] Michael G. Reed, Paul F. Syverson, and M. Goldschlag David.Anonymous connections and onion routing.IEEE JSAC, 1998.

[42] Jody Sankey and Matthew Wright. Dovetail: Stronger anonymity innext-generation internet routing. InPETS, 2014.

[43] Andrei Serjantov and Peter Sewell. Passive attack analysis forconnection-based anonymity systems. InESORICS, 2003.

[44] Matthew Smart, G. Robert Malan, and Farnam Jahanian. DefeatingTCP/IP Stack Fingerprinting. InUSENIX Security, 2000.

[45] Wei Wang, Mehul Motani, and Vikram Srinivasan. Dependent linkpadding algorithms for low latency anonymity systems. InACMCCS, 2008.

14

[46] Xiaowei Yang, David Clark, and Arthur W Berger. Nira: a newinter-domain routing architecture.IEEE/ACM Transactions onNetworking, 2007.

[47] Bassam Zantout and Ramzi Haraty. I2P data communication system.In ICN, 2011.

[48] Xin Zhang, Hsu-Chun Hsiao, Geoffrey Hasker, Haowen Chan,Adrian Perrig, and David G. Andersen. SCION: Scalability, Control,and Isolation on Next-Generation Networks. InIEEE S&P, 2011.

15