Nymble blocking misbehaviouring users in anonymizing networks

Nymble: Blocking Misbehaving Users
in Anonymizing Networks
Patrick P. Tsang, Apu Kapadia, Member, IEEE, Cory Cornelius, and Sean W. Smith
Abstract—Anonymizing networks such as Tor allow users to access Internet services privately by using a series of routers to hide the
client’s IP address from the server. The success of such networks, however, has been limited by users employing this anonymity for
abusive purposes such as defacing popular Web sites. Web site administrators routinely rely on IP-address blocking for disabling
access to misbehaving users, but blocking IP addresses is not practical if the abuser routes through an anonymizing network. As a
result, administrators block all known exit nodes of anonymizing networks, denying anonymous access to misbehaving and behaving
users alike. To address this problem, we present Nymble, a system in which servers can “blacklist” misbehaving users, thereby
blocking users without compromising their anonymity. Our system is thus agnostic to different servers’ definitions of
misbehavior—servers can blacklist users for whatever reason, and the privacy of blacklisted users is maintained.
Index Terms—Anonymous blacklisting, privacy, revocation.
Ç
1 INTRODUCTION
ANONYMIZING networks such as Tor [18] route traffic
through independent nodes in separate administrative
domains to hide a client’s IP address. Unfortunately, some
users have misused such networks—under the cover of
anonymity, users have repeatedly defaced popular Web sites
such as Wikipedia. Since Web site administrators cannot
blacklist individual malicious users’ IP addresses, they
blacklist the entire anonymizing network. Such measures
eliminate malicious activity through anonymizing networks
at the cost of denying anonymous access to behaving users.
In other words, a few “bad apples” can spoil the fun for all.
(This has happened repeatedly with Tor.1
)
There are several solutions to this problem, each
providing some degree of accountability. In pseudonymous
credential systems [14], [17], [23], [28], users log into Web
sites using pseudonyms, which can be added to a blacklist
if a user misbehaves. Unfortunately, this approach results
in pseudonymity for all users, and weakens the anonymity
provided by the anonymizing network.
Anonymous credential systems [10], [12] employ group
signatures. Basic group signatures [1], [6], [15] allow servers
to revoke a misbehaving user’s anonymity by complaining to
a group manager. Servers must query the group manager for
every authentication, and thus, lacks scalability. Traceable
signatures [26] allow the group manager to release a trapdoor
that allows all signatures generated by a particular user to be
traced; such an approach does not provide the backward
unlinkability [30] that we desire, where a user’s accesses
before the complaint remain anonymous. Backward unlink-
ability allows for what we call subjective blacklisting, where
servers can blacklist users for whatever reason since the
privacy of the blacklisted user is not at risk. In contrast,
approaches without backward unlinkability need to pay
careful attention to when and why a user must have all their
connections linked, and users must worry about whether
their behaviors will be judged fairly.
Subjective blacklisting is also better suited to servers
such as Wikipedia, where misbehaviors such as question-
able edits to a Webpage, are hard to define in mathematical
terms. In some systems, misbehavior can indeed be defined
precisely. For instance, double spending of an “e-coin” is
considered a misbehavior in anonymous e-cash systems [8],
[13], following which the offending user is deanonymized.
Unfortunately, such systems work for only narrow defini-
tions of misbehavior—it is difficult to map more complex
notions of misbehavior onto “double spending” or related
approaches [32].
With dynamic accumulators [11], [31], a revocation opera-
tion results in a new accumulator and public parameters for
the group, and all other existing users’ credentials must be
updated, making it impractical. Verifier-local revocation (VLR)
[2], [7], [9] fixes this shortcoming by requiring the server
(“verifier”) to perform only local updates during revocation.
Unfortunately, VLR requires heavy computation at the server
that is linear in the size of the blacklist. For example, for a
blacklist with 1,000 entries, each authentication would take
tens of seconds,2
a prohibitive cost in practice. In contrast, our
scheme takes the server about one millisecond per authenti-
cation, which is several thousand times faster than VLR. We
believe these low overheads will incentivize servers to adopt
256 IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 8, NO. 2, MARCH-APRIL 2011
. P.P. Tsang, C. Cornelius, and S.W. Smith are with the Department of
Computer Science, Dartmouth College, Hanover NH, USA.
E-mail: {patrick, sws}@cs.dartmouth.edu,
Cory.T.Cornelius@Dartmouth.edu.
. A. Kapadia is with the School of Informatics and Computing, Indiana
University Bloomington, USA. E-mail: kapadia@indiana.edu.
Manuscript received 7 Dec.2008; revised 29 Apr. 2009; accepted 24 June 2009;
published online 1 Sept. 2009.
For information on obtaining reprints of this article, please send e-mail to:
tdsc@computer.org, and reference IEEECS Log Number TDSC-2008-12-0188.
Digital Object Identifier no. 10.1109/TDSC.2009.38.
1. The Abuse FAQ for Tor Server Operators lists several such examples at
http://tor.eff.org/faq-abuse.html.en.
2. In Boneh and Shacham’s construction [7], computation at the server
involves 3 þ 2jBLj pairing operations, each of which takes tens of
milliseconds (see benchmarks at http://crypto.stanford.edu/pbc).
1545-5971/11/$26.00 ß 2011 IEEE Published by the IEEE Computer Society

such a solution when weighed against the potential benefits
of anonymous publishing (e.g., whistle-blowing, reporting,
anonymous tip lines, activism, and so on.).3
1.1 Our Solution
We present a secure system called Nymble, which provides
all the following properties: anonymous authentication,
backward unlinkability, subjective blacklisting, fast authen-
tication speeds, rate-limited anonymous connections, revo-
cation auditability (where users can verify whether they
have been blacklisted), and also addresses the Sybil attack
[19] to make its deployment practical.
In Nymble, users acquire an ordered collection of nymbles,
a special type of pseudonym, to connect to Web sites. Without
additional information, these nymbles are computationally
hard to link,4
and hence, using the stream of nymbles
simulates anonymous access to services. Web sites, however,
can blacklist users by obtaining a seed for a particular nymble,
allowing them to link future nymbles from the same
user—those used before the complaint remain unlinkable.
Servers can therefore blacklist anonymous users without
knowledge of their IP addresses while allowing behaving
users to connect anonymously. Our system ensures that users
are aware of their blacklist status before they present a
nymble, and disconnect immediately if they are blacklisted.
Although our work applies to anonymizing networks in
general, we consider Tor for purposes of exposition. In fact,
any number of anonymizing networks can rely on the same
Nymble system, blacklisting anonymous users regardless of
their anonymizing network(s) of choice.
1.2 Contributions of This Paper
Our research makes the following contributions:
. Blacklisting anonymous users. We provide a means
by which servers can blacklist users of an anonymiz-
ing network while maintaining their privacy.
. Practical performance. Our protocol makes use of
inexpensive symmetric cryptographic operations to
significantly outperform the alternatives.
. Open-source implementation. With the goal of
contributing a workable system, we have built an
open-source implementation of Nymble, which is
publicly available.5
We provide performance statis-
tics to show that our system is indeed practical.
Some of the authors of this paper have published two
anonymous authentication schemes, BLAC [33] and PEREA
[34], which eliminate the need for a trusted third party for
revoking users. While BLAC and PEREA provide better
privacy by eliminating the TTP, Nymble provides authenti-
cation rates that are several orders of magnitude faster than
BLAC and PEREA (see Section 6). Nymble thus represents a
practical solution for blocking misbehaving users of
anonymizing networks.
We note that an extended version of this paper is
available as a technical report [16].
2 AN OVERVIEW TO NYMBLE
We now present a high-level overview of the Nymble
system, and defer the entire protocol description and
security analysis to subsequent sections.
2.1 Resource-Based Blocking
To limit the number of identities a user can obtain (called
the Sybil attack [19]), the Nymble system binds nymbles to
resources that are sufficiently difficult to obtain in great
numbers. For example, we have used IP addresses as the
resource in our implementation, but our scheme gener-
alizes to other resources such as email addresses, identity
certificates, and trusted hardware. We address the practical
issues related with resource-based blocking in Section 8,
and suggest other alternatives for resources.
We do not claim to solve the Sybil attack. This problem is
faced by any credential system [19], [27], and we suggest
some promising approaches based on resource-based
blocking since we aim to create a real-world deployment.
2.2 The Pseudonym Manager
The user must first contact the Pseudonym Manager (PM) and
demonstrate control over a resource; for IP-address block-
ing, the user must connect to the PM directly (i.e., not
through a known anonymizing network), as shown in Fig. 1.
We assume the PM has knowledge about Tor routers, for
example, and can ensure that users are communicating with
it directly.6
Pseudonyms are deterministically chosen based
on the controlled resource, ensuring that the same pseudo-
nym is always issued for the same resource.
Note that the user does not disclose what server he or she
intends to connect to, and the PM’s duties are limited to
mapping IP addresses (or other resources) to pseudonyms.
As we will explain, the user contacts the PM only once per
linkability window (e.g., once a day).
2.3 The Nymble Manager
After obtaining a pseudonym from the PM, the user
connects to the Nymble Manager (NM) through the
TSANG ET AL.: NYMBLE: BLOCKING MISBEHAVING USERS IN ANONYMIZING NETWORKS 257
Fig. 1. The Nymble system architecture showing the various modes of
interaction. Note that users interact with the NM and servers though the
anonymizing network.
3. http://www.torproject.org/torusers.html.en.
4. Two nymbles are linked if one can infer that they belong to the same
user with probability better than random guessing.
5. The Nymble Project. http://www.cs.dartmouth.edu/~nymble.
6. Note that if a user connects through an unknown anonymizing
network or proxy, the security of our system is no worse than that provided
by real IP-address blocking, where the user could have used an
anonymizing network unknown to the server.

anonymizing network, and requests nymbles for access to a
particular server (such as Wikipedia). A user’s requests to
the NM are therefore pseudonymous, and nymbles are
generated using the user’s pseudonym and the server’s
identity. These nymbles are thus specific to a particular
user-server pair. Nevertheless, as long as the PM and the
NM do not collude, the Nymble system cannot identify
which user is connecting to what server; the NM knows
only the pseudonym-server pair, and the PM knows only
the user identity-pseudonym pair.
To provide the requisite cryptographic protection and
security properties, the NM encapsulates nymbles within
nymble tickets. Servers wrap seeds into linking tokens, and
therefore, we will speak of linking tokens being used to link
future nymble tickets. The importance of these constructs
will become apparent as we proceed.
2.4 Time
Nymble tickets are bound to specific time periods. As
illustrated in Fig. 2, time is divided into linkability windows
of duration W, each of which is split into L time periods of
duration T (i.e., W ¼ L Ã T ). We will refer to time periods
and linkability windows chronologically as t1; t2; . . . ; tL and
w1; w2; . . . , respectively. While a user’s access within a time
period is tied to a single nymble ticket, the use of different
nymble tickets across time periods grants the user anonym-
ity between time periods. Smaller time periods provide
users with higher rates of anonymous authentication, while
longer time periods allow servers to rate-limit the number
of misbehaviors from a particular user before he or she is
blocked. For example, T could be set to five minutes, and W
to one day (and thus, L ¼ 288). The linkability window
allows for dynamism since resources such as IP addresses
can get reassigned and it is undesirable to blacklist such
resources indefinitely, and it ensures forgiveness of misbe-
havior after a certain period of time. We assume all entities
are time synchronized (for example, with time.nist.gov via
the Network Time Protocol (NTP)), and can thus calculate
the current linkability window and time period.
2.5 Blacklisting a User
If a user misbehaves, the server may link any future
connection from this user within the current linkability
window (e.g., the same day). Consider Fig. 2 as an example:
A user connects and misbehaves at a server during time
period tÃ
within linkability window wÃ
. The server later
detects this misbehavior and complains to the NM in time
period tc (tÃ
< tc tL) of the same linkability window wÃ
.
As part of the complaint, the server presents the nymble
ticket of the misbehaving user and obtains the correspond-
ing seed from the NM. The server is then able to link future
connections by the user in time periods tc; tc þ 1; . . . ; tL of
the same linkability window wÃ
to the complaint. Therefore,
once the server has complained about a user, that user is
blacklisted for the rest of the day, for example (the
linkability window). Note that the user’s connections in
t1; t2; . . . ; tÃ
; tÃ
þ 1; . . . ; tc remain unlinkable (i.e., including
those since the misbehavior and until the time of com-
plaint). Even though misbehaving users can be blocked
from making connections in the future, the users’ past
connections remain unlinkable, thus providing backward
unlinkability and subjective blacklisting.
2.6 Notifying the User of Blacklist Status
Users who make use of anonymizing networks expect their
connections to be anonymous. If a server obtains a seed for
that user, however, it can link that user’s subsequent
connections. It is of utmost importance then that users be
notified of their blacklist status before they present a nymble
ticket to a server. In our system, the user can download the
server’s blacklist and verify her status. If blacklisted, the
user disconnects immediately.
Since the blacklist is cryptographically signed by the NM,
theauthenticity of theblacklist is easily verifiedif theblacklist
was updated in the current time period (only one update to
the blacklist per time period is allowed). If the blacklist has
not been updated in thecurrent timeperiod, the NM provides
servers with “daisies” every time period so that users can
verify the freshness of the blacklist (“blacklist from time
period told is fresh as of time period tnow”). As discussed in
Section 4.3.4, these daisies are elements of a hash chain, and
provide a lightweight alternative to digital signatures. Using
digital signatures and daisies, we thus ensure that race
conditions are not possible in verifying the freshness of a
blacklist. A user is guaranteed that he or she will not be linked
if the user verifies the integrity and freshness of the blacklist
before sending his or her nymble ticket.
2.7 Summary of Updates to the Nymble Protocol
We highlight the changes to Nymble since our conference
paper [24]. Previously, we had proved only the privacy
properties associated with nymbles as part of a two-tiered
hash chain. Here, we prove security at the protocol level. This
process gave us insights into possible (subtle) attacks
against privacy, leading us to redesign our protocols and
refine our definitions of privacy. For example, users are
now either legitimate or illegitimate, and are anonymous
within these sets (see Section 3). This redefinition affects
how a user establishes a “Nymble connection” (see
Section 5.5), and now prevents the server from distinguish-
ing between users who have already connected in the same
time period and those who are blacklisted, resulting in
larger anonymity sets.
A thorough protocol redesign has also resulted in several
optimizations. We have eliminated blacklist version num-
bers and users do not need to repeatedly obtain the current
Fig. 2. The life cycle of a misbehaving user. If the server complains in
time period tc about a user’s connection in tÃ
, the user becomes linkable
starting in tc. The complaint in tc can include nymble tickets from only
tcÀ1 and earlier.

version number from the NM. Instead servers obtain proofs
of freshness every time period, and users directly verify the
freshness of blacklists upon download. Based on a hash-
chain approach, the NM issues lightweight daisies to servers
as proof of a blacklist’s freshness, thus making blacklist
updates highly efficient. Also, instead of embedding seeds,
on which users must perform computation to verify their
blacklist status, the NM now embeds a unique identifier
nymbleÃ
, which the user can directly recognize. Finally, we
have compacted several data structures, especially the
servers’ blacklists, which are downloaded by users in each
connection, and report on the various sizes in detail in
Section 6. We also report on our open-source implementation
of Nymble, completely rewritten as a C library for efficiency.
3 SECURITY MODEL
Nymble aims for four security goals. We provide informal
definitions here; a detailed formalism can be found in our
technical report [16], which explains how these goals must
also resist coalition attacks.
3.1 Goals and Threats
An entity is honest when its operations abide by the system’s
specification. An honest entity can be curious: it attempts to
infer knowledge from its own information (e.g., its secrets,
state, and protocol communications). An honest entity
becomes corrupt when it is compromised by an attacker,
and hence, reveals its information at the time of compro-
mise, and operates under the attacker’s full control, possibly
deviating from the specification.
Blacklistability assures that any honest server can
indeed block misbehaving users. Specifically, if an honest
server complains about a user that misbehaved in the
current linkability window, the complaint will be successful
and the user will not be able to “nymble-connect,” i.e.,
establish a Nymble-authenticated connection, to the server
successfully in subsequent time periods (following the time
of complaint) of that linkability window.
Rate-limiting assures any honest server that no user can
successfully nymble-connect to it more than once within
any single time period.
Nonframeability guarantees that any honest user who is
legitimate according to an honest server can nymble-connect
to that server. This prevents an attacker from framing a
legitimate honest user, e.g., by getting the user blacklisted for
someone else’s misbehavior. This property assumes each
user has a single unique identity. When IP addresses are
used as the identity, it is possible for a user to “frame” an
honest user who later obtains the same IP address. Non-
frameability holds true only against attackers with different
identities (IP addresses).
A user is legitimate according to a server if she has not
been blacklisted by the server, and has not exceeded the rate
limit of establishing Nymble connections. Honest servers
must be able to differentiate between legitimate and
illegitimate users.
Anonymity protects the anonymity of honest users,
regardless of their legitimacy according to the (possibly
corrupt) server; the server cannot learn any more informa-
tion beyond whether the user behind (an attempt to make) a
nymble connection is legitimate or illegitimate.
3.2 Trust Assumptions
We allow the servers and the users to be corrupt and
controlled by an attacker. Not trusting these entities is
important because encountering a corrupt server and/or
user is a realistic threat. Nymble must still attain its goals
under such circumstances. With regard to the PM and NM,
Nymble makes several assumptions on who trusts whom to
be how for what guarantee. We summarize these trust
assumptions as a matrix in Fig. 3. Should a trust assumption
become invalid, Nymble will not be able to provide the
corresponding guarantee.
For example, a corrupt PM or NM can violate Black-
listability by issuing different pseudonyms or credentials to
blacklisted users. A dishonest PM (resp., NM) can frame a
user by issuing her the pseudonym (resp., credential) of
another user who has already been blacklisted. To under-
mine the Anonymity of a user, a dishonest PM (resp., NM)
can first impersonate the user by cloning her pseudonym
(resp., credential) and then attempt to authenticate to a
server—a successful attempt reveals that the user has
already made a connection to the server during the time
period. Moreover, by studying the complaint log, a curious
NM can deduce that a user has connected more than once if
she has been complained about two or more times. As
already described in Section 2.3, the user must trust that at
least the NM or PM is honest to keep the user and server
identity pair private.
4 PRELIMINARIES
4.1 Notation
The notation a 2R S represents an element drawn uniformly
at random from a nonempty set S. NN0 is the set of nonnegative
integers, and NN is the setNN0nf0g. s½iŠis theithelement of list s.
skt is the concatenation of (the unambiguous encoding of)
lists s and t. The empty list is denoted by ;. We sometimes
treat lists of tuples as dictionaries. For example, if L is the list
((Alice, 1234), (Bob, 5678)), then L[Bob] denotes the tuple
(Bob, 5678). If A is an (possibly probabilistic) algorithm, then
AðxÞ denotes the output when A is executed given the
input x. a :¼ b means that b is assigned to a.
4.2 Cryptographic Primitives
Nymble uses the following building blocks (concrete
instantiations are suggested in Section 6):
. Secure cryptographic hash functions. These are one-
way and collision-resistant functions that resemble
random oracles [5]. Denote the range of the hash
functions by H.
Fig. 3. Who trusts whom to be how for what guarantee.

. Secure message authentication (MA) [3]. These consist
of the key generation (MA.KeyGen), and the message
authentication code (MAC) computation (MA.Mac)
algorithms. Denote the domain of MACs by M.
. Secure symmetric-key encryption (Enc) [4]. These
consist of the key generation (Enc.KeyGen), encryp-
tion (Enc.Encrypt), and decryption (Enc.Decrypt)
algorithms. Denote the domain of ciphertexts by À.
. Secure digital signatures (Sig) [22]. These consist of
the key generation (Sig.KeyGen), signing (Sig.Sign),
and verification (Sig.Verify) algorithms. Denote the
domain of signatures by Æ.
4.3 Data Structures
Nymble uses several important data structures:
4.3.1 Pseudonyms
The PM issues pseudonyms to users. A pseudonym pnym
has two components nym and mac: nym is a pseudorandom
mapping of the user’s identity (e.g., IP address),7
the
linkability window w for which the pseudonym is valid,
and the PM’s secret key nymKeyP ; mac is a MAC that the
NM uses to verify the integrity of the pseudonym.
Algorithms 1 and 2 describe the procedures of creating
and verifying pseudonyms.
Algorithm 1. PMCreatePseudonym
Input: ðuid; wÞ 2 H Â NN
Persistent state: pmState 2 SP
Output: pnym 2 P
1: Extract nymKeyP ; macKeyNP from pmState
2: nym :¼ MA:Macðuidkw; nymKeyP Þ
3: mac :¼ MA:Macðnymkw; macKeyNP Þ
4: return pnym :¼ ðnym; macÞ
Algorithm 2. NMVerifyPseudonym
Input: ðpnym; wÞ 2 P Â NN
Persistent state: nmState 2 SN
Output: b 2 ftrue; falseg
1: Extract macKeyNP from nmState
2: ðnym; macÞ :¼ pnym
3: return mac ¼
?
MA:Macðnymkw; macKeyNP Þ
4.3.2 Seeds and Nymbles
A nymble is a pseudorandom number, which serves as an
identifier for a particular time period. Nymbles (presented
by a user) across periods are unlinkable unless a server has
blacklisted that user. Nymbles are presented as part of a
nymble ticket, as described next.
As shown in Fig. 4, seeds evolve throughout a linkability
window using a seed-evolution function f; the seed for the
next time period (seednext) is computed from the seed for
the current time period (seedcur) as
seednext ¼ fðseedcurÞ:
The nymble (nymblet) for a time period t is evaluated by
applying the nymble evaluation function g to its correspond-
ing seed (seedt), i.e.,
nymblet ¼ gðseedtÞ:
The NM sets seed0 to a pseudorandom mapping of the
user’s pseudonym pnym, the (encoded) identity sid of the
server (e.g., domain name), the linkability window w for
which the seed is valid, and the NM’s secret key seedKeyN .
Seeds are therefore specific to user-server-window combi-
nations. As a consequence, a seed is useful only for a
particular server to link a particular user during a particular
linkability window.
In our Nymble construction, f and g are two distinct
cryptographic hash functions. Hence, it is easy to compute
future nymbles starting from a particular seed by applying
f and g appropriately, but infeasible to compute nymbles
otherwise. Without a seed, the sequence of nymbles appears
unlinkable, and honest users can enjoy anonymity. Even
when a seed for a particular time period is obtained, all the
nymbles prior to that time period remain unlinkable.
4.3.3 Nymble Tickets and Credentials
A credential contains all the nymble tickets for a particular
linkability window that a user can present to a particular
server. Algorithm 3 describes the following procedure of
generating a credential upon request: A ticket contains a
nymble specific to a server, time period, and linkability
window. ctxt is encrypted data that the NM can use during
a complaint involving the nymble ticket. In particular, ctxt
contains the first nymble (nymbleÃ
) in the user’s sequence of
nymbles, and the seed used to generate that nymble. Upon
a complaint, the NM extracts the user’s seed and issues it to
the server by evolving the seed, and nymbleÃ
helps the NM
to recognize whether the user has already been blacklisted.
Algorithm 3. NMCreateCredential
Input: ðpnym; sid; wÞ 2 P Â H Â NN
Output: cred 2 D
1: Extract macKeyNS; macKeyN ; seedKeyN ; encKeyN from
keys in nmState
2: seed0 :¼ fðMacðpnymksidkw; seedKeyN ÞÞ
3: nymbleÃ
:¼ gðseed0Þ
4: for t from 1 to L do
5: seedt :¼ fðseedtÀ1Þ
6: nymblet :¼ gðseedtÞ
7: ctxtt :¼ Enc:EncryptðnymbleÃ
kseedt; encKeyN Þ
8: ticket0
t :¼ sidktkwknymbletkctxtt
9: macN;t :¼ MA:Macðticket0
t; macKeyN Þ
10: macNS;t :¼ MA:Macðticket0
tkmacN;t; macKeyNSÞ
11: tickets½tŠ :¼ ðt; nymblet; ctxtt; macN;t; macNS;tÞ
12: return cred :¼ ðnymbleÃ
; ticketsÞ
Fig. 4. Evolution of seeds and nymbles. Given seedi, it is easy to
compute nymblei; nymbleiþ1; . . . ; nymbleL, but not nymbleÃ
; nymble1; . . . ;
nymbleiÀ1.
7. In Nymble, identities (users’ and servers’) are encoded into a fixed-
length string using a cryptographic hash function.

The MACs macN and macNS are used by the NM and the
server, respectively, to verify the integrity of the nymble
ticket, as described in Algorithms 4 and 5. As will be
explained later, the NM will need to verify the ticket’s
integrity upon a complaint from the server.
Algorithm 4. NMVerifyTicket
Input: ðsid; t; w; ticketÞ 2 H Â NN2
Â T
Persistent state: svrState
1: Extract macKeyN from keys in nmState
2: ðÁ; nymble; ctxt; macN ; macNSÞ :¼ ticket
3: content :¼ sidktkwknymblekctxt
4: return macN ¼
?
MA:Macðcontent; macKeyN Þ
Algorithm 5. ServerVerifyTicket
Input: ðt; w; ticketÞ 2 NN2
Â T
Persistent state: svrState
1: Extract sid; macKeyNS from svrState
2: ðÁ; nymble; ctxt; macN ; macNSÞ :¼ ticket
3: content :¼ sidktkwknymblekctxtkmacN
4: return macNS ¼
?
MA:Macðcontent; macKeyNSÞ
4.3.4 Blacklists
A server’s blacklist is a list of nymbleÃ
s corresponding to all
the nymbles that the server has complained about. Users
can quickly check their blacklisting status at a server by
checking to see whether their nymbleÃ
appears in the
server’s blacklist (see Algorithm 6).
Algorithm 6. UserCheckIfBlacklisted
Input: ðsid; blistÞ 2 H Â Bn, n; ‘ 2 NN0
Persistent state: usrState 2 SU
1: Extract nymbleÃ
from cred in usrEntries½sidŠ in usrState
2: return ðnymbleÃ
2
?
blistÞ
Blacklist integrity. It is important for users to be able to
check the integrity and freshness of blacklists, because,
otherwise, servers could omit entries or present older
blacklists and link users without their knowledge. The NM
signs the blacklist (see Algorithm 7), along with the server
identity sid, the current time period t, current linkability
window w, and target (used for freshness, explained soon),
using its signing key signKeyN . As will be explained later,
during a complaint procedure, the NM needs to update
the server’s blacklist, and thus needs to check the integrity
of the blacklist presented by the server. To make this
operation more efficient, the NM also generates an MAC
using its secret key macKeyN (line 7). At the end of the
signing procedure, the NM returns a blacklist certificate
(line 7), which contains the time period for which the
certificate was issued, a daisy (used for freshness,
explained soon), mac, and sig. Algorithms 8 and 9 describe
how users and the NM can verify the integrity and
freshness of blacklists.
Algorithm 7. NMSignBL
Input: ðsid; t; w; target; blistÞ 2 H Â NN2
Â H Â Bn, n 2 NN0
Output: cert 2 C
1: Extract macKeyN ; signKeyN from keys in nmState
2: content :¼ sidktkwktargetkblist
3: mac :¼ MA:Macðcontent; macKeyN Þ
4: sig :¼ Sig:Signðcontent; signKeyN Þ
5: daisy :¼ target
6: return cert :¼ ðt; daisy; t; mac; sigÞ
Algorithm 8. VerifyBL
Input: ðsid; t; w; blist; certÞ 2 H Â NN2
Â Bn Â C, n 2 NN0
1: ðtd; daisy; ts; mac; sigÞ :¼ cert
2: if td 6¼ t _ td < ts then
3: return false
4: target :¼ hðtdÀtsÞ
ðdaisyÞ
5: content :¼ sidktskwktargetkblist
6: return Sig:Verifyðcontent; sig; verKeyN Þ
Algorithm 9. NMVerifyBL
Input: ðsid; t; w; blist; certÞ 2 H Â NN2
Â Bn Â C, n 2 NN0
1-6: Same as lines 1-6 in VerifyBL
7: Extract macKeyN from keys in nmState
8: return mac ¼
?
MA:Macðcontent; macKeyN Þ
Blacklist freshness. If the NM has signed the blacklist
for the current time period, users can simply verify the
digital signature in the certificate to infer that the blacklist
is both valid (not tampered with) and fresh (since the
current time period matches the time period in the
blacklist certificate). To prove the freshness of blacklists
every time period, however, the servers would need to get
the blacklists digitally signed every time period, thus
imposing a high load on the NM. To speed up this process,
we use a hash chain [20], [29] to certify that “blacklist from
time period t is still fresh.”
As illustrated in Fig. 5, for each complaint, the NM
generates a new random seed daisyL for a hash chain
corresponding to time period L. It then computes
daisyLÀ1; daisyLÀ2; . . . ; daisyt up to current time period t
by successively hashing the previous daisy to generate the
next with a cryptographic hash function h. For example,
daisy5 ¼ hðdaisy6Þ.
As outlined later (in Algorithm 13), target is set to daisyt.
Now, until the next update to the blacklist, the NM need
only release daisies for the current time period instead of
digitally signing the blacklist. Given a certificate from an
older time period and daisyt for current time period t, users
can verify the integrity and freshness of the blacklist by
computing the target from daisyt.
Fig. 5. Given daisyi, it is easy to verify the freshness of the blacklist by
applying hi times to obtain target. Only the NM can compute the next
daisyiþ1 in the chain.

4.3.5 Complaints and Linking Tokens
A server complains to the NM about a misbehaving user by
submitting the user’s nymble ticket that was used in the
offending connection. The NM returns a seed, from which
the server creates a linking token, which contains the seed
and the corresponding nymble.
Each server maintains a list of linking tokens in a
linking list, and updates each token on the list every time
period. When a user presents a nymble ticket, the server
checks the nymble within the ticket against the nymbles in
the linking-list entries. A match indicates that the user has
been blacklisted.
4.4 Communication Channels
Nymble utilizes three types of communication channels,
namely, type-Basic, -Auth, and -Anon (Fig. 6).
We assume that a public-key infrastructure (PKI) such as
X.509 is in place, and that the NM, the PM, and all the servers
in Nymble have obtained a PKI credential from a well-
established and trustworthy CA. (We stress that the users in
Nymble, however, need not possess a PKI credential.) These
entities can thus realize type-Basic and type-Auth channels to
one another by setting up a TLS8
connection using their
PKI credentials.
All users can realize type-Basic channels to the NM, the
PM, and any server, again by setting up a TLS connection.
Additionally, by setting up a TLS connection over the Tor
anonymizing network,9
users can realize a type-Anon
channel to the NM and any server.
5 OUR NYMBLE CONSTRUCTION
5.1 System Setup
During setup, the NM and the PM interact as follows:
1. The NM executes NMInitStateðÞ (see Algorithm 10)
and initializes its state nmState to the algorithm’s
output.
2. The NM extracts macKeyNP from nmState and
sends it to the PM over a type-Auth channel.
macKeyNP is a shared secret between the NM and
the PM, so that the NM can verify the authenticity of
pseudonyms issued by the PM.
3. The PM generates nymKeyP by running Mac.Key-
Gen() and initializes its state pmState to the pair
ðnymKeyP ; macKeyNP Þ.
4. The NM publishes verKeyN in nmState in a way
that the users in Nymble can obtain it and verify its
integrity at any time (e.g., during registration).
Algorithm 10. NMInitState
Output: nmState 2 SN
1: macKeyNP :¼ Mac:KeyGenðÞ
2: macKeyN :¼ Mac:KeyGenðÞ
3: seedKeyN :¼ Mac:KeyGenðÞ
4: ðencKeyN ; decKeyN Þ :¼ Enc:KeyGenðÞ
5: ðsignKeyN ; verKeyN Þ :¼ Sig:KeyGenðÞ
6: keys :¼ ðmacKeyNP ; macKeyN ; seedKeyN ,
7: encKeyN ; decKeyN ; signKeyN ; verKeyN Þ
8: nmEntries :¼ ;
9: return nmState :¼ ðkeys; nmEntriesÞ
5.2 Server Registration
To participate in the Nymble system, a server with identity
sid initiates a type-Auth channel to the NM, and registers
with the NM according to the Server Registration protocol
below. Each server may register at most once in any
linkability window.
1. The NM makes sure that the server has not already
registered: If ðsid; Á; ÁÞ 2 nmEntries in its nmState, it
terminates with failure; it proceeds otherwise.
2. The NM reads the current time period and linkability
window as tnow and wnow, respectively, and then
obtains an svrState by running (see Algorithm 11)
NMRegisterServernmStateðsid; tnow; wnowÞ:
3. The NM appends svrState to its nmState, sends it to
the Server, and terminates with success.
4. The server, on receiving svrState, records it as its
state, and terminates with success.
Algorithm 11. NMRegisterServer
Input: ðsid; t; wÞ 2 H Â NN2
Output: svrState 2 SS
1: ðkeys; nmEntriesÞ :¼ nmState
2: macKeyNS :¼ Mac:KeyGenðÞ
3: daisyL 2R H
4: nmEntries0
:¼ nmEntrieskðsid; macKeyNS; daisyL; tÞ
5: nmState :¼ ðkeys; nmEntries0
Þ
6: target :¼ hðLÀtþ1Þ
ðdaisyLÞ
7: blist :¼ ;
8: cert :¼ NMSignBLnmStateðsid; t; w; target; blistÞ
9: svrState :¼ ðsid; macKeyNS; blist; cert; ;; ;; ;; tÞ
10: return svrState
In svrState, macKeyNS is a key shared between the NM
and the server for verifying the authenticity of nymble
tickets; timelastUpd indicates the time period when the
blacklist was last updated, which is initialized to tnow, the
current time period at registration.
5.3 User Registration
A user with identity uid must register with the PM once in
each linkability window. To do so, the user initiates a type-
Basic channel to the PM, followed by the User Registration
protocol described below.
1. The PM checks if the user is allowed to register. In
our current implementation, the PM infers the
Fig. 6. Different types of channels utilized in Nymble.
8. The Transport Layer Security Protocol Version 1.2. IETF RFC 5246.
9. While we acknowledge the existence of attacks on Tor’s anonymity,
we assume Tor provides perfect anonymity [21] for the sake of arguing
Nymble’s own anonymity guarantee.

registering user’s IP address from the communica-
tion channel, and makes sure that the IP address
does not belong to a known Tor exit node. If this is
not the case, the PM terminates with failure.
2. Otherwise, the PM reads the current linkability
window as wnow, and runs
pnym :¼ PMCreatePseudonympmStateðuid; wnowÞ:
The PM then gives pnym to the user, and terminates
with success.
3. The user, on receiving pnym, sets her state usrState
to ðpnym; ;Þ, and terminates with success.
5.4 Credential Acquisition
To establish a Nymble connection to a server, a user must
provide a valid ticket, which is acquired as part of a
credential from the NM. To acquire a credential for server
sid during the current linkability window, a registered user
initiates a type-Anon channel to the NM, followed by the
Credential Acquisition protocol below.
1. The user extracts pnym from usrState and sends the
pair ðpnym; sidÞ to the NM.
2. The NM reads the current linkability window as
wnow. It makes sure the user’s pnym is valid: If
NMVerifyPseudonymnmStateðpnym; wnowÞ
returns false, the NM terminates with failure; it
proceeds otherwise.
3. The NM runs
NMCreateCredentialnmStateðpnym; sid; wnowÞ;
which returns a credential cred. The NM sends cred
to the user and terminates with success.
4. The user, on receiving cred, creates usrEntry:¼
ðsid; cred; falseÞ, appends it to its state usrState,
and terminates with success.
5.5 Nymble Connection Establishment
To establish a connection to a server sid, the user initiates a
type-Anon channel to the server, followed by the Nymble
connection establishment protocol described below.
5.5.1 Blacklist Validation
1. The server sends hblist; certi to the user, where blist
is its blacklist for the current time period and cert is
the certificate on blist. (We will describe how the
server can update its blacklist soon.)
2. The user reads the current time period and
linkability window as tðUÞ
now and wðUÞ
now and assumes
these values to be current for the rest of the protocol.
3. For freshness and integrity, the user checks if
VerifyBLusrState
À
sid; tðUÞ
now; wðUÞ
now; blist; cert
Á
¼ true:
If not, she terminates the protocol with failure.
5.5.2 Privacy Check
Since multiple connection establishment attempts by a user
to the same server within the same time period can be
linkable, the user keeps track of whether she has already
disclosed a ticket to the server in the current time period by
maintaining a boolean variable ticketDisclosed for the
server in her state.
Furthermore, since a user who has been blacklisted by a
server can have her connection establishment attempts
linked to her past establishment, the user must make sure
that she has not been blacklisted thus far.
Consequently, if ticketDisclosed in usrEntries½sidŠ in the
user’s usrState is true, or
UserCheckIfBlacklistedusrStateðsid; blistÞ ¼ true;
then it is unsafe for the user to proceed and the user sets safe
to false and terminates the protocol with failure.10
5.5.3 Ticket Examination
1. The user sets ticketDisclosed in usrEntries½sidŠ in
usrState to true. She then sends hticketi to the server,
where ticket is ticket½tðUÞ
nowŠ in cred in usrEntries½sidŠ in
usrState.
Note that the user discloses ticket for time period tðUÞ
now
after verifying blist’s freshness for tðUÞ
now. This proce-
dure avoids the situation in which the user verifies the
current blacklist just before a time period ends, and
then presents a newer ticket for the next time period.
2. On receiving hticketi, the server reads the current
time period and linkability window as tðSÞ
now and wðSÞ
now,
respectively. The server then checks that:
. ticket is fresh, i.e., ticket 62 slist in server’s state.
. ticket is valid, i.e., on input ðtðSÞ
now; wðSÞ
now; ticketÞ,
the algorithm ServerVerifyTicket returns
true. (See Algorithm 5.)
. ticket is not linked (in other words, the user has
not been blacklisted), i.e.,
ServerLinkTicketsvrStateðticketÞ ¼ false:
(See Algorithm 12.)
3. If any of the checks above fails, the server sends
hgoodbyei to the user and terminates with failure.
Otherwise, it adds ticket to slist in its state, sends
hokayi to the user, and terminates with success.
4. On receiving hokayi, the user terminates with success.
Algorithm 12. ServerLinkTicket
Input: ticket 2 T
Persistent state: svrState 2 SS
1: Extract lnkng-tokens from svrState
2: ðÁ; nymble; Á Á ÁÞ :¼ ticket
3: for all i ¼ 1 to jlnkng-tokensj do
4: if ðÁ; nymbleÞ ¼ lnkng-tokens½iŠ then
5: return true
6: return false
5.6 Service Provision and Access Logging
If both the user and the server terminate with success in the
Nymble connection Establishment described above, the server
10. We note that a nymble-authenticated session may be long-lived,
where actions within the session are linkable. It is the establishment of
multiple sessions within a time period that is disallowed.

may start serving the user over the same channel. The
server records ticket and logs the access during the session
for a potential complaint in the future.
5.7 Auditing and Filing for Complaints
If at some later time, the server desires to blacklist the user
behind a Nymble connection, during the establishment of
which the server collected ticket from the user, the server
files a complaint by appending ticket to cmplnt-tickets in its
svrState.
Filed complaints are batched up. They are processed
during the next blacklist update (to be described next).
5.8 Blacklist Update
Servers update their blacklists for the current time period
for two purposes. First, as mentioned earlier, the server
needs to provide the user with its blacklist (and blacklist
certificate) for the current time period during a Nymble
connection establishment. Second, the server needs to be
able to blacklist the misbehaving users by processing the
newly filed complaints (since last update).
The procedure for updating blacklists (and their
certificates) differs depending on whether complaints are
involved. When there is no complaint (i.e., the server’s
cmplnt-tickets is empty), blacklists stay unchanged; the
certificates need only a “light refreshment.” When there
are complaints, on the other hand, new entries are added
to the blacklists and certificates need to be regenerated.
Since these updates are certified for integrity and freshness
at the granularity of time periods, multiple updates within
a single time period are disallowed (otherwise, servers
could send users stale blacklists).
Our current implementation employs “lazy” update: the
server updates its blacklist upon its first Nymble connection
establishment request in a time period.
5.8.1 Without Complaints
1. The server with identity sid initiates a type-Auth
channel to the NM, and sends a request to the NM
for a blacklist update.
2. The NM reads the current time period as tnow. It
extracts tlastUpd and daisyL from nmEntry for sid in
nmState. If tlastUpd is tnow, the server has already
updated its blacklist for the current time period, and
the NM terminates the protocol as failure.
3. Otherwise, the NM updates tlastUpd to tnow. It
computes daisy0
:¼ hðLÀtnowþ1Þ
ðdaisyLÞ and sends
ðtnow; daisy0
Þ to the server.
4. The server replaces td and daisy in cert in blist in its
svrState with tnow and daisy0
, respectively.
5.8.2 With Complaints
1. The server with identity sid initiates a type-Auth
channel to the NM and sends ðblist; cert; cmplnt-
ticketsÞ from its svrState as a blacklist update request.
2. The NM reads the current time period as tðNÞ
now. It runs
NMHandleComplaintsnmState
on input ðsid; tnow; wnow; blist; cert; cmplnt-ticketsÞ.
(See Algorithm 15.) If the algorithm returns ?, the
NM considers the update request invalid, in which
case the NM terminates the protocol as failure.
3. Otherwise, the NM relays the algorithm’s output
ðblist0
; cert0
; seedsÞ, to the server.
4. The server updates its state svrState as follows: It
replaces blist and cert with blistkblist0
and cert0
,
respectively, and sets cmplnt-tkts to ;. For each
seed 2 seeds, the server creates a token as ðseed;
gðseedÞÞ and appends it to lnkng-tokens. Finally, the
server terminates with success.
We now explain what NMHandleComplaints does. The
algorithm first checks the integrity and freshness of the
blacklist (lines 2-6) and that the NM hasn’t already updated
theserver’sblacklistforthecurrenttimeperiod.Itthenchecks
if all complaints are valid for some previous time period
duringthecurrentlinkabilitywindow(lines7-12).Finally,the
algorithm prepares an answer to the update request by
invoking NMComputeBLUpdate and NMComputeSeeds (see
Algorithm 14) (lines 13-16).
NMComputeBLUpdate (see Algorithm 13) creates new
entries to be appended to the server’s blacklist. Each entry
is either the actual nymbleÃ
of the user being complained
about if the user has not been blacklisted already, or a random
nymble otherwise. This way, the server cannot learn if two
complaints are about the same user, and thus, cannot link the
Nymble connections to the same user. NMComputeSeeds (see
Algorithm 14) uses the same trick when computing a seed
that enables the server to link a blacklisted user.
Algorithm 13. NMComputeBLUpdate
Input: ðsid; t; w; blist; cmplnt-ticketsÞ 2 H Â NN2
Â Bn Â T m
Output: ðblist0
; cert0
Þ 2 Bm Â C
1: ðkeys; nmEntriesÞ :¼ nmState
2:
Á; macKeyN ; seedKeyN ;
encKeyN ; Á; signKeyN ; Á

:¼ keys
3: for i ¼ 1 to m do
4: ðÁ; Á; ctxt; Á; ÁÞ :¼ cmplnt-tickets½iŠ
5: nymbleÃ
kseed :¼ Decryptðctxt; decKeyN Þ
6: if nymbleÃ
2 blist then
7: blist0
½iŠ 2R H
8: else
9: blist0
½iŠ :¼ nymbleÃ
10: daisy0
L 2R H
11: target0
:¼ hðLÀtþ1Þ
ðdaisy0
LÞ
12: cert0
:¼ NMSignBLðsid; t; w; target0
; blistkblist0
Þ
13: Replace daisyL and tlastUpd in nmEntries½sidŠ in
nmState with daisy0
L and by t, respectively
14: return ðblist0
; cert0
Þ
Algorithm 14. NMComputeSeeds
Input: ðt; blist; cmplnt-ticketsÞ 2 NN Â Bn Â T m
Output: seeds 2 Hm
1: Extract decKeyN from keys in nmState
2: for all i ¼ 1 to m do
3: ðt0
; nymble; ctxt; Á Á ÁÞ :¼ cmplnt-tickets½iŠ
4: nymbleÃ
kseed :¼ Enc:Decryptðctxt; decKeyN Þ
5: if nymbleÃ
2 blist then

6: seeds½iŠ 2R H
7: else
8: seeds½iŠ :¼ fðtÀt0
Þ
ðseedÞ
9: return seeds
5.9 Periodic Update
5.9.1 Per Time Period
At the end of each time period that is not the last of the
current linkability window, each registered server updates
its svrState by running (see Algorithm 7)
ServerUpdateStatesvrStateðÞ;
which prepares the linking token list for the new time
period. Each entry is updated by evolving the seed and
computing the corresponding nymble.
Each registered user sets ticketDisclosed in every
usrEntry in usrState to false, signaling that the user has
not disclosed any ticket in the new time period.
5.9.2 Per Linkability Window
At the beginning of each linkability window, all the entities,
i.e., the PM, the NM, the servers, and the users erase their
state and start afresh. In other words, the NM and the PM
must resetup Nymble for the new current linkability
window and all servers and users must reregister if they
still want to use Nymble.
Algorithm 15. NMHandleComplaints
Input: ðsid; t; w; blist; cert; cmplnt-ticketsÞ 2 H Â NN2
Â
Bn Â C Â T m
Output: ðblist0
; cert0
; seedsÞ 2 Bm Â C Â Hm
1: Extract timelastUpd from nmEntries½sidŠ in nmState
2: b1 :¼ ðtimelastUpd tÞ
3: b2 :¼
4: NMVerifyBLnmStateðsid; timelastUpd; w; blist; certÞ
5: if :ðb1 ^ b2Þ then
6: return ?
7: for all i ¼ 1 to m do
8: ticket :¼ cmplnt-tickets½iŠ; ð~t; Á Á ÁÞ :¼ ticket
9: bi1 :¼ ~t t
10: bi2 :¼ NMVerifyTicketnmStateðsid;~t; w; ticketÞ
11: if :ðbi1 ^ bi2Þ then
12: return ?
13: ðblist0
; cert0
Þ :¼
14: NMComputeBLUpdatenmStateðsid; t; w; blist; certÞ
15: seeds :¼
16: NMComputeSeedsnmStateðt; blist; cmplnt-ticketsÞ
17: return ðblist0
; cert0
; seedsÞ
Algorithm 16. ServerUpdateState
Persistent state: svrState 2 SS
1: Extract lnkng-tokens from svrState
2: for all i ¼ 1 to jlnkng-tokensj do
3: ðseed; nymbleÞ :¼ lnkng-tokens½iŠ
4: seed0
:¼ fðseedÞ; nymble0
:¼ gðseed0
Þ
5: tokens0
½iŠ :¼ ðseed0
; nymble0
Þ
6: Replace lnkng-tokens in svrState with tokens0
7: Replace seen-tickets in svrState with ;
6 PERFORMANCE EVALUATION
We implemented Nymble and collected various empirical
performance numbers, which verify the linear (in the
number of “entries” as described below) time and space
costs of the various operations and data structures.
6.1 Implementation and Experimental Setup
We implemented Nymble as a C++ library along with Ruby
and JavaScript bindings. One could, however, easily
compile bindings for any of the languages (such as Python,
PHP, and Perl) supported by the Simplified Wrapper and
Interface Generator (SWIG), for example. We utilize
OpenSSL for all the cryptographic primitives.
We use SHA-256 for the cryptographic hash functions;
HMAC-SHA-256 for the message authentication MA;
AES-256 in CBC-mode for the symmetric encryption
Enc; and 2,048-bit RSASSA-PSA for the digital signatures
Sig. We chose RSA over DSA for digital signatures
because of its faster verification speed—in our system,
verification occurs more often than signing.
We evaluated our system on a 2.2 GHz Intel Core 2 Duo
Macbook Pro with 4 GB of RAM. The PM, the NM, and the
server were implemented as Mongrel (Ruby’s version of
Apache) servers. The user portion was implemented as a
Firefox 3 extension in JavaScript with XPCOM bindings to the
Nymble C++ library. For each experiment relating to protocol
performance, we report the average of 10 runs. The evalua-
tion of data structure sizes is the byte count of the marshaled
data structures that would be sent over the network.
6.2 Experimental Results
Fig. 7 shows the size of the various data structures. The
X-axis represents the number of entries in each data
structure—complaints in the blacklist update request, tickets
in the credential (equal to L, the number of time periods in a
linkability window), nymbles in the blacklist, tokens and
seeds in the blacklist update response, and nymbles in the
blacklist. For example, a linkability window of one day with
five minute time periods equates to L ¼ 288.11
The size of a
11. The security-related tradeoffs for this parameter are discussed in
Section 2.4. The performance tradeoffs are apparent in this section (see
Figs. 7 and 8a for credential size and acquisition times).
Fig. 7. The marshaled size of various Nymble data structures. The
X-axis refers to the number of entries—complaints in the blacklist update
request, tickets in the credential, tokens and seeds in the blacklist
update response, and nymbles in the blacklist.

credential in this case is about 59 KB. The size of a blacklist
update request with 50 complaints is roughly 11 KB,
whereas the size of a blacklist update response for
50 complaints is only about 4 KB. The size of a blacklist
(downloaded by users before each connection) with
500 nymbles is 17 KB.
In general, each structure grows linearly as the number
of entries increases. Credentials and blacklist update
requests grow at the same rate because a credential is a
collection of tickets which is more or less what is sent as a
complaint list when the server wishes to update its blacklist.
In our implementation, we use Google’s Protocol Buffers to
(un)marshal these structures because it is cross-platform
friendly and language-agnostic.
Fig. 8a shows the amount of time it takes the NM to
perform various protocols. It takes about 9 ms to create a
credential when L ¼ 288. Note that this protocol occurs only
once in every linkability window for each user wanting to
connect to a particular server. For blacklist updates, the initial
jump in the graph corresponds to the fixed overhead
associated with signing a blacklist. To execute the update
blacklist protocol with 500 complaints, it takes the NM about
54 ms. However, when there are no complaints, it takes the
NM on average less than a millisecond to update the daisy.
Fig. 8b shows the amount of time it takes the server and
user to perform various protocols. These protocols are
relatively inexpensive by design, i.e., the amount of
computation performed by the users and servers should be
minimal. For example, it takes less than 3 ms for a user to
execute a security check on a blacklist with 500 nymbles.
Note that this figure includes signature verification as well,
and hence, the fixed-cost overhead exhibited in the graph.
It takes less than a millisecond for a server to perform
authentication of a ticket against a blacklist with 500 nymbles.
Every time period (e.g., every five minutes), a server must
update its state and blacklist. Given a linking list with
500 entries, the server will spend less than 2 ms updating the
linking list. If the server were to issue a blacklist update
request with 500 complaints, it would take less than 3 ms for
the server to update its blacklist.
To measure the latency perceived by an authenticating
user, we simulated a client authenticating to a server with
500 blacklist entries. We simulated two scenarios, with the
PM, NM, and server (a) on the local network and (b) on a
remote machine (48 ms round-trip time).12
On average, it
took a total of 470 ms for the full protocol on the local
network and 2,001 ms for the remote case: acquiring a
pseudonym (87 ms local; 307 ms remote) and credential
(107 ms; 575 ms), acquiring the blacklist and the server
checking if the user is blacklisted (179 ms; 723 ms), and
finally authenticating (97 ms; 295 ms).13
7 SECURITY ANALYSIS
Theorem 1. Our Nymble construction has Blacklistability,
Rate-limiting, Nonframeability, and Anonymity provided
that the trust assumptions in Section 3.2 hold true, and the
cryptographic primitives used are secure.
We summarize the proof of Theorem 1. Please refer to
our technical report [16] for a detailed version.
7.1 Blacklistability
An honest PM and NM will issue a coalition of c unique
users at most c valid credentials for a given server. Because
of the security of HMAC, only the NM can issue valid
tickets, and for any time period, the coalition has at most
c valid tickets, and can thus make at most c connections to
the server in any time period regardless of the server’s
blacklisting. It suffices to show that if each of the c users has
been blacklisted in some previous time period of the current
linkability window, the coalition cannot authenticate in the
current time period kÃ
.
Assume the contrary that connection establishment kÃ
using one of the coalition members’ ticketÃ
was successful
even though the user was blacklisted in a previous time
period k0
. Since connection establishments k0
and kÃ
were
successful, the corresponding tickets ticket0
and ticketÃ
must
be valid. Assuming the security of digital signatures and
HMAC, an honest server can always contact an honest NM
with a valid ticket and the NM will successfully terminate
Fig. 8. Nymble’s performance at (a) the NM and (b) the user and the
server when performing various protocols. (a) Blacklist updates take
several milliseconds and credentials can be generated in 9 ms for the
suggested parameter of L ¼ 288. (b) The bottleneck operation of server
ticket examination is less than 1 ms and validating the blacklist takes the
user only a few ms.
12. The remote machine was a 256 slice from Slicehost running Ubuntu
4.09, and provides an indication of performance on the network.
13. For perspective, we note that with SSL disabled, the total times were
65 ms on the local network and 1,086 ms for the remote case.

during the blacklist update. Since the server blacklisted the
valid ticket0
and updates its linking list honestly, the
ServerLinkTicket will return fail on input ticketÃ
, and
thus, the connection kÃ
must fail, which is a contradiction.
7.2 Nonframeability
Assume the contrary that the adversary successfully framed
honest user iÃ
with respect to an honest server in time
period tÃ
, and thus, user iÃ
was unable to connect in time
period tÃ
using ticketÃ
even though none of his tickets were
previously blacklisted. Because of the security of HMAC,
and since the PM and NM are honest, the adversary cannot
forge tickets for user iÃ
, and the server cannot already have
seen ticketÃ
; it must be that ticketÃ
was linked to an entry in
the linking list. Thus, there exists an entry ðseedÃ
; nymbleÃ
Þ
in the server’s linking list, such that the nymble in ticketÃ
equals nymbleÃ
. The server must have obtained this entry in
a successful blacklist update for some valid ticketb,
implying the NM had created this ticket for some user ~i.
If ~i 6¼ iÃ
, then user ~i’s seed0 is different from user iÃ
’s
seed0 so long as the PM is honest, and yet the two seed0’s
evolve to the same seedÃ
, which contradicts the collision-
resistance property of the evolution function. Thus, we have
~i ¼ iÃ
. But, as already argued, the adversary cannot forge
iÃ
’s ticketb, and it must be the case that iÃ
’s ticketb was
blacklisted before tÃ
, which contradicts our assumption that
iÃ
was a legitimate user in time tÃ
.
7.3 Anonymity
We show that an adversary learns only that some legitimate
user connected or that some illegitimate user’s connection
failed, i.e., there are two anonymity sets of legitimate and
illegitimate users.
Distinguishing between two illegitimate users. We
argue that any two chosen illegitimate users out of the
control of the adversary will react indistinguishably. Since
all honest users execute the Nymble connection Establishment
protocol in exactly the same manner up until the end of the
Blacklist validation stage (Section 5.5.1), it suffices to show
that every illegitimate user will evaluate safe to false, and
hence, terminate the protocol with failure at the end of the
Privacy check stage (Section 5.5.2).
For an illegitimate user (attempting a new connection)
who has already disclosed a ticket during a connection
establishment earlier in the same time period, ticketDisclosed
for the server will have been set to true and safe is evaluated
to false during establishment kÃ
.
An illegitimate user who has not disclosed a ticket
during the same time period must already be blacklisted.
Thus, the server complained about some previous ticketÃ
of
the user. Since the NM is honest, the user’s nymbleÃ
appears
in some previous blacklist of the server. Since an honest NM
never deletes entries from a blacklist, it will appear in all
subsequent blacklists, and safe is evaluated to false for the
current blacklist. Servers cannot forge blacklists or present
blacklists for earlier time periods (as, otherwise, the digital
signature would be forgeable, or the hash in the daisy chain
could be inverted).
Distinguishing between two legitimate users. The
authenticity of the channel implies that a legitimate user
knows the correct identity of the server, and thus, Boolean
ticketDisclosed for the server remains false. Furthermore,
UserCheckIfBlacklisted returns false (assuming the se-
curity of digital signatures) and safe is evaluated to true
for the legitimate user.
Now, in the ticket presented by the user, only nymble
and ctxt are functions of the user’s identity. Since the
adversary does not know the decryption key, the CCA2
security of the encryption implies that ctxt reveals no
information about the user’s identity to the adversary.
Finally, since the server has not obtained any seeds for the
user, under the Random Oracle model, the nymble pre-
sented by the user is indistinguishable from random and
cannot be linked with other nymbles presented by the user.
Furthermore, if and when the server complains about a
user’s tickets in the future, the NM ensures that only one
real seed is issued (subsequent seeds corresponding to the
same user are random values), and thus, the server cannot
distinguish between legitimate users for a particular time
period by issuing complaints in a future time period.
7.4 Across Multiple Linkability Windows
With multiple linkability windows, our Nymble construc-
tion still has Accountability and Nonframeability because each
ticket is valid for and only for a specific linkability window;
it still has Anonymity because pseudonyms are an output of
a collision-resistant function that takes the linkability
window as input.
8 DISCUSSION
IP-address blocking. By picking IP addresses as the
resource for limiting the Sybil attack, our current imple-
mentation closely mimics IP-address blocking employed by
Internet services. There are, however, some inherent limita-
tions to using IP addresses as the scarce resource. If a user
can obtain multiple addresses, she can circumvent both
nymble-based and regular IP-address blocking. Subnet-
based blocking alleviates this problem, and while it is
possible to modify our system to support subnet-based
blocking, new privacy challenges emerge; a more thorough
description is left for future work.
Other resources. Users of anonymizing networks would
be reluctant to use resources that directly reveal their
identity (e.g., passports or a national PKI). Email addresses
could provide more privacy, but provide weak black-
listability guarantees because users can easily create new
email addresses. Other possible resources include client
puzzles [25] and e-cash, where users are required to
perform a certain amount of computation or pay money
to acquire a credential. These approaches would limit the
number of credentials obtained by a single individual by
raising the cost of acquiring credentials.
Server-specific linkability windows. An enhancement
would be to provide support to vary T and L for different
servers. As described, our system does not support varying
linkability windows, but does support varying time
periods. This is because the PM is not aware of the server
the user wishes to connect to, yet it must issue pseudonyms
specific to a linkability window. We do note that the use of
resources such as client puzzles or e-cash would eliminate
the need for a PM, and users could obtain Nymbles directly

from the NM. In that case, server-specific linkability
windows could be used.
Side-channel attacks. While our current implementation
does not fully protect against side-channel attacks, we
mitigate the risks. We have implemented various algo-
rithms in a way that their execution time leaks little
information that cannot already be inferred from the
algorithm’s output. Also, since a confidential channel does
not hide the size of the communication, we have con-
structed the protocols so that each kind of protocol message
is of the same size regardless of the identity or current
legitimacy of the user.
9 CONCLUSIONS
We have proposed and built a comprehensive credential
system called Nymble, which can be used to add a layer of
accountability to any publicly known anonymizing net-
work. Servers can blacklist misbehaving users while
maintaining their privacy, and we show how these proper-
ties can be attained in a way that is practical, efficient, and
sensitive to the needs of both users and services.
We hope that our work will increase the mainstream
acceptance of anonymizing networks such as Tor, which
has, thus far, been completely blocked by several services
because of users who abuse their anonymity.
ACKNOWLEDGMENTS
The authors wish to thank Peter C. Johnson and Daniel
Peebles for their help in the early stages of prototyping.
They are also grateful for the suggestions and help from
Roger Dingledine and Nick Mathewson. This research was
supported in part by the US National Science Foundation,
under grant CNS-0524695, and the Bureau of Justice
Assistance, under grant 2005-DD-BX-1091. The views and
conclusions do-not necessarily reflect the views of the
sponsors. Nymble first appeared in a PET ’07 paper [24].
This paper presents a significantly improved construction
and a complete rewrite and evaluation of our (open-source)
implementation (see Section 2.7 for a summary of changes).
We dedicate this paper to the memory of Patrick Tsang.
REFERENCES
[1] G. Ateniese, J. Camenisch, M. Joye, and G. Tsudik, “A Practical
and Provably Secure Coalition-Resistant Group Signature,
Scheme,” Proc. Ann. Int’l Cryptology Conf. (CRYPTO), Springer,
pp. 255-270, 2000.
[2] G. Ateniese, D.X. Song, and G. Tsudik, “Quasi-Efficient Revoca-
tion in Group Signatures,” Proc. Conf. Financial Cryptography,
Springer, pp. 183-197, 2002.
[3] M. Bellare, R. Canetti, and H. Krawczyk, “Keying Hash Functions
for Message Authentication,” Proc. Ann. Int’l Cryptology Conf.
(CRYPTO), Springer, pp. 1-15, 1996.
[4] M. Bellare, A. Desai, E. Jokipii, and P. Rogaway, “A Concrete
Security Treatment of Symmetric Encryption,” Proc. Ann. Symp.
Foundations in Computer Science (FOCS), pp. 394-403, 1997.
[5] M. Bellare and P. Rogaway, “Random Oracles Are Practical: A
Paradigm for Designing Efficient Protocols,” Proc. First ACM Conf.
Computer and Comm. Security, pp. 62-73, 1993.
[6] M. Bellare, H. Shi, and C. Zhang, “Foundations of Group
Signatures: The Case of Dynamic Groups,” Proc. Cryptographer’s
Track at RSA Conf. (CT-RSA), Springer, pp. 136-153, 2005.
[7] D. Boneh and H. Shacham, “Group Signatures with Verifier-Local
Revocation,” Proc. ACM Conf. Computer and Comm. Security,
pp. 168-177, 2004.
[8] S. Brands, “Untraceable Off-Line Cash in Wallets with Observers
(Extended Abstract),” Proc. Ann. Int’l Cryptology Conf. (CRYPTO),
Springer, pp. 302-318, 1993.
[9] E. Bresson and J. Stern, “Efficient Revocation in Group Signa-
tures,” Proc. Conf. Public Key Cryptography, Springer, pp. 190-206,
2001.
[10] J. Camenisch and A. Lysyanskaya, “An Efficient System for Non-
Transferable Anonymous Credentials with Optional Anonymity
Revocation,” Proc. Int’l Conf. Theory and Application of Cryptographic
Techniques (EUROCRYPT), Springer, pp. 93-118, 2001.
[11] J. Camenisch and A. Lysyanskaya, “Dynamic Accumulators and
Application to Efficient Revocation of Anonymous Credentials,”
Proc. Ann. Int’l Cryptology Conf. (CRYPTO), Springer, pp. 61-76,
2002.
[12] J. Camenisch and A. Lysyanskaya, “Signature Schemes and
Anonymous Credentials from Bilinear Maps,” Proc. Ann. Int’l
Cryptology Conf. (CRYPTO), Springer, pp. 56-72, 2004.
[13] D. Chaum, “Blind Signatures for Untraceable Payments,” Proc.
Ann. Int’l Cryptology Conf. (CRYPTO), pp. 199-203, 1982.
[14] D. Chaum, “Showing Credentials without Identification Trans-
feering Signatures between Unconditionally Unlinkable Pseudo-
nyms,” Proc. Int’l Conf. Cryptology (AUSCRYPT), Springer,
pp. 246-264, 1990.
[15] D. Chaum and E. van Heyst, “Group Signatures,” Proc. Int’l Conf.
Theory and Application of Cryptographic Techniques (EUROCRYPT),
pp. 257-265, 1991.
[16] C. Cornelius, A. Kapadia, P.P. Tsang, and S.W. Smith, “Nymble:
Blocking Misbehaving Users in Anonymizing Networks,” Tech-
nical Report TR2008-637, Dartmouth College, Computer Science,
Dec. 2008.
[17] I. Damga˚rd, “Payment Systems and Credential Mechanisms with
Provable Security Against Abuse by Individuals,” Proc. Ann. Int’l
Cryptology Conf. (CRYPTO), Springer, pp. 328-335, 1988.
[18] R. Dingledine, N. Mathewson, and P. Syverson, “Tor: The Second-
Generation Onion Router,” Proc. Usenix Security Symp., pp. 303-
320, Aug. 2004.
[19] J.R. Douceur, “The Sybil Attack,” Proc. Int’l Workshop on Peer-to-
Peer Systems (IPTPS), Springer, pp. 251-260, 2002.
[20] S. Even, O. Goldreich, and S. Micali, “On-Line/Off-Line Digital
Schemes,” Proc. Ann. Int’l Cryptology Conf. (CRYPTO), Springer,
pp. 263-275, 1989.
[21] J. Feigenbaum, A. Johnson, and P.F. Syverson, “A Model of Onion
Routing with Provable Anonymity,” Proc. Conf. Financial Crypto-
graphy, Springer, pp. 57-71, 2007.
[22] S. Goldwasser, S. Micali, and R.L. Rivest, “A Digital Signature
Scheme Secure Against Adaptive Chosen-Message Attacks,”
SIAM J. Computing, vol. 17, no. 2, pp. 281-308, 1988.
[23] J.E. Holt and K.E. Seamons, “Nym: Practical Pseudonymity for
Anonymous Networks,” Internet Security Research Lab Technical
Report 2006-4, Brigham Young Univ., June 2006.
[24] P.C. Johnson, A. Kapadia, P.P. Tsang, and S.W. Smith, “Nymble:
Anonymous IP-Address Blocking,” Proc. Conf. Privacy Enhancing
Technologies, Springer, pp. 113-133, 2007.
[25] A. Juels and J.G. Brainard, “Client Puzzles: A Cryptographic
Countermeasure Against Connection Depletion Attacks,” Proc.
Network and Distributed System Security Symp. (NDSS), 1999.
[26] A. Kiayias, Y. Tsiounis, and M. Yung, “Traceable Signatures,”
Proc. Int’l Conf. Theory and Application of Cryptographic Techniques
(EUROCRYPT), Springer, pp. 571-589, 2004.
[27] B.N. Levine, C. Shields, and N.B. Margolin, “A Survey of
Solutions to the Sybil Attack,” Technical Report 2006-052, Univ.
of Massachusetts, Oct. 2006.
[28] A. Lysyanskaya, R.L. Rivest, A. Sahai, and S. Wolf, “Pseudonym
Systems,” Proc. Conf. Selected Areas in Cryptography, Springer,
pp. 184-199, 1999.
[29] S. Micali, “NOVOMODO: Scalable Certificate Validation and
Simplified PKI Management,” Proc. First Ann. PKI Research
Workshop, Apr. 2002.
[30] T. Nakanishi and N. Funabiki, “Verifier-Local Revocation Group
Signature Schemes with Backward Unlinkability from Bilinear
Maps,” Proc. Int’l Conf. Theory and Application of Cryptology and
Information Security (ASIACRYPT), Springer, pp. 533-548, 2005.

[31] L. Nguyen, “Accumulators from Bilinear Pairings and Applica-
tions,” Proc. Cryptographer’s Track at RSA Conf. (CT-RSA), Springer,
pp. 275-292, 2005.
[32] I. Teranishi, J. Furukawa, and K. Sako, “k-Times Anonymous
Authentication (Extended Abstract),” Proc. Int’l Conf. Theory and
Application of Cryptology and Information Security (ASIACRYPT),
Springer, pp. 308-322, 2004.
[33] P.P. Tsang, M.H. Au, A. Kapadia, and S.W. Smith, “Black-
listable Anonymous Credentials: Blocking Misbehaving Users
without TTPs,” Proc. 14th ACM Conf. Computer and Comm.
Security (CCS ’07), pp. 72-81, 2007.
[34] P.P. Tsang, M.H. Au, A. Kapadia, and S.W. Smith, “PEREA:
Towards Practical TTP-Free Revocation in Anonymous Authenti-
cation,” Proc. ACM Conf. Computer and Comm. Security, pp. 333-
344, 2008.
Patrick P. Tsang was a PhD student in the
Computer Science program at Dartmouth Col-
lege, and passed away on October 27, 2009 as
a victim to cancer. He was 28 years old. His
research interests spanned security and trust in
computers and networks, privacy-enhancing
technologies and applied cryptography. He
was particularly interested in developing scal-
able security and privacy solutions for resource-
constrained environments. He was a member
of the International Association for Cryptologic Research (IACR).
Patrick was a disciplined and cheerful student, and he battled his
illness with strength and courage. Even in those final moments, he was
busy extending ideas presented in this paper. We dedicate this paper
to his memory.
Apu Kapadia received the PhD degree from the
University of Illinois at Urbana-Champaign and a
four-year High-Performance Computer Science
Fellowship from the Department of Energy for
the dissertation research. Following the docto-
rate, he joined Dartmouth College as a post-
doctoral research fellow with the Institute for
Security Technology Studies, and then was a
member of technical staff at MIT Lincoln Labora-
tory. He joined Indiana University, Bloomington,
as an assistant professor in the School of Informatics and Computing in
2009. He is an active researcher in security and privacy and is
particularly interested in anonymizing networks, usable security, security
in peer-to-peer and mobile networks, and applied cryptography. He is a
member of the IEEE, the IEEE Computer Society, and the ACM.
Cory Cornelius is working toward the PhD
degree in the Computer Science Department at
Dartmouth College. His research interests in-
clude security, privacy, networks, and, in parti-
cular, the intersection of these fields.
Sean W. Smith was educated at Princeton and
CMU. He has been active in information security
even before the inception of the Web. Previously
a research scientist at Los Alamos National
Laboratory and at IBM, he joined Dartmouth
College in 2000. He has published two books;
been granted more than a dozen patents; and
advised over three dozen PhD, MS, and senior
honors theses. He is a member of Phi Beta
Kappa and Sigma Xi.
. For more information on this or any other computing topic,
please visit our Digital Library at www.computer.org/publications/dlib.

Nymble blocking misbehaviouring users in anonymizing networks

More Related Content

What's hot (15)

Viewers also liked (13)

Similar to Nymble blocking misbehaviouring users in anonymizing networks (20)

More from Muthu Samy (9)

Recently uploaded (20)

Nymble blocking misbehaviouring users in anonymizing networks