Implementation of an Authenticated Dictionary with Skip Lists and Commutative Hashing

Michael T. Goodrich Department of Computer Science Johns Hopkins University Baltimore, Maryland 21218
goodrich@[Link]

Roberto Tamassia Andrew Schwerin Department of Computer Science Brown University Providence, Rhode Island 02912

rt,schwerin @[Link]

Abstract
We present the software architecture and implementation of an efcient data structure for dynamically maintaining an authenticated dictionary. The building blocks of the data structure are skip lists and one-way commutative hash functions. We also present the results of a preliminary experiment on the performance of the data structure. Applications of our work include certicate revocation in public key infrastructure and the publication of data collections on the Internet.

veries the proof by relying solely on its trust in the source and the availability of public information about the source that allows to check the sources signature. The data structure used by the directory to maintain set , together with the protocol for queries and updates is called an authenticated dictionary [18, 29]. Figure 1 shows a schematic view of an authenticated dictionary.

query source update auth. info directory answer auth. info user

Figure 1. Authenticated dictionary.

1. Introduction
We present the software architecture and implementation of an efcient and practical data structure for dynamically maintaining a distributed collection of elements in an authenticated manner. Applications of our work include certicate revocation in public key infrastructure and authenticated publication of data collections on the Internet. The problem we address involves three parties: a trusted source, an untrusted directory, and a user. The source of elements that evolves over time denes a nite set through insertions and deletions of elements. The directory maintains a copy of set . It receives time-stamped updates from the source together with update authentication information, such as signed statements about the update and the current elements of the set. The user performs membership queries on the set of the type is element in set ? but instead of contacting the source directly, it queries the directory. The directory provides the user with a yes/no answer to the query together with answer authentication information, which yields a proof of the answer assembled by combining statements signed by the source. The user then
Research supported in part by DARPA Grant F306020020509.

1.1 Design Goals

The design of an authenticated dictionary should address the following goals:

low computational cost: the computations performed internally by each entity (source, directory, and user) should be simple and fast; also, the memory space used by the data structures supporting the computation should be as small as possible;

low communication overhead: source-to-directory communication (update authentication information) and directory-to-user communication (answer authentication information) should be kept as small as possible;

high security: the authenticity of the data provided by a directory should be veriable with a high degree of reliability.

1.2 Metrics and Applications

We can formalize the above goals as the algorithmic problem of minimizing the following cost parameters of an authenticated dictionary for the set : 1. space used by the data structures maintained by the source, directory, and user; 2. time spent by the directory to perform an update initiated by the source; 3. size of the update authentication information sent by the source in an update (source-to-directory); 4. time spent by the directory to answer a query and return the answer authentication information as a proof of the answer; 5. size of the answer authentication information sent by the directory together with the answer (directory-touser); 6. time spent by the user to verify the answer to a query. Authenticated dictionaries have a number of applications, including scientic data mining (e.g., genomic querying [20] and astrophysical querying [24, 10, 25]), geographic data servers (e.g., GIS querying), third-party publication on the Internet [12], and certicate revocation in public key infrastructure [21, 28, 29, 1, 11, 19, 15]. In the third-party publication application [12], the source is a trusted organization (e.g., a stock exchange) that produces and maintains integrity-critical content (e.g., stock prices) and allows third party publishers (e.g., Web portals), to publish this content on the Internet so that it is widely disseminated. The publishers store copies of the content produced by the source. They perform content updates originating from the source and process queries on such content made by the users. However, the publishers are not assumed to be trustworthy, for a given publisher may be processing updates from the source incorrectly or it may be the victim of a system break-in. Thus, in addition to returning the result of a query, a publisher should also return a proof of authenticity of the result. In the certicate revocation application [21, 28, 29, 1, 11, 19, 15], the source is a certication authority (CA) that digitally signs certicates binding entities (e.g., identities or attributes) to their public keys, thus guaranteeing this binding. Nevertheless, certicates are sometimes revoked (e.g., if a private key is lost or compromised, or if someone loses their authority to use a particular private key). Thus, the user of a certicate must be able to verify that a given certicate has not been revoked. To facilitate such queries, the set of revoked certicates is distributed to certicate revocation directories, which process revocation status queries on behalf

of users. The results of such queries need to be trustworthy, for they often form the basis for electronic commerce transactions.

1.3 Organization of the Paper

The rest of this paper is organized as follows: Section 2 overviews previous work on authenticated dictionaries, especially in the context of certicate revocation. Our software architecture for authenticated dictionaries is described in Section 3. Our prototype implementation of an authenticated dictionaries based on skip lists and commutative hashing is outlined in Section 4. In Section 5, we report the results of a preliminary experiment on the performance of our data structure, and we conclude in Section 6.

2.1. Certicate Revocation

Previous work on authenticated dictionaries has been conducted primarily in the context of certicate revocation in public-key infrastructure (PKI). The traditional method for certicate revocation (e.g., see [21]) is for the CA (source) to sign a statement consisting of a timestamp plus a hash of the set of all revoked certicates, called certicate revocation list (CRL), and periodically send the signed CRL to the directories. A directory then just forwards that entire signed CRL to any user who requests the revocation status of a certicate. This approach is secure, but it is inefcient, for it requires the transmission of the entire set of revoked certicates for both source-to-directory and directory-to-user communication. This scheme corresponds to an authenticated dictionary where both the update authentication information and the answer authentication in. Because of the inefciency of the formation has size underlying dictionary, CRLs are not a scalable solution for certicate revocation. Micali [28] proposes an alternate approach, where the source periodically sends to each directory the list of all issued certicates, each tagged with the signed time-stamped value of a one-way hash function (e.g., see [31]) that indicates if this certicate has been revoked or not. This approach allows the system to reduce the size of the answer

 

2. Previous and Related Work

In this section, and throughout the rest of this paper, we denote with the current number of elements of the set stored in the authenticated dictionary. Authenticated dictionaries are related to research in distributed computing (e.g., data replication in a network [5, 23]), data structure design (e.g., program checking [6, 8, 9, 32] and memory checking [7, 13]), and cryptography (e.g., incremental cryptography [2, 3, 13, 14]).

2.2. Hash Trees

The hash tree scheme introduced by Merkle [26, 27] can be used to implement a static authenticated dictionary, which supports the initial construction of the data structure followed by query operations, but not update operations (without complete rebuilding). A hash tree for a set stores the elements of at the leaves of and a label at each node , dened as follows:

2.3. Dynamic Hash Trees

Using techniques from incremental cryptography, Naor and Nissim [29] dynamize hash trees to support the insertion and deletion of elements. In their scheme, the source and the directory maintain identically-implemented 2-3 trees. Each leaf of such a 2-3 tree stores an element of set , and each internal node stores a one-way hash of its childrens values. Hence, the source-to-directory communication is reduced to items, since the source sends insert and remove instructions to the directory, together with a signed statement consisting of a timestamp and the hash value of the root of . A directory responds to a membership query for an element as follows: if is in , then the directory supplies the path of from the leaf storing to the root, together with all siblings of nodes on this path; else ( is not in ), the directory supplies the leaf-to-root paths from two consecutive leaves storing and such that , together with all siblings of the nodes on these paths. By tracing these paths, the user can recompute the hash values of their nodes, ultimately recomputing the hash value for the root, which is then compared against the signed hash value of the root for authentication. One can apply Kochers interval idea to this scheme as an alternative way of validating items that are not in the dictionary . There are nevertheless some drawbacks of this approach. Dynamic 2-3 trees are not trivial to program correctly. In addition, since nodes in a 2-3 tree can have two or three children, one must take special care in the structuring of the answer authentication information sent by the directory to the user. Namely, all sibling nodes returned must be classied as being left children, middle children (if they exist), or right children. Recomputing the hash value at the root requires that a user be able to match the computation done at the source as regards a particular leaf-to-root path. Other certicate revocation schemes based on variations of hash trees have been recently proposed in [11, 15], as well, but do not deviate signicantly from the above approaches.

DfEe&dEcC &

&

&

&

The authenticated dictionary for consists of the hash tree plus the signature of a statement consisting of a timestamp and the label stored at the root of . An element is proven to belong to by reporting the labels of the nodes on the path in from the leaf storing to the root, together with the values of all nodes that have siblings on this path. Each node in this path must be identied as a left or right child, and the path must be given in order, so that the user can recompute the roots hash value and compare it to the current signed value. It is important that all this order and connectivity information be presented to the user, for without it the user would have great difculty recomputing the hash value for the root. This hash tree scheme can be extended to validate that an item is not in by keeping the leaves of sorted and then returning the leaf-to-root paths, and associated hash values, for two elements and such that and are stored at consecutive leaves of and , or (in the boundary cases) is undened and is the left-most leaf or is undened and is the right-most leaf. Again, the user is required to know enough about binary trees to be able to verify from the topology of the two paths that and are stored at consecutive leaves. Kocher [22] also advocates a static hash tree approach for realizing an authenticated dictionary, but simplies somewhat the processing done by the user to validate that an item is not in the set . In his solution, the leaves of the hash tree store the intervals dened by the consecutive elements in the sorted sequence of the elements of . A membership query for an item always returns a leaf and

  ba

else ( is an internal node), , where and are the left and right child of , respectively, and is a collision-resistant cryptographic hash function, such as MD5 or SHA1.

#  @9"!865"4320)(#"! 7 ! 1 $  # &

&

&

&

& $  '%"#"!

 BA"!

D E & E H'GFC C

if

is a leaf,

, where

is stored at ;

W XV

D E & S UTGC

QD7 RP) IC

authentication information to words: namely just a certicate identier and a hash value indicating its status. Unfortunately, this scheme requires the size of the update authentication information to increase to , where is the number of all non-expired certicates issued by the certifying authority, which is typically much larger than the number, , of revoked certicates.

the interval stored at such that , together with the path from to the root and all sibling hash values for nodes along this path. The user validates this path by recomputing the hash values of the nodes in this path, keeping track of whether nodes are left children or right children of their respective parents. Although there is a minor extra overhead of now having to have a way of representing and , this method simplies the verication for the case when an item is not in (which will usually be the case in certicate revocation applications). It does not support updates of the set , however.

W `Y

 "#"!

  

 

&

Table 1. Comparison of data structures for authenticated dictionaries. We use to denote the size of the dictionary, to denote the number of updates since a queried element has been created, and to denote the size of the universe the elements of the dictionary come from. We denote with an integer such that . The time and information size bounds of the Goodrich-Tamassia scheme are expected with high probability, while they are worst-case for the other schemes.

2.4. Skip Lists

Goodrich and Tamassia [18] have devised a data structure for an authenticated dictionary based on skip lists [30]. They introduce the notion of commutative hashing and show how to embed in the nodes of a skip list a computational DAG (directed acyclic graph) of cryptographic computations based on commutative hashing. This data structure matches the asymptotic performance of the NaorNissim approach [29], while simplifying the details of an actual implementation of a dynamic authenticated dictionary. In particular, the choice of a skip list and commutative hashing to implement an authenticated dictionary has the following benets over approaches based on hash trees:

We compare the asymptotic performance of data structures for authenticated dictionaries in Table 1.

3. Software Architecture
We have designed a general object-oriented software architecture for authenticated dictionaries and we have implemented it in Java. A high-level view of the software architecture is shown in Figure 2. In our architecture, an entity, called certication authority, or CA, has been added to the participants of the authenticated dictionary protocol. The CA is the only trusted entity in the system. It initiates updates and provides a signed statement to authenticate each update. This statement is modeled by an object called the Basis. In our formalization, the source acts as the intermediary between the CA and the directory. It forwards to the directory each update and its associated basis. The directory replies to queries made by the user by returning an object called AuthenticResponse, whose data elds provide the answer authentication information. We use six interfaces (APIs) to describe our authenticated dictionary system: AuthenticatedDictionary, with its subinterfaces MirrorAuthenticatedDictionary and SourceAuthenticatedDictionary, AuthenticResponse, Update, and Basis.

It replaces the complex details of 2-3 trees with the easy-to-implement details of skip lists.

It avoids the complication of storing intervals at leaf nodes [22], and instead returns to the intuitive concept of storing actual items at the leaf nodes.

It greatly simplies the verication process for a user, while retaining the basic security properties of signing a collection of values via cryptographic hashing.

2.5. One-Way Accumulators

The authors [16] have recently developed a data structure for authenticated dictionaries based on one-way accumulators [4, 31]. An advantage of this approach is that the validation of a query result performed by the user takes constant time and requires computations simple enough to be performed in devices with very limited computing power, such as a smart card or a wireless phone. This approach achieves a tradeoff between the cost of updates at the source and queries at the directories, with updates taking time and queries taking time, for any xed integer parameter . For example, one can achieve time for both updates and queries.

3.1. Queries
Interfaces AuthenticatedDictionary, AuthenticResponse, and Basis relate to querying. At the heart of the query system is the AuthenticatedDictionary. Its principal methods are

AuthenticResponse contains(Object o): queries the membership of an element and retrieves the answer as an AuthenticResponse object;

Basis getBasis(): requests the Basis object providing the answer authentication information.

quh Rig qrRyxig p h qrpRyxig h q h w(vig q h "(pig

quh Rig q"%Ryxig p h q"p%Ryxig h quh Rig q h r(pig

q h ar(pig q"Ryxig p h q"Ryxig p h q h F(sig q h "(pig

q h (ig quh Rig quh Rig q h t(sig q h "(pig

qar(ig "(pig p h q h qrRyxig "(pig p h q h qrRyxig "(pig p h q h q h t(sig q h t(sig q h "(pig q h "(pig  d6

method CRLs Micali [28] Naor-Nissim [29] Goodrich-Tamassia [18] Goodrich-Schwerin-Tamassia [16]

space

update time

update info

query time

answer info

validation time

S S HfeF

TS'S`

 4 g  Y a)63F

Basis (signed)

CA

PQ765F3 Update

Source

Figure 2. High-level view of our object-oriented software architecture for authenticated dictionaries.

An instance of AuthenticResponse has a method, subject, to identify the element of the query for which the response is issued, and a method, subjectContained, to determine whether or not the element is contained by the dictionary. There is also a method for determining whether or not the response is valid, called validatesAgainst, which takes an instance of Basis as its parameter. The user should trust that the answer about the membership of the object returned by subject in the dictionary provided that subjectContained is correct and the following are veried: 1. the user trusts that the data stored in the instance of Basis has not been tampered with, e.g., because it has been signed by the CA.; 2. the user trusts that the code executed by the methods of the AuthenticResponse has not been tampered with, e.g., because it has been signed by the CA; 3. method validatesAgainst returns true. A schematic interaction diagram for a query is shown in Figure 3. Note that method verifyBasis() is not part of the interfaces discussed above. The data represented by the Basis and AuthenticResponse objects are implementation-dependent. For example, in the hash tree data structure, the basis is the label of the root of the tree, and the AuthenticResponse object for an element in the set contains the sequence of labels (and associated left-child/right-child) indicators, for the siblings of the nodes in the path from the leaf containing the element

AuthenticResponse
YES Proof:

Directory PQ765F3 User AX234H3 Query

to the root. Method validatesAgainst recomputes the label of the root by hashing the labels in the sequence in the appropriate order and compares the value so obtained with the one provided by the basis.

3.2. Updates
Interfaces Update, MirrorAuthenticatedDictionary and SourceAuthenticatedDictionary, relate to updating an authenticated dictionary. The SourceAuthenticatedDictionary interface describes the updates to the authenticated dictionary maintained at the source. It allows the CA to add or remove items from the dictionary. It has two methods: insert and remove. Both methods have a single parameter, the element, and return an Update object. The Update object is used to transmit changes in the dictionary to the directory. The Update interface contains an execute method that carries out the action of the update on a directory, which could be a single insert/remove operation or a sequence of them. The MirrorAuthenticatedDictionary is the view given to an object of type Update of the authenticated dictionary maintained at the directory. Its only method is used to initialize the directory. It is assumed that a transport mechanism exists form distributing Update objects and their associated Basis objects to the directory. A schematic interaction diagram for updates is shown in Figure 4. Note that methods signBasis() and distribute() are not part of the interfaces discussed above. Because specic implementations of authenticated dic-

User getBasis()

Directory

<<create>> Basis

Basis Basis

contains(Object) AuthenticResponse

validatesAgainst(Basis) Boolean

tionary systems may restrict the types of data that may be stored in the dictionaries, the contains method of AuthenticatedDictionary, as well as the insert and remove methods of SourceAuthenticatedDictionary and the initialize method of MirrorAuthenticatedDictionary may throw exceptions if the user attempts to insert incompatible data. Also, if a directory is not fed instances of Update in the order in which they were generated at the source, exceptions may arise, depending upon specic implementations. We show the source code for the above interfaces at the end of this paper, in Figures 10 through 15.

i i

verifyBasis() <<create>>
YES Proof:

AuthenticResponse AuthenticResponse

Figure 3. Query interaction diagram.

CA

Source

Directory

insert(Object) remove(Object)

signBasis() Basis

distribute(Update)

distribute(Basis)

Figure 4. Update interaction diagram.

4. Implementation
To validate our software architecture for authenticated dictionaries, we have done a prototype implementation of an authenticated dictionary based on skip lists.

4.1. Skip Lists

In this section, we review the skip list data structure [30], which is an efcient means for storing a set of elements from an ordered universe. It supports the following opera-

S5 S4 S3 S2 S1 S0

+ 17 17 17 12 12 17 17 20 22 25 25 25 25 31 31 31 38 38 39 44 44 50 55 55 55 55 + + + + +

Figure 5. Example of a skip list.

The outer loop of the search process continues while down null, performing inside the loop one hop forward followed by one drop down. After completing such a sequence of hops forward and drops down, we ultimately null. If, at this point, reach a node with down elem , then we have found element . Otherwise, is the node of the base list with the largest element less than ; likewise, in this case, right is the a node of the base list with the smallest element greater than , that is, elem elem right . Figures 6 shows an example of a search in the skip list of Figure 5. The above searching process runs in expected time, for, with high probability, the height of the randomized skip list is and the expected number of nodes visited on any level is three (e.g., see [17]). Moreover, experimental studies (e.g., see [30]) have shown that skip lists often outperform 2-3 trees, red-black trees, and other deterministic search tree structures. To insert a new element , we determine which lists should contain the new element by a sequence of simulated random coin ips. Starting with , while the coin comes up heads, we use the stack to trace our way back to the position of list where element should go, add a new node storing to this list, and set . We continue this insertion process until the coin comes up tails. If we reach the top level with this insertion process, we add a new top level on top of the current one. The time taken by the above insertion method is with high probability. To delete an existing element , we remove all the nodes that contain the element . This takes time is with high probability.

 {z

&

Hop forward: We move right along the current list until we nd the node of the current list with largest

 %b

eY r $

&

&

&r ~f$ r &

&  %b

 )(#

$  T)(#

 a"#

&

l q

 %z

&

 )(#

E & E  "#

& $  e@"#

$  td(

$ F#

&

A skip list stores a set of elements in a series of linked lists , , , , . The base list, , stores all the elements of in order, as well as sentinels associated with the special elements and . Each successive list , for , stores a sample of the elements from . To dene the sample from one level to the next, we choose each element of at random with probability to be in the list . The sentinel elements and are always included in the next level up, and the top level, , is maintained to be . The top level is guaranteed to contain only the sentinels. We therefore distinguish the node of the as the start node . top list storing An element that exists in but not in is said to be a plateau element of . An element that is in both and is said to be a tower element in . Thus, between any two tower elements, there are some plateau elements. In deterministic skip lists, the number of plateau elements between two towers is at least one and at most three. The expected number of plateau elements between two tower elements is one. (See Figure 5.) For each node of list , we denote with elem the element stored at . Also, we denote with down the node below , which stores the same element as , unless in , in which case down null. Similarly, we denote with right the node in immediately to the right of , unless is the sentinel storing , in which case right null. To perform a search for element in a skip list, we begin at the start node . Let denote the current node in our search (initially, ). The search proceeds using two actions, forward hop and drop down, which are repeated one after the other until we terminate the search.

&

l"v}B q q u lrwq v lrvwq q lv "}q | W XV o  {z W `Y W XV q y 8x lv rwq lv rwqu  tr s qB W `Y W XV o nn m l j B P8n k k

 )(#

 )(#

W `Y

j p

&

q $  @)(#

&

delete( ): remove element

from .

# $  {)(#

&

insert( ): insert element

into .

&

nd( ): determine whether elements

is in .

Drop down: If down null, then we are done with our search: the node stores the largest element in the skip list less than or equal to . Otherwise, we update down .

 )(#

$ F# &

tions:

element less than or equal to elem right , we update

That is, while right

& E  {a"#

| $ # |

 "#

&

&

&

${"# # ~ $ lv "}q r

S5 S4 S3 S2 S1 S0

v11
+ 8

v10
17 8 17 17 12 12 17 17 8

v9
+

v8
25 25 25 20 22 25 8

v7
55 + + + +

v6
31 31 31 8

v5
55

v4
38 38 8

v3
44 55 50 55

v2
39

v1
44 8

Figure 6. Search for element in the skip list of Figure 5. The nodes visited and the links traversed are drawn with thick lines. This successful search visits the same nodes as the unsuccessful search for element .

It can be shown that tant [18].

is commutatively collision resis-

j p u&

 | "!

3fGu& & E & E

u&

The authenticated dictionary approach introduced in [18] consists of a skip list where each node stores a label computed accumulating the elements of the set with a commutatively cryptographic hash function . For completeness, let us review how hashing occurs. See [18] for details.

&

4.3. Authenticated Dictionary Based on a Skip List

We illustrate the ow of the computation of the hash values labeling the nodes of a skip list in Figure 7. Note that the computation ow denes a directed acyclic graph, not a tree. After performing the update in the skip list, the hash values must be updated to reect the change that has occurred. The additional computational expense needed to update all these values is expected with high probability to be . The verication of the answer to a query is simple, thanks to the use of a commutative hash function. Recall that the goal is to produce a verication that some element is or is not contained in the skip list. In the case when the answer is yes, we verify the presence of the element itself. Otherwise, we verify the presence of two elements and stored at consecutive nodes on the bottom level such that . In either case, the answer authentication information is a single sequence of values, together with the signed, timestamped, label of the start node .

 "#"!

 ! $  {(5"{"#"!

 a@(9"!P65"431 7 ! 9 9

 %z

$ 5

2.

null, i.e.,

is not on the base level: .

(a) If (b) If

is a tower node, then is a plateau node, then .

 "#"!

 a9

#  !7 @9"8"#

7 "#

elem

 "#"!

is a tower node, then elem . (b) If is a plateau node, then elem .

(a) If

31

31

$ 5

1.

null, i.e.,

is on the base level:

$  )(#

 )(#"!

For this paper, we view a cryptographic hash function as a function that takes two integer arguments, and , and maps them to an integer that is represented using a xed number of bits (typically fewer than the number of bits of and ). Intuitively, is a digest for the pair . We can also use the hash function to digest a triple, , as . Likewise, we can use to digest larger sequences. Namely, to digest a sequence we can compute . To simplify the verication process that a user has to do in an authenticated dictionary scheme, Goodrich and Tamassia introduce commutative cryptographic hash functions [18]. A hash function is commutative if , for all and . Such a function requires that we modify what we mean by a collision resistant hash funcwould normally be tion, for the condition considered as a collision. We therefore say that a hash function is commutatively collision resistant if, given , it is difcult to compute a pair such that while and . Given a cryptographic hash function that is collision resistant in the usual sense, we construct a candidate commutative cryptographic hash function, , as follows [18]:

 "#

$ T5

~{"#"! $   "#  "#"!

$ 9

4.2. Commutative Hashing

For each node we dene label in terms of the respective values at nodes right and down . If right null, then we dene . The denition in the general case depends on whether exists or of not for this node .

 7 1 $ 7 P43%88431 7 RP

$  C7 X"4(&31

  &7l v 17 m v 1nnn7 m 17l az8P)P"`d(&38`)&dPP8Pu(&38%(&31  &7nnn7 m &7l )P8P8u4{& 1  D7 17 aP)(C38&d1 P)&  D7 C7 1  C7 "4(&  C7 r(&31 C &

&

1 n C & 7 C7 & 1 $  C7 "7Bbt"w"@zd6"4(& 1 b1

{7)Cd1$6"47(&31 & C C

 7 $  7 8Pc8P4 7 8

 1

 C7 r(&31

 7 $  7 PP8P

y b

&

 &7 %4d(C31

S5 S4 S3 S2 S1 S0

+ 17 17 17 12 12 17 17 20 22 25 25 25 25 31 31 31 38 38 39 44 44 50 55 55 55 55 + + + + +

12

17

20

22

25

31

38

39

44

50

55

Figure 7. Flow of the computation of the hash values labeling the nodes of the skip list of Fig. 5. Nodes where hash functions are computed are drawn with thick lines. The arrows denote the ow of information, not links in the data structure.

, the label of the start node;

Two classes are used to implement the Update interface. One represents insertion updates and stores the height of the tower associated with the newly inserted element. The other represents deletion updates.

4.4. Implementation Details

The six interfaces described in Section 3 have been implemented as Java classes. Additional auxiliary classes have been used. Some implementation details are overviewed below.

(B~ n

The class implementing the Basis interface stores the label of the start node of the skip list and a reference to the CommutativeHash used by the data structure.

~ y

A class CommutativeHash serves as a wrapper that adds commutativity to a standard [Link].

y 

~ ~~7 ~ bk ~ ~~7 ~~ bk

~ ~ ~7 ~ ~ baB

The computation of the node sequence can be done by pushing onto a stack the nodes visited while searching for element . When the search ends, the stack contains the nodes of ordered from top to bottom. Using this stack, we easily construct the sequence of node labels. by simThe user veries the answer for element ply hashing the values of the returned sequence in the given order, and comparing the result with the signed value , where is the start node of the skip list. If the two values agree, then the user is assured of the validity of the answer at the time given by the timestamp.

The class implementing the AuthenticatedDictionary interface uses nite sentinel values. Also, it limits to a given value the height of any tower.

5. Performance
We have conducted a preliminary experiment on the performance of our data structure for authenticated dictionaries on randomly generated sets of -bit integers ranging in size from to . For each operation, the average was computed over trials. The experiment was conducted on a 440MHz Sun Ultra 10 with 256M of memory running Solaris. The Java Virtual Machine was launched with a 200M maximum heap size. Cryptographic hashing was performed using the standard Java implementation of the MD5 algorithm. The signing of the basis by the CA and the signature verication by the user were omitted from the experiment. The highest level of a tower was limited to . The results of the experiment are summarized in Figure 9. Note that validations, insertions and deletions take less than ms, while queries take less than ms. Thus, we feel the use of skip lists and commutative hashing is a scalable solution for the authenticated dictionary.

%(&

Let be the sequence of nodes that are visited when searching for element , in reverse order. In the example of Fig. 6, we have . Note that by the properties of a skip list, the size of sequence is with high probabila sequence ity. We construct from the node sequence of values such that:

The class implementing the AuthenticResponse interface stores the sequence of label values and an integer ag to distinguish among the various cases of validation of the answer.

$uybz$u &  %(& &

 %&  {& &  {&   C 1 aa(P8Pld78P4dP7bmv`(C318l"`(C3HC 7 v 1 $  | ! "$ C  CPPPR7 l (Cc%{& 7 $  {&  l 8PR7 l # l #7  {z  {& |  | "!

 8PR7 l (#e%(& #7 $ 

S5 S4 S3 S2 S1 S0

v11
+ 8

v10
17 8

v9
+

17 12 12 17 17

u6
25 20 22 25 31 31 8 8

v4
38

v3
38

w3
44 55 50 55 + + 39

u4

v2

v1

44

12

17

20

22

25

31

38

39

44

50

55

Figure 8. The answer authentication information for the presence of element (and for the absence of element ) consists of the signed time-stamped value of the source element and the sequence . The user recomputes by accumulating the elements of the sequence with the hash function , and veries that the computed value of is equal to the value signed by the source. As in Figure 7, the arrows denote the ow of information, not links in the data structure.

1.2

1 0.9

average time (ms)

0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1

100,000 200,000 300,000

Figure 9. Average time per operation (in milliseconds) of our Java implementation of an authenticated dictionary using a skip list.

6. Conclusion
We presented an object-oriented software design of an authenticated dictionary and a prototype implementation of an efcient and practical data structure for realizing an authenticated dictionary. Preliminary experiments show we are able to retain the basic security properties of previous schemes but make the dynamic maintenance of an accumulated dictionary more practical, particularly for contexts where user computations must be performed on simple de-

1.1

insertion deletion validation query

400,000 500,000 600,000 700,000

number of elements

vices, such as PDAs and smart cards. Acknowledgments We would like to thank Giuseppe Ateniese and Robert Cohen for helpful discussions on the topics of this paper, Benety Goh for assisting in the implementation of the data structure, and James Lentini for conducting runtime experiments. We also thank Jeremy Mullendore, Joel Sandin, and Michael Shin for additional software support.

u8

v6
25 31

v5
55 +

u10

v8
17 25

v7
55

w7
+

$ d&

 l #"! l 1  !7 7 !7 !7 !7 !7 !7 !7 7 7 $   jl 5"83a%5"P4d5"8(9"P4d5"P4d5"89"PBkkbz%& ll Pu#"! y b

 l (#"! l

References
[1] W. Aiello, S. Lodha, and R. Ostrovsky. Fast digital identity revocation. In Advances in Cryptology CRYPTO 98, Lecture Notes in Computer Science. Springer-Verlag, 1998. [2] M. Bellare, O. Goldreich, and S. Goldwasser. Incremental cryptography: The case of hashing and signing. In Advances in CryptologyCRYPTO 94, volume 839 of Lecture Notes in Computer Science, pages 216233. SpringerVerlag, 1994. [3] M. Bellare, O. Goldreich, and S. Goldwasser. Incremental cryptography and application to virus protection. In Proceedings of the Twenty-Seventh Annual ACM Symposium on the Theory of Computing, pages 4556, 1995. [4] J. Benaloh and M. de Mare. One-way accumulators: A decentralized alternative to digital signatures. In Advances in CryptologyEUROCRYPT 93, volume 765 of Lecture Notes in Computer Science, pages 274285, 1993. [5] J. J. Bloch, D. S. Daniels, and A. Z. Spector. A weighted voting algorithm for replicated directories. Journal of the ACM, 34(4):859909, 1987. [6] M. Blum. Program result checking: A new approach to making programs more reliable. In S. C. Andrzej Lingas, Rolf G. Karlsson, editor, Automata, Languages and Programming, 20th International Colloquium, volume 700 of Lecture Notes in Computer Science, pages 114. Springer-Verlag, 1993. [7] M. Blum, W. Evans, P. Gemmell, S. Kannan, and M. Naor. Checking the correctness of memories. Algorithmica, 12(2/3):225244, 1994. [8] M. Blum and S. Kannan. Designing programs that check their work. J. ACM, 42(1):269291, Jan. 1995. [9] M. Blum and H. Wasserman. Program result-checking: A theory of testing meets a test of theory. In Proceedings of the 35th Annual Symposium on Foundations of Computer Science, pages 382393, 1994. [10] R. J. Brunner, L. Csabai, A. S. Szalay, A. Connolly, G. P. Szokoly, and K. Ramaiyer. The science archive for the Sloan Digital Sky Survey. In Proceedings of Astronomical Data Analysis Software and Systems Conference V, 1996. [11] A. Buldas, P. Laud, and H. Lipmaa. Accountable certicate management with undeniable attestations. In ACM Conference on Computer and Communications Security. ACM Press, 2000. [12] P. Devanbu, M. Gertz, C. Martel, and S. Stubblebine. Authentic third-party data publication. In Fourteenth IFIP 11.3 Conference on Database Security, 2000. [13] Fischlin. Incremental cryptography and memory checkers. In EUROCRYPT: Advances in Cryptology: Proceedings of EUROCRYPT, LNCS 1233, pages 393408, 1997. [14] M. Fischlin. Lower bounds for the signature size of incremental schemes. In 38th Annual Symposium on Foundations of Computer Science, pages 438447, 1997. [15] I. Gassko, P. S. Gemmell, and P. MacKenzie. Efcient and fresh certication. In International Workshop on Practice and Theory in Public Key Cryptography 2000 (PKC 2000), Lecture Notes in Computer Science, pages 342353, Melbourne, Australia, 2000. Springer-Verlag, Berlin Germany. [16] M. T. Goodrich, A. Schwerin, and R. Tamassia. An efcient dynamic and distributed cryptographic accumulator. Technical Report, Johns Hopkins Information Security Institute, 2000.

[17] M. T. Goodrich and R. Tamassia. Data Structures and Algorithms in Java. John Wiley & Sons, New York, NY, 1998. [18] M. T. Goodrich and R. Tamassia. Efcient authenticated dictionaries with skip lists and commutative hashing. Technical Report, Johns Hopkins Information Security Institute, 2000. [19] C. Gunter and T. Jim. Generalized certicate revocation. In Proc. 27th ACM Symp. on Principles of Programming Languages, pages 316329, 2000. [20] R. M. Karp. Mapping the genome: Some combinatorial problems arising in molecular biology. In Proceedings of the Twenty-Fifth Annual ACM Symposium on the Theory of Computing, pages 278285, 1993. [21] C. Kaufman, R. Perlman, and M. Speciner. Network Security: Private Communication in a Public World. PrenticeHall, Englewood Cliffs, NJ, 1995. [22] P. C. Kocher. On certicate revocation and validation. In Proc. International Conference on Financial Cryptography, volume 1465 of Lecture Notes in Computer Science, 1998. [23] B. Kroll and P. Widmayer. Distributing a search tree among a growing number of processors. SIGMOD Record (ACM Special Interest Group on Management of Data), 23(2):265 276, 1994. [24] R. Lupton, F. M. Maley, and N. Young. Sloan digital sky survey. [Link] [25] R. Lupton, F. M. Maley, and N. Young. Data collection for the Sloan Digital Sky SurveyA network-ow heuristic. Journal of Algorithms, 27(2):339356, 1998. [26] R. C. Merkle. Protocols for public key cryptosystems. In Proc. Symp. on Security and Privacy. IEEE Computer Society Press, 1980. [27] R. C. Merkle. A certied digital signature. In G. Brassard, editor, Advances in CryptologyCRYPTO 89, volume 435 of Lecture Notes in Computer Science, pages 218238. Springer-Verlag, 1990. [28] S. Micali. Efcient certicate revocation. Technical Report TM-542b, MIT Laboratory for Computer Science, 1996. [29] M. Naor and K. Nissim. Certicate revocation and certicate update. In Proceedings of the 7th USENIX Security Symposium (SECURITY-98), pages 217228, Berkeley, 1998. [30] W. Pugh. Skip lists: a probabilistic alternative to balanced trees. Commun. ACM, 33(6):668676, 1990. [31] B. Schneier. Applied cryptography: protocols, algorithms, and sourcecode in C. John Wiley and Sons, Inc., New York, 1994. [32] G. F. Sullivan, D. S. Wilson, and G. M. Masson. Certication of computational results. IEEE Trans. Comput., 44(7):833 847, 1995.

/** * Interface implemented by objects that represent the bases of the validatable * responses returned by AuthenticatedDictionar y objects. Implementations of * this class should have a public constructor that takes no parameters, and * a means to distinguish between initialized and uninitialized instances. * **/ public interface Basis /** * Get the encoded form of this basis. **/ public byte[ ] getEncoded() throws NotYetInitializedException; /** * Read the basis from an array of bytes, initializing this instance of * the basis. This should at least be able to read the encodings produced * by the getEncoded() method. **/ public void readEncoded(byte[] encoding) throws AlreadyInitializedException, IncompatibleDataException;

/** * Interface implemented by all objects representing updates to * instances of MirrorAuthenticatedDictionary . **/ public interface Update extends [Link] /** * An udpate that doesnt do anything at all. Never throws an exception, * and may be executed upon any MirrorAuthenticatedDictionary. **/ public static nal Update NOOP = new NoUpdate(); static class NoUpdate implements Update public void execute(MirrorAuthenticatedDictionary dict) throws IncompatibleDataException, InconsistentUpdateException, NotYetInitializedException /* do nothing */ public String toString() return "NOOP"; ; /** * Update the given MirrorAuthenticatedDictionary dict * Throws IncompatibleDataException if this update object cannot update * the given data structure because of an incompatible implementation. * Throws InconsistentUpdateException if this update object cannot update * the given data structure because the data structure does not have the * appropriate initial state, or if the data structure has not yet been initialized. * Throws NotYetInitializedException if the mirror is uninitialized. **/ public void execute(MirrorAuthenticatedDictionary dict) throws IncompatibleDataException, InconsistentUpdateException, NotYetInitializedException;

Figure 11. Update interface.

Figure 10. Basis interface.

public interface AuthenticatedDictionary /* Include the basic dictionary methods size() and isEmpty() */ public int size() throws NotYetInitializedException; public boolean isEmpty() throws NotYetInitializedException; /** * Responds as to whether or not the given object o is contained in the * dictionary. The response takes the form of an instance of the * AuthenticResponse class which, whenever possible, answers the question * of containment in the dictionary in a veriable manner. * Returns A response as to whether or not code o /code * is in the dictionary. * Throws IncompatibleDataException If o is not a valid * object to store in this instance of the AuthenticatedDictionary * Throws NotYetInitializedException if this instance is a mirror, * and has yet to be initialized **/ public AuthenticResponse contains(Object o) throws IncompatibleDataException, NotYetInitializedException; /** * Gets the basis of the veriable responses returned by this data * structure. If the user trusts the basis, then the user may trust all * validatable responses concluded * from that basis. The user might come to trust a particular basis by * receiving it from a trusted source over secure channels, or by receiving * a copy of it that has been signed by a trusted source. * Throws NotYetInitializedException if this instance is a mirror, * and has yet to be initialized. **/ public Basis getBasis() throws NotYetInitializedException; /** * Determines whether or not the basis b of the validatable responses created * by this AuthenticatedDictionary is the same as the parameter to the method. * To be the same, the two bases need to be able to validate exactly the * same set of responses. If the basis of the data structure validates * responses that b does not, or b validates responses that the data * structures basis does not, then the two bases are not the same; * otherwise, they are. * Throws NotYetInitializedException if this instance is a mirror, * and has yet to be initialized. **/ public boolean validatesAgainst(Basis b) throws NotYetInitializedException; /** * Gets data that may be used to initialize a compatible mirror * authenticated dictionary via its * initialize(AuthenticatedDictionaryInitialization) method. * Throws NotYetInitializedException if this instance is a mirror, * and has yet to be initialized. **/ public AuthenticatedDictionar yInitialization getInitializationData() throws NotYetInitializedException;

Figure 12. AuthenticatedDictionary interface.

/** * Returns the object whose membership in a particular * AuthenticatedDictionar y this response authentically conrms or denies. * Returns The subject of the response. **/ public Object subject(); /** * Return code true /code iff the subject of this response is contained * within the authenticated dictionary that issued this response. **/ public boolean subjectContained(); /** * Checks to see if the response is actually validatable. It is possible * that a given instance of AuthenticatedDictionar y might only be able to * provide validatable responses when the result of a query is postive. * Such instances must still be able to supply a response when the result * is negative, even if that response isnt validatable. * * Returns true iff this response is validatable **/ public boolean isValidatable(); /** * Checks to see of the response is a valid conclusion from the given basis. * If the response is a valid conclusion from the given basis, and if the * user trusts the basis, then the user may also trust the validity of the * response. * * @param b The basis against which to check this response. * @return true iff the response is a valid conclusion from the given basis. * Must return false if code isValidatable() /code returns false. **/ public boolean validatesAgainst(Basis b);

Figure 13. AuthenticResponse interface.

public interface AuthenticResponse

public interface SourceAuthenticatedDictionary extends AuthenticatedDictionar y

/** * Initialize the otherwise uninitialized data structure according to the * given initialization data, which was presumably issued by the * getInitializationData() method of a compatible * implementation of SourceAuthenticatedDictionary. * @param initData The initialization data * @exception AlreadyInitializedException If the data structure has already * been initialized * @exception IncompatibleDataException if the initialization data object is * not compatible with this implementation of * MirrorAuthenticatedDictionary. * @see SourceAuthenticatedDictionary#getInitializationData() **/ public void initialize(AuthenticatedDictionaryInitialization initData) throws AlreadyInitializedException, IncompatibleDataException;

Figure 15. MirrorAuthenticatedDictionary interface.

/** * Add o to the AuthenticatedDictionar y; * returns an update object describing how mirror copies of this data * structure should modify themselves in order to be consistent with * this insertion * @param o The object to insert * @throws IncompatibleDataException if o is not an object * that may be stored in this AuthenticatedDictionary **/ public Update insert(Object o) throws IncompatibleDataException; /** * Remove o from the AuthenticatedDictionary, * returns an update object describing how mirror copies of this data * structure should modify themselves in order to be consistent with * this removal * @param o The object to remove * @throws IncompatibleDataException if o is not an object * that may be stored in this AuthenticatedDictionary **/ public Update remove(Object o) throws IncompatibleDataException;

Figure 14. SourceAuthenticatedDictionary interface.

public interface MirrorAuthenticatedDictionary extends AuthenticatedDictionar y