arX

iv:c

s/03

0201

0v1

[cs

.CR

] 7

Feb

200

3

Authenticated Append-only Skip Lists

Petros Maniatis Mary Baker

Computer Science Department, Stanford University

Stanford, CA 94305, USA

{maniatis,mgbaker}@cs.stanford.eduhttp://identiscape.stanford.edu/

Abstract

In this work we describe, design and analyze the se-curity of a tamper-evident, append-only data struc-ture for maintaining secure data sequences in aloosely coupled distributed system where individ-ual system components may be mutually distrust-ful. The resulting data structure, called an Authen-ticated Append-Only Skip List (AASL), allows itsmaintainers to produce one-way digests of the entiredata sequence, which they can publish to others asa commitment on the contents and order of the se-quence. The maintainer can produce efficiently suc-cinct proofs that authenticate a particular datumin a particular position of the data sequence againsta published digest. AASLs are secure against tam-pering even by malicious data structure maintain-ers. First, we show that a maintainer cannot “in-vent” and authenticate data elements for the AASLafter he has committed to the structure. Second,he cannot equivocate by being able to prove con-flicting facts about a particular position of the datasequence. This is the case even when the data se-quence grows with time and its maintainer publishessuccessive commitments at times of his own choos-ing.

AASLs can be invaluable in reasoning about the

integrity of system logs maintained by untrusted

components of a loosely-coupled distributed sys-

tem.

1 Introduction

Dependable systems rely heavily on logs ofdata, system events, transactions, and securitydecisions. Inspecting such logs while the sys-tem is running (on-line) or after an exceptionalevent has caused the system to cease opera-

tions (off-line) can help maintain accountabil-ity through audit trails, repair failures throughundo/redo logs, and improve performance viaprofiling.

In distributed systems, especially those in-tended for loosely-coupled communities of in-dependent components (generally called peer-to-peer systems), it is frequently infeasible tomaintain a central system log; in fact, oftenthere is no central authority that can be trustedby all participating components to maintain alog faithfully. Instead, each component storesits own log of events observed locally, or of in-teractions with other components. The log forthe entire system does not exist physically; itis made up of log fragments scattered arounddifferent system components.

These distributed log fragments must be pe-rused for answers when a failure occurs or acomponent is reported as misbehaving. For ex-ample, consider a distributed file system, wherecomponent A requests that component B storedatum d and B accepts. Later A attempts toretrieve datum d from B and B denies havingthis datum. A can convincingly accuse B ofmisbehavior only if it can show that, at first,B agreed to hold d and, later, B denied havingdone so.

In such a setting, logs can be a very sensi-tive and vulnerable system resource. A com-ponent, along with the entity that operates it,cannot trust another component to retain theorder of its locally logged events or to refrainfrom changing events after it has logged them.This prevents A, in the example above, from us-ing B’s log to justify its accusation. Similarly,

2

an arbiter must be skeptical of an accusationmade by A that relies on the integrity of A’slog.

The problem has been addressed in the lit-erature via the use of collision-resistant hashfunctions to link the contents of earlier log en-tries to later ones [4, 5, 8, 9]. The collision-resistance property of the hash functions usedmakes it very difficult to “rewrite history” in asensitive log, without causing dramatic changesin the entire log. However, with very few ex-ceptions (notably, work by Buldas et al. [2]),no attention has been paid to the scalabilityof such hash-based techniques when logs growvery long and interesting sensitive log entriesmay have been created years—and billions oflog entries—ago.

In this paper, we analyze the security of theAuthenticated Append-only Skip List (AASL).The AASL is a novel data structure that is de-signed for the efficient maintenance of and ac-cess to very large, tamper-evident sequences ofdata. AASLs provide a mechanism for detect-ing structural corruption, such as modification,removal or reordering of data, whenever thosedata are accessed. We have used AASLs inTimeweave [5], a mechanism that allows com-ponents of a distributed system to maintain alocal trustworthy view of a global system log.

A distributed system component that main-tains an AASL can compute succinct one-waydigests of the entire structure; these digestscan serve as a commitment on the data struc-ture contents and order, and can be conveyedto other system components as such. A re-mote component wishing to establish whethera particular datum appears in such a data se-quence (membership) can request a proof fromthe maintainer of the AASL. This proof can beverified against the digest to which the main-tainer has committed.

AASLs are guaranteed to prevent maintain-ers from proving conflicting facts about a datasequence, even at different points in the evolu-tion of the sequence over time. In this paper, wedescribe the construction of AASLs and provethe security guarantees they offer.

2 Background

In this section, we describe related work thatprotects sensitive logs from tampering, and re-lated work on securing the contents of skip lists.

The integrity of public logs or commit-ment sequences has traditionally been pro-tected through the use of one-way hash func-tions. Spreitzer et al. [9] describe how to pro-tect the modification order of a weakly consis-tent, replicated data system, by placing succes-sive write and read operations in a hash chain;this is a linked list, where every element is an-notated with a label computed by hashing to-gether the value of the element and the label ofthe preceding element. Schneier and Kelsey [8]propose a historic integrity scheme for logs ofuntrusted or vulnerable machines. Their workprotects access-controlled log entries againsttampering or unauthorized retroactive disclo-sure through hash chaining. In secure digitaltime stamping [4], a digital notary places docu-ments in a hash chain, so as to be able to derivetemporal precedences between document com-mitments.

Unfortunately, reasoning about simple hashchains can be very expensive when they growlong. To check that a particular element occu-pies the beginning of the chain, all the hashesbetween that element and the end of the chainmust be performed. Buldas et al. [2] improvegreatly on this linear cost; they describe opti-mally efficient hash graphs that permit the ex-traction of such temporal precedences with op-timal proof sizes, on the order of the logarithmof the size of the graph.

Goodrich et al. [3] retrofit skip lists fortamper-evidence. In that work, the authorspropose an authenticated skip list that relieson commutative hashing. Anagnostopoulos etal. [1] extend this construct to deal with per-sistent data collections, where older versions ofthe skip list are available, and they are each, bythemselves, an authenticated skip list. How-ever, these structures are not designed to beappend-only. As a result, they are not well-suited for tamper-evident logs: a maliciousmaintainer can remove and then reinsert ele-

3

ments from the “middle” of the structure acrossversion changes. A verifier must check vigi-lantly that a log entry that interests him re-mains consistently in every new version of thestructure produced by the maintainer, whichcan be very expensive when versions are pro-duced frequently.

We have used the structure described in thispaper in previous work [5] to preserve the his-toric integrity of a loosely coupled distributedsystem. Here we focus on a detailed designand analysis of the security guarantees that thestructure offers.

3 Design

An Authenticated Append-only Skip List(AASL) is a data structure conceptually basedon skip lists [7]. Skip lists are sorted linkedlists with extra links, designed to allow fastlookup of the stored data elements by taking“shortcuts.” The basic idea is to enhance linkedlists, which connect each element in the data se-quence to its successor, by also linking some ele-ments to successors further down the sequence.Roughly half of the elements have links to theirtwo-hop successor, roughly a quarter of the el-ements have links to their four-hop successor,and so on. As a result, during traversal fromelement a to element b, the traversal path fol-lows repeatedly the longest available link fromthe current element that does not overshoot thedestination b, and thereby reaches b in fewersteps than would be possible by just travers-ing every intervening element between a and b.Skip list traversals achieve logarithmic traver-sal path lengths in the number of data elementsin the structure, as opposed to the linear pathsoffered by regular linked lists.

3.1 AASL construction

AASLs take advantage of the shortcut idea, de-scribed above, albeit in a deterministic fash-ion as opposed to the randomized nature of theoriginal skip lists. AASLs of n elements consistof log2 n coexisting linked lists, each designatedby a different level number. The linked list at

0 1 2 5 8 9 10

0 0 0 0 0 0 0 0 0 0 0

1 1 1 1 11

2 2

2

3

34

1d

2d

3d

4d

5d

6d

7d

8d

9d

10d

3 4 6 7

Figure 1: An example of a deterministic skiplist, containing 10 data elements. Boxes denoteelement positions (indices), and circles denotethe actual element data. We represent the skiplist as an overlapping set of linked lists, eachat a different level. Pointers are marked withthe level of the linked list to which they belong.The thick gray line outlines a traversal of theskip list, from the 3rd to the 7th element.

level 0 is a regular linked list connecting all el-ements in the data sequence. The linked list atlevel 1 is a linked list that only contains everyother element from the original data sequence.The linked list at level l contains every 2l-th el-ement of the original data sequence. Element ibelongs to the l-level linked list if and only if iis divisible by 2l. Figure 1 illustrates this basicstructure.

AASL elements, in addition to their datumand their index number, carry an authenticator.The authenticator T i for the i-th element is avalue derived via a few applications of a one-way hash function h, such as SHA-1 [6], to thedatum di of the i-th element and the authen-ticators of the immediate predecessors of thatelement on each of the linked lists in which itappears.

More specifically, an authenticator is com-puted in two steps (see Figure 2). First, thepartial authenticators for an element are com-puted, one for each list in which that elementparticipates. A partial authenticator is a valuecomputed by hashing together the current in-dex number, the current datum, the current listlevel, and the authenticator of the preceding el-ement on that list. The partial authenticator

4

datumpartial

authenticatorauthenticator

10d

0

10L

1

10L

10T

110

010

0

9L

9d

9T

09

8T

Figure 2: An illustration of the construction ofthe skip list authenticators for elements 9 and10. The construction of the 8-th authenticatoris not shown.

Lli for the element in position i on the list at

level l is computed by

Lli = h(i‖l‖di‖T

i−2l) (1)

where ‖ denotes bit-string concatenation. Sec-ond, the partial authenticators are combined,again using the hash function, to produce theelement authenticator. The authenticator T i ofthe i-th element is computed by

T i = h(L0i ‖L

1i ‖ . . . ‖L

fii ) (2)

where fi is the highest level of linked list inwhich the i-th element appears. fi is definedby the relation

fi = {n : i = 2nr ∧ gcd(2, r) = 1} (3)

A very useful property of skip lists is thatthey can be traversed from a source element ito a destination element n (i ≥ n) in a num-ber of steps that is logarithmic in the elementsof the structure. At every step, a linked listat the highest level is picked, among those inwhich the current element participates, so asto travel the farthest distance towards the des-tination, without overtaking it. Algorithm 1specifies how a single hop is chosen for such atraversal. The thick gray line in Figure 1 illus-trates a traversal of the structure.

3.2 AASL Membership Proofs

The primary use of AASLs is to support au-thenticated answers to membership questions,

Algorithm 1 SingleHopTraversalLevel(i, n) ⇒ l. Return the highest linked list level lthat must be followed in the AASL from element ito element n, where i ≥ n.

1: l← 02: while 2l divides i do3: if i+ 2l ≤ n then4: L← l {L-hop does not overtake n.}5: else6: Return L {Last safe hop level.}7: end if8: l← l + 19: end while

10: Return L {The highest level possible for i.}

such as “what is the 7-th element in theAASL?”, while maintaining the append-onlyproperty of the AASL. To accomplish this func-tionality, it is important, first, that the partyasking the question (the verifier) know in whichAASL she is asking that question; and, sec-ond, that once the verifier receives a response,she holds that response as unequivocal for theAASL in question.

An AASL is uniquely determined by a digest.This is the authenticator of the last appendedelement into the structure. The maintainer ofan AASL conveys this short value to potentialverifiers as commitment to the exact contentsof the AASL. A verifier who receives such a di-gest verifies all subsequent exchanges with themaintainer against this digest.

A response to a membership question on thecontents of an AASL consists of a membershipclaim and a membership proof. A membershipclaim has the form “Data element d occupiesthe i-th position of the AASL whose n-th au-thenticator is known to the verifier,” and isdenoted by 〈i, n, d〉. The corresponding mem-bership proof is denoted by Ei,n,d. This proofconvinces the verifier that, first, the maintainerhad decided what the i-th value d would be be-fore issuing the n-th authenticator; second, themaintainer cannot authenticate any other valued′ 6= d as the value of the i-th element of theAASL with the known n-th authenticator T .

The AASL maintainer constructs the mem-bership proof Ei,n,d by traversing the AASL

5

from the i-th to the n-th element, hop byhop, as described by SingleHopTraversal-

Level. For every encountered skip list ele-ment j, the maintainer constructs a proof com-ponent Cj that consists of the j-th data el-ement and the authenticators of its predeces-sors on all the linked lists in which it appears:Cj = 〈dj ; 〈T

j−2l : 0 ≤ l ≤ fj〉〉. The sequenceof all proof components makes up the member-ship proof Ei,n,d = 〈Cj : j ∈ Si,n〉, where Si,n

is the sequence of elements traversed from i ton. The appendix contains Algorithm 6, whichdescribes the construction process for a singleproof component, and Algorithm 7, which out-lines the overall proof construction process.

The verifier processes a membership proofagainst the AASL authenticator that it holdsto verify the validity of a membership claim.The verification process mimics the proof con-struction process. The verifier’s job, however,is to make sure that the purported proof iswell-formed and yields the known authentica-tor starting with the element datum and posi-tion in the maintainer’s membership claim. Theverification may succeed with a positive result,which means that the claim is true; it may suc-ceed with a negative result, which means thatthe claim is false, i.e., it cannot be true; and itmay fail, in which case nothing is known aboutthe claim, except that the supplied proof is in-appropriate for the given claim.

For every element j in the traversal from thei-th to the n-th element, the verifier checks thatthe corresponding component C in the proofis formed as component Cj should be formed;he then uses that component to compute whatthe j-th authenticator should be based on thatcomponent. Furthermore, since, during traver-sal, the authenticator of a traversed element isalways used in the computation of the authenti-cator of the next traversed element, the verifiermust check that the authenticators it computesin earlier steps of the verification process areconsistent with those used in later verificationsteps. Finally, the proof must be checked forapplicability, that is, it should match the claimit purportedly proves: if a membership proofclaims to prove the membership claim 〈i, n, d〉,

then the datum in the first proof componentshould be d.

Algorithm 2 details how a single proof com-ponent is handled by the verification pro-cess. Algorithm 3 details the overall proofverification process, making use of the single-component proof verification from Algorithm 2.

Algorithm 2 ProcessProofComponent(j, C) ⇒ T . Process the proof component C thatcorresponds to the j-th element in an AASL, andreturn the resulting j-th AASL authenticator.

1: 〈d; 〈T0, T1, . . . , TF 〉〉 ← C {Parse C.}2: if F 6= fj then3: Proof component is invalid4: end if5: P ← ∅

6: for l = 0 to F do7: L← h(j‖l‖d‖Tl) {Calculates L

lj . If the proof

is correct, then Tl must be T j−2l

in the orig-inal AASL.}

8: P ← P‖L9: end for

10: T ← h(P ) {Should calculate T j.}11: Return T

Section 4 proves the security properties ofAASLs, as described informally above. Namely,given an AASL digest known to verifiers whofollow ProcessMembershipProof, the main-tainer can only authenticate a single, uniquemembership claim per element to any of thoseverifiers, and he can determine that digest onlyafter he has decided which claims he wishes toauthenticate.

3.3 AASL Evolution

AASLs are useful in distributing the contentsof fixed-forever data sequences, but can be in-valuable in distributing the contents of data se-quences that grow over time. In this sectionwe address how AASLs can be used when thedata sequences on which they are based evolveover time, especially when the verifier needs toaccess the sequence as it changes.

As new elements are appended to a data se-quence that a maintainer keeps in an AASL, theAASL grows with new authenticators for thenew elements. Whenever it is necessary to com-

6

Algorithm 3 ProcessMembershipProof(i, n, d, T, E) ⇒ TRUE/FALSE . Process themembership proof E of the membership claim〈i, n, d〉 against authenticator T .

1: 〈C1, C2, . . . , CS〉 ← E {Parse E.}2: Tcur ← ProcessProofComponent (i, C1){Should calculate T i.}

3: Tprev ← Tcur

4: l← SingleHopTraversalLevel (i, n)5: j ← i+ 2l

6: c← 2 {Component counter.}7: while j ≤ n do8: Tcur ← ProcessProofComponent (j, Cc)

{Should return T j.}9: 〈d′; 〈T0, T1, . . . , TF 〉〉 ← Cc

10: if Tl 6= Tprev then11: Proof is invalid {The values for the same

authenticator computed in the previousstep and included in the current compo-nent differ.}

12: end if13: Tprev ← Tcur

14: l← SingleHopTraversalLevel (j, n)15: j ← j + 2l

16: c← c+ 117: end while18: if S 6= c then19: Proof is invalid {Wrong number of proof com-

ponents.}20: end if21: if Tcur 6= T then22: Proof is invalid {The T n just computed from

the proof is different from the T n known.}23: end if24: 〈d′; 〈. . .〉〉 ← C1 {Parse the datum in the first

component.}25: if d = d′ then26: Return TRUE27: else28: Return FALSE29: end if

mit to newer versions of the AASL, the main-tainer updates verifiers with the new AASL di-gest, i.e., the currently last AASL authentica-tor. In addition to the security guarantees de-scribed in the previous section, verifiers of a dy-namic AASL must also be convinced that mem-bership claims they verified in previous versionsof the AASL remain true in the new version.Simply, the AASL maintainer must be unableto “rewrite history” to which he has committedin the past when he advances to a new versionof the structure.

The preservation of AASL history is sup-ported by an advancement proof, which accom-panies the new digest in an AASL version up-date. An advancement proof is very similar to amembership proof. Intuitively, an advancementproof authenticates a membership claim aboutan authenticator, instead of a data value. Wecall this an advancement claim; it has the form“Tprev is the i-th authenticator of the AASLwhose n-th authenticator is Tnew .”

Because advancement proofs are basicallymembership proofs, their construction is al-most identical to membership proof construc-tion, and their components have the same form.Advancement proof Ai,n from the i-th to the n-th AASL authenticator is the same as member-ship proof Ei,n,d without the first proof compo-nent. The first proof component of a member-ship proof computes the authenticator of thesource element from the element datum andearlier AASL authenticators; this step is un-necessary when the source element authentica-tor is already known, as is the case with ad-vancement. In the appendix, we outline theadvancement proof construction algorithm (Al-gorithm 8). Figure 3 illustrates an example ofadvancement.

A verifier need remember three pieces of in-formation for a given remote dynamic AASL:the latest AASL size n, the latest digest T , anda vector of earlier authenticators called a basis.

The basis vector is used to check consistencyamong the values of “reusable” authenticatorsincluded in different advancement proofs for thesame AASL. Reusable authenticators are thoseAASL authenticators that may appear again in

7

0 0

3

1 2 3 4 5 6 7

0 0 0 0 0 0 0 0

1 1 1 1 1

2 2

1d

2d

3d

4d

5d

6d

7d

8d

9d

10d

Advancement 0 to 9 Adv. 9 to 10

0 8 9 10

Figure 3: An example of advancement in a dy-namic AASL. In version 1, the AASL has ele-ments 1 through 9. The corresponding advance-ment proof from the empty AASL to version 1 isA0,9 = 〈〈d8; 〈T

7, T 6, T 4, T 0〉〉, 〈d9; 〈T8〉〉〉. Then

the maintainer adds element 10 and publishesversion 2, with advancement proof A9,10 =〈〈d10; 〈T

9, T 8〉〉〉. The gray links delineate thetraversal paths that the two advancements take.

subsequent advancement proofs for the AASL.In the appendix, we illustrate an example ofcheating that a malicious AASL maintainer canperpetrate when he is free to use inconsistentvalues for such reusable authenticators acrossadvancements.

The structure of a basis vector resembles thebinary representation of the AASL element in-dex to which it corresponds. Specifically, basisBi for element i is a vector of l authenticators,where l = ⌊log2 i⌋ is the number of significantbits in the binary representation of i. The vec-tor contains a special “empty” value in thosepositions in which the binary representation ofi contains a 0; the rest of the basis vector’spositions are occupied by authenticator values.These authenticator values correspond to theauthenticators of the elements encountered inthe traversal of the AASL from element 0 to ele-ment i. A traversal from 0 to i proceeds in hopsof decreasing length, starting with the largestpower of 2 that is less than or equal to the des-tination. For example, for destination 9 (binary1001), the traversal from 0 first hops over 8 = 23

elements to element 8, and then over one lastelement (20) to element 9 (see Figure 3). In theassociated basis B9, each non-zero “bit” posi-

tion is annotated with the authenticator of theelement from which the corresponding traver-sal hop launches, that is B9 = 〈T 0,∅,∅, T 8〉.The basis B0 for the 0-th element (the initialvalue of the AASL) contains no values. Notethat verifiers need not remember bases for astatic AASLs, since the concept of advancementis meaningless in those.

Advancement proof verification occurs in twophases. First, the verifier checks whether thelast digest he holds can appear in the AASLof the new digest. This check is almost iden-tical to the verification of membership proofs,as described in Section 3.2, with the exceptionthat what is verified is the membership of anauthenticator, not a datum, in the AASL.

The second phase of checking an advance-ment proof deals with the basis. For everycomponent in the proof, the authenticators in-cluded therein are checked against the valuesof any corresponding authenticators in the ba-sis. If the component is consistent with remem-bered authenticator values, the basis is updatedwith any reusable authenticators seen first inthe component. In the end, the basis is up-dated to reflect the newly acquired digest andadvancement proof. Algorithm 4 provides thedetails, and is reminiscent of binary addition ofpositive integers.

ProcessAdvancementProofComponent isinvoked once for every component in the ad-vancement proof, after that component hasbeen processed as a membership proof compo-nent. Algorithm 5 describes how the whole ad-vancement proof verification proceeds.

A powerful use of AASLs is to determine thepossible relative orders of insertion of differentdata in the maintainer’s tamper-evident datasequence. For example, let Molly by an AASLmaintainer who claims that she did not learnvalue a until after she had committed to valueb. If verifier Van holds valid proofs of the mem-bership claims 〈i, j, a〉 and 〈k, n, b〉 in Molly’sAASL, where i < j < k < n, then he can con-vince anyone who agrees on Molly’s j-th and n-th AASL authenticators that she is lying; Mollymust have known value a before her commit-ment to the j-th authenticator, and therefore

8

Algorithm 4 ProcessAdvancementProof-Component (j, T,B,C, l) ⇒ B′. Process an ad-vancement component C that takes a hop of levell from the j-th digest T with basis B. Return thenew basis.1: 〈d; 〈T0, T1, . . . , TF 〉〉 ← C {Parse C.}2: if F 6= fj then3: Proof component is invalid {The component

contains the wrong number of authentica-tors.}

4: end if5: 〈B0, . . . , Bb〉 ← B {The values in the basis vec-

tor.}6: if Bl = ∅ then7: Bl ← T8: Return 〈B0, . . . , Bb〉9: else

10: c← l {Current basis element.}11: while Bc 6= ∅ do12: if Bc 6= Tc+1 then13: Advancement is invalid. {The main-

tainer is now sending a different value(Tc+1) for an authenticator whose valuehe reported as Bc before.}

14: end if15: carry ← Bc

16: Bc ← ∅

17: c← c+ 118: end while19: Bc ← carry20: Return 〈B0, . . . , Bmax{b,c}〉 {The vector may

have grown by one non-empty element.}21: end if

Algorithm 5 ProcessAdvancementProof(i, n, Tprev , Bprev , Tnew , A)⇒ Bnew . Process the ad-vancement proof A that establishes Tnew as the n-thauthenticator, starting with the i-th authenticatorTprev and basis Bprev . The process returns the newbasis Bnew , if successful.

1: 〈C2, . . . , CS〉 ← A {Parse A. The numberingstarts with 2, to be consistent with the num-bering in ProcessMembershipProof.}

2: c← 2 {Component counter.}3: j ← i4: while j < n do5: l← SingleHopTraversalLevel (j, n)6: Bnew ← ProcessAdvancementProof-

Component (j, Tprev , Bprev , Cc, l) {This re-

turns Bj+2l

.}7: j ← j + 2l {Next element in traversal.}8: Tcur ← ProcessProofComponent (j, Cc)

{Should be T j.}9: 〈d; 〈T0, T1, . . . , TF 〉〉 ← Cc {Parse Cc.}

10: if Tl 6= Tprev then {Tprev should be T j−2l

.}

11: Proof is invalid {The value of T j−2l

com-puted in the previous step is not the same

as the value for T j−2l

in the current proofcomponent.}

12: end if13: Tprev ← Tcur

14: Bprev ← Bnew

15: c← c+ 116: end while17: if S 6= c then18: Proof is invalid {Wrong number of proof com-

ponents.}19: end if20: if Tcur 6= Tnew then21: Proof is invalid {The T n claimed by the ad-

vancement is different from the one computedby processing the advancement proof.}

22: end if23: Return Bnew

9

before her commitment to b. Such temporal or-derings can apply also to the data themselves,when those data contain a “freshness marker”,as is the case, for example, with signed state-ments containing a nonce. We detail how tem-poral ordering in a distributed log can be pre-served in the Timeweave project [5].

In the next section, we prove the securityproperties of static AASLs, described in Sec-tion 3.2, and of dynamic AASLs, described inthis section.

4 Security Analysis

In this section, we substantiate the securityguarantees that AASLs offer to their users. Ourgoal is to secure the “commitment metaphor” ofAASLs for verifiers who follow the membershipand advancement proof verification proceduresdescribed in the previous section. Informally,this means that, first, diligent verifiers acceptonly a single, unique membership claim for ev-ery position in the data sequence on which anAASL is built; second, the data structure main-tainer must decide which membership claims hecan prove before he commits to the AASL bygiving a digest to potential verifiers.

There are two distinct “roles” that a mali-cious adversary can take, with regards to anAASL. On one hand, the adversary may be aneavesdropper, who wishes to prove to a verifiera false membership claim of his choosing, foran AASL that he does not maintain. On theother hand, the adversary may be the AASLmaintainer, who wishes either to defer choosingto which membership claim to commit until af-ter he has apparently committed; or to proveconflicting membership claims to different veri-fiers (a membership claim 〈i, n, d〉 conflicts withmembership claim 〈i, n′, d′〉 if d 6= d′). A mali-cious AASL maintainer is a more powerful ad-versary, because he can use arbitrary means toproduce a digest before he has to relay it to po-tential verifiers. In what follows, we prove thatAASLs are resistant to such attacks.

First, we show that an adversary is unable toconstruct convincing membership proofs (that

he has not already seen) from a random AASLdigest. This prevents a malicious eavesdropperfrom proving false membership claims. Thisalso prevents a malicious AASL maintainerfrom committing to bogus digests and only de-ciding later what to prove to its unsuspectingverifiers. This property is similar to the pre-image resistance property of one-way functions.

Theorem 1 (AASL Membership ProofPre-image Resistance). Consider randomlychosen T from the set of values of the hashfunction h. A computationally bound adversarycannot construct efficiently an AASL member-ship proof Ei,n,d of any datum d in position i ofan n-element AASL, for any i and n (0 < i ≤n).

This result follows directly from the pre-image resistance of the hash function h.

Suppose the adversary can pick d, i and nand construct a membership proof Ei,n,d of din position i, where T is the given n-th authen-ticator, so that a verifier in possession of T andfollowing Algorithms 2 and 3 accepts the proof.

Given Ei,n,d, i, d, n and T , Algorithm 3 exe-cuted by the verifier must fail to match the con-dition of Line 21. This means that in the lastiteration of Line 8, Tcur returned from Algo-rithm 2 must be the random T given to the ad-versary in the challenge. However, this meansthat, in Line 10 of Algorithm 2, the adver-sary must be able to find a pre-image of thepre-image resistant hash function h for randomimage T . As a result, the hypothesis is false,and the adversary cannot produce a pre-imageproof.

Theorem 1 only deals with cheap, unsophis-ticated malice. We proceed by addressing moresophisticated attacks that rely on the manipu-lation of corrupt AASLs by their maintainer oron the manipulation of observed proofs by aneavesdropper. There are three types of such at-tacks. First, the adversary can modify correctproofs to make them prove a false membershipclaim. Second, the maintainer can produce anAASL digest against which he can prove con-flicting membership claims. Third, the main-tainer can produce AASL digests and advance-

10

ment proofs so as to prove conflicting mem-bership claims against different versions of theAASL. We call the first two attacks second pre-image and collision, respectively. We call thethird attack evolutionary collision, because itrelies on subverting AASL evolution across ver-sions.

In the next theorem, we prove that AASLsare resistant to the second type of attack, col-lision attacks (Theorem 2). AASLs are also re-sistant to the first type of attack, second pre-image, but the proof is a direct corollary of col-lision resistance, so we defer to the Appendixfor it (Theorem 4).

Theorem 2 (AASL Membership ProofCollision Resistance). A computationallybound adversary cannot construct two member-ship proofs E and E′ verifiable against the sameauthenticator T that authenticate different datavalues in the same sequence position.

Suppose that an adversary can, in fact, con-struct an efficient proof collision with proofs Eand E′ against common authenticator T . Letthe two membership claims be t = 〈i, n, d〉 andt′ = 〈i, n′, d′〉, respectively (t 6= t′). We traceProcessMembershipProof backwards for bothproofs E and E′ in parallel, and reach a viola-tion of the one-way properties of the hash func-tion h.

Since both membership proofs can be verifiedagainst the same authenticator T (which corre-sponds to a purported AASL’s n-th element inthe case of E and a different purported AASL’sn′-th element in the case of E′), in the last it-eration of Line 8 of Algorithm 3, the invocationof Algorithm 2 must yield the same result T . Inthis last iteration, local variable j, the currentelement of the purported AASL, is equal to nand n′, respectively.

However, this means that the adversary mustbe able to cause the verifier to invoke Pro-

cessProofComponent with input (n,C) and(n′, C ′) but receive the same result T for bothinvocations. This is equivalent to passing toEquations 1 and 2 different i’s and T ’s but cal-culating the same T i. Intuitively, since thetwo equations use a one-way hash function,

this should be impossible, i.e., ProcessProof-Component should only return the same resultwhen invoked with identical inputs (we provethis rigorously in the Appendix, in Lemma 1).Therefore, in the last iteration ProcessProof-

Component can only be invoked with (n,C)and (n′, C ′) if n = n′. This restricts our as-sumed proof collision to support membershipclaims that only differ in the data values d andd′.

Since both proofs authenticate position i inan n-length AASL, Line 18 of ProcessMem-

bershipProof imposes that the proof lengthsmust be equal to the same S. We prove induc-tively on the number of components in the twoproofs that the two proofs must be identical.Induction follows the iterations of the loop inProcessMembershipProof, Lines 7 – 17, fromlast iteration to first.

The base case for the last components CS andC ′

S , respectively, follows directly from the col-lision resistance claim of ProcessProofCom-

ponent (Lemma 1 in the appendix) and fromthe supposition that both proofs are verifiableagainst the same authenticator T .

To establish the inductive step, consider thec-th proof components Cc and C ′

c of the twomembership proofs and assume they are equal.In the associated loop iteration in Process-

MembershipProof, Line 9 extracts the individ-ual F hash values of the c-th proof component;these are pairwise equal across the two respec-tive proof components, since the componentsthemselves are equal. The l-th of these hashvalues must be equal to the value of the respec-tive Tprev , in Line 10. Since the l-th hash valuesare equal across proofs, the values of Tprev arethe same in the invocations of ProcessMem-

bershipProof for the two membership proofs.But, in the previous loop iteration, in Line 13,Tprev had been assigned the value of the re-spective Tcur , computed using ProcessProof-

Component in Line 8. Because of the colli-sion resistance of ProcessProofComponent,this means that the inputs to the two respec-tive invocations of ProcessProofComponent

must also be identical in that loop iteration,which means that the (c − 1)-st element com-

11

ponents Cc−1 and C ′

c−1, respectively, are alsoidentical. This proves the inductive step.

The induction applies to all but the firstproof components in the two proofs, which areprocessed outside the loop of ProcessMember-

shipProof, in Lines 2 – 5. The same argu-ment as the inductive step above can also beapplied here: the Tcur returned by the respec-tive invocations of ProcessProofComponent

on the respective first proof components is thesame Tprev that ends up matching the identicall-th hash values of the respective, equal secondproof components in Line 10 of the first loop it-eration. Consequently, the respective first proofcomponents must also be equal.

We have shown that two proofs E and E′ au-thenticating the same element position i againstthe same authenticator T must be identical.But in ProcessMembershipProof, Line 25,the datum in the first component of a proofmust match the one whose membership is ver-ified. This contradicts the collision hypothesis,because the condition in Line 25 only succeedsif the algorithm is invoked with the data valuethat occupies the first proof component of thetwo proofs. d and d′ cannot be different.

Finally, we prove that AASLs are resistant tothe third type of malicious manipulation attack,evolutionary collision, in Theorem 3. AASLshave the property of evolutionary collision-resistance if it is impossible for a computation-ally constrained adversary to produce advance-ments and membership proofs that authenti-cate two different data elements d and d′ 6= dfor the same position i, in any version of thesame AASL.

The definition is fairly broad in scope: itcovers unrelated, mutually unknown verifiers Aand B, who, through different sequences of ad-vancements, arrive at the same digest T for po-sition n of an AASL at different times; a mali-cious prover must be unable to convince A thatd is at position i and convince B that d′ 6= dis at position i, even in different versions of theAASL in its separate evolution paths towardslength n and digest T .

Two advancements Ai,j and Ak,l are con-nected if the source element of the latter ad-

vancement is the destination element of the for-mer, that is j = k. In what follows, we referto a sequence of connected advancements as anadvancement sequence, and the sequence of ele-ment positions traversed by that advancementsequence as an advancement path. In a simi-lar manner, we define the sequence of elementpositions traversed by a membership proof as amembership proof path.

Our proof strategy for evolutionary collisionresistance is to show that if two diligent veri-fiers have both accepted the same authentica-tor for the same AASL element, they must ar-rive at the same value for the authenticators ofsome other strategic AASL elements. Namely,we show that the two verifiers must “agree”on the authenticators they compute during theprocessing of the membership proofs with whichthe adversary seeks to fool them. From Theo-rem 2, if two verifiers agree on the authentica-tors computed during membership proof veri-fication, they cannot be verifying the truth ofconflicting membership claims.

To reduce authenticator agreement duringthe verification of independent advancementpaths to authenticator agreement during theverification of independent membership proofs,we use two “authenticator agreement claims,”which we describe here informally, but proverigorously in the Appendix.

First, if a membership proof verification andan advancement proof verification agree on thevalue of a particular AASL authenticator, thenthey must also agree on the authenticator val-ues of all earlier AASL elements that the twopaths—the advancement and the membershipproof paths—have in common (see Lemma 7 inthe appendix).

Second, if two runs of the advancement veri-fication algorithm, applied to two different ad-vancement sequences, agree on the value of aparticular AASL authenticator, then they mustalso agree on the authenticator values of all ear-lier AASL elements that the two advancementpaths have in common (see Lemma 8 in the ap-pendix).

Equipped with these two claims, we nowtackle evolutionary collision resistance.

12

Theorem 3 (Evolutionary collision re-sistance of AASL membership proofs.).Consider two independent verifiers, A and Band a computationally constrained adversarywho conveys to them independently two ad-vancement sequences. It is impossible for theadversary to produce advancement sequencesand membership proofs in such a way that, first,the two verifiers, processing their respective ad-vancement sequences, advance to element po-sition n with the same digest T ; and, second,the two verifiers, processing separate member-ship proofs, authenticate, at any time, two con-flicting membership claims.

It is already known, from Theorem 2, thatconflicting membership claims cannot be au-thenticated against the same authenticator.Here we address the case where the two aspir-ing proofs authenticate different data values forthe same AASL position against the authenti-cators of different versions of that AASL heldby the two verifiers.

Let i be the element position for whose dataelement the adversary wishes to fool two ver-ifiers, A and B, and let j and k be the ele-ment positions against whose authenticators hewishes to produce the offending proofs for theverifiers; specifically, the adversary wishes toauthenticate the membership claims 〈i, j, d〉 toA and 〈i, k, d′〉 to B. Without loss of generality,we assume j < k, so 0 < i ≤ j < k ≤ n.

Consider the abstract illustration of thissetup in Figure 4. A’s advancement path,the dark dashed line, does not necessarily gothrough element i, but it certainly touches ele-ment j (since the adversary’s membership proofis authenticated to A against the j-th authen-ticator) and element n (since the two verifiersagree on the value of the n-th authenticator).Similarly, B’s advancement path, the lighterdashed line, does not necessarily go through el-ement i, but certainly touches elements k andn. A’s membership proof path (the thick darkline) starts from i and ends at j, and B’s mem-bership proof path (the lighter dark line) startsfrom i and ends at k.

There is an element in [j, k], element m,

B’s membership

B’s advancement

A’s membership

A’s advancement

ji nkmr

Figure 4: Illustration of the proof of Theorem 3.Verifier A advances to the n-th digest of theAASL via element j. When A held the j-th di-gest for the AASL, he had successfully authen-ticated a datum for the i-th position. VerifierB advances to the n-th digest of the AASL viaelement k. When B held the k-th digest forthe AASL, he had successfully authenticated adatum for the same i-th position as A did.

that is common among A’s advancement path,B’s advancement path, and B’s membershipproof path. This results from the fact thatB’s membership proof and advancement pathsboth start before element j and touch elementk, and A’s advancement path touches elementj and continues past element k. An intuitivereason for this is that A’s advancement pathcan skip element k only by “jumping” over iton a high-level linked list. Then, B’s member-ship proof and advancement paths must touchthe jumping-off point of A’s path, on their wayto “lower” k. We prove this claim rigorously inLemma 5, in the Appendix.

The two advancements agree on the value ofT n after processing the respective advancementsequences in ProcessAdvancementProof, asper the theorem assumption. Because ofthe second authenticator agreement claim de-scribed above, this means that the two advance-ment algorithms also agree with each other onthe value of Tm after processing the correspond-ing part of their respective advancement se-quences that brings them both to element m.

Because B’s membership proof verification,to succeed, must agree on the value of T k

13

with the advancement verification algorithm,and because of the first authenticator agree-ment claim above, the membership proof verifi-cation algorithm on B also agrees on the valueof Tm with B’s advancement verification algo-rithm after they both reach element m. There-fore, B’s membership proof verification algo-rithm and both advancement verification algo-rithms agree on the value of Tm after reachingelement m.

As above, there is an element in [i, j], ele-ment r, that is common among A’s advance-ment path, and A and B’s membership proofpaths. This is because both membership proofpaths start at i and go to or past j, and A’sadvancement path starts before i and toucheselement j (since A’s membership proof mustbe verifiable against the digest for element j,as per the theorem assumptions).

Because A’s membership and advancementproof verification algorithms must agree on thevalue of T j for the membership proof to be ac-cepted, and from the first authenticator agree-ment claim once more, the membership proofverification algorithm on A also agrees on thevalue of T r with A’s advancement algorithm af-ter reaching element r. From the same claim,since B’s membership and A’s advancementproof verification algorithms agree on the valueof Tm after reaching element m, they must alsoagree on the value of T r after they reach ele-ment r. As a result, the two membership proofverification algorithms reach element r with thesame value for T r.

However, this contradicts Theorem 2. If theadversary could manage to create two member-ship proofs starting with different data valueson element i and computing the same authen-ticator for element r, then he would be able toproduce same-version collisions, as well, whichTheorem 2 precludes. Therefore, the two dataelements d and d′ cannot be different.

5 Conclusions

In this work we describe, design and analyze thesecurity of a tamper-evident, append-only data

structure for maintaining secure data sequencesin a loosely coupled distributed system, whereindividual system components may be mutuallydistrustful. The resulting data structure, calledAuthenticated Append-Only Skip List, allowsits maintainers to produce one-way digests ofthe entire data sequence, which they can pub-lish to others as a commitment on the contentsand order of the sequence. The maintainer canproduce efficiently succinct proofs that authen-ticate a particular datum in a particular posi-tion of the data sequence against a publisheddigest.

AASLs are secure against tampering even bymalicious structure maintainers. First, we haveshown that a maintainer cannot “invent” andauthenticate data elements for the AASL af-ter he has committed to the structure. Sec-ond, he cannot equivocate by being able toprove conflicting facts about a particular po-sition of the data sequence. This is the case,even when the data sequence grows with timeand its maintainer publishes successive commit-ments at times of his own choosing.

We have implemented and extensively mea-sured the performance and storage require-ments of AASLs (we present a discussion ofpractical implementation considerations in theAppendix). We have used AASLs extensively inTimeweave [5], a system for preserving historicintegrity in trust-free peer-to-peer systems.

References

[1] Anagnostopoulos, A., Goodrich, M. T.,and Tamassia, R. Persistent AuthenticatedDictionaries and Their Applications. In Pro-ceedings of the Information Security Confer-ence (ISC 2001) (Malaga, Spain, Oct. 2001),vol. 2200 of Lecture Notes in Computer Science,Springer, pp. 379–393.

[2] Buldas, A., Laud, P., Lipmaa, H., andVillemson, J. Time-stamping with BinaryLinking Schemes. In Advances on Cryptology(CRYPTO 1998) (Santa Barbara, USA, Aug.1998), H. Krawczyk, Ed., vol. 1462 of LectureNotes in Computer Science, Springer, pp. 486–501.

14

[3] Goodrich, M. T., Tamassia, R., and Schw-erin, A. Implementation of an AuthenticatedDictionary with Skip Lists and CommutativeHashing. In 2001 DARPA Information Sur-vivability Conference and Exposition (DISCEX2001) (Anaheim, CA, USA, June 2001).

[4] Haber, S., and Stornetta, W. S. How toTime-stamp a Digital Document. Journal ofCryptology: the Journal of the International As-sociation for Cryptologic Research 3, 2 (1991),99–111.

[5] Maniatis, P., and Baker, M. Secure His-tory Preservation Through Timeline Entangle-ment. In Proceedings of the 11th USENIX Secu-rity Symposium (San Francisco, CA, USA, Aug.2002), pp. 297–312.

[6] National Institute of Standards andTechnology (NIST). Federal InformationProcessing Standard Publication 180-1: SecureHash Standard. Washington, D.C., USA, Apr.1995.

[7] Pugh, W. Skip Lists: a Probabilistic Alterna-tive to Balanced Trees. Communications of theACM 33, 6 (June 1990), 668–676.

[8] Schneier, B., and Kelsey, J. CryptographicSupport for Secure Logs on Untrusted Machines.In Proceedings of the 7th USENIX Security Sym-posium (San Antonio, TX, USA, Jan. 1998),pp. 53–62.

[9] Spreitzer, M. J., Theimer, M. M., Pe-tersen, K., Demers, A. J., and Terry,D. B. Dealing with Server Corruption in WeaklyConsistent, Replicated Data Systems. In Pro-ceedings of the Third Annual ACM/IEEE Inter-national Conference on Mobile Computing andNetworking (Budapest, Hungary, Sept. 1997),ACM/IEEE, pp. 234–240.

15

A The Need For Bases

We give here a simple example of how “forget-ting” the values of reusable authenticators canallow a malicious maintainer to authenticateconflicting membership claims across AASLversions. Consider the authenticator for ele-ment 8, in Figure 5; it is used in all membershipproofs verifiable against the digest of version 1ending with element 9, since the authenticatorfor element 9 depends on a single partial au-thenticator, that for element 8. However, theauthenticator for element 8 is also used in allmembership proofs verifiable against the digestof version 2 ending with element 10, becausethe authenticator for element 10 also dependson the authenticator for element 8 for one of itspartial authenticators.

A malicious maintainer can construct two au-thenticators T 8 and T 8′ for element 8 to ac-commodate two different elements d8 and d′8,respectively, using Equations 1 and 2, as fol-lows:

T 8 = h(h(8‖0‖d8‖T7) ‖ h(8‖1‖d8‖T

6) ‖

h(8‖2‖d8‖T4) ‖ h(8‖3‖d8‖T

0))

T 8′ = h(h(8‖0‖d′8‖T7) ‖ h(8‖1‖d′8‖T

6) ‖

h(8‖2‖d′8‖T4) ‖ h(8‖1‖d′8‖T

0))

He can then construct a single authenticator T 9

for element 9 based on T 8′:

T 9 = h(h(9‖0‖d9‖T8′))

and use it to commit to version 1, which ends atelement 9, with this T 9 and the first advance-ment proof A0,9:

A0,9 = 〈〈d′8; 〈T7, T 6, T 4, T 0〉〉, 〈d9; 〈T

8′〉〉〉

The digest T 9 for version 1 authenticates d′8 inposition 8 with the following membership proof:

E8,9,d′8 = 〈〈d′8; 〈T

7, T 6, T 4, T 0〉〉, 〈d9; 〈T8′〉〉〉

Now the malicious maintainer can constructa corrupt authenticator T 10 for the 10-th ele-ment, by mixing T 8 from the AASL that con-tains d8 in position 8, and T 9, from the AASLthat contains d′8 in position 8:

T 10 = h(h(10‖0‖d10‖T9)‖h(10‖1‖d10‖T

8))

0 0

3

1 2 3 4 5 6 7

0 0 0 0 0 0 0 0

1 1 1 1 1

2 2

1d

2d

3d

4d

5d

6d

7d

8d

9d

10d

Advancement 0 to 9 Adv. 9 to 10

0 8 9 10

Figure 5: A repeat of Figure 3. An ex-ample of advancement in a dynamic AASL.In version 1, the AASL has elements 1through 9. The corresponding advancement isA0,9 = 〈〈d8; 〈T

7, T 6, T 4, T 0〉〉, 〈d9; 〈T8〉〉〉. Then

the maintainer adds element 10 and pub-lishes version 2, with advancement A9,10 =〈〈d10; 〈T

9, T 8〉〉〉. The gray links delineate thetraversal paths that the two advancements take.

and publish it as the digest for version 2, withthe corresponding advancement proof

A9,10 = 〈〈d10; 〈T9, T 8〉〉〉

In conflict to version 1, version 2 authenticateselement d8 in position 8, with the followingmembership proof:

E8,10,d8 = 〈〈d8; 〈T7, T 6, T 4, T 0〉〉, 〈d10; 〈T

9, T 8〉〉〉

The problem lies in the verifier’s forgettingthat the value for the purported authentica-tor of element 8 was T 8′ in the first advance-ment A0,9 to version 1, whereas the same au-thenticator has the value T 8 6= T 8′ in the sec-ond advancement A9,10 from version 1 to ver-sion 2. To avoid this problem, verifiers keeptrack of reusable authenticators, such as T 8

in the example above. With every advance-ment received, a verifier checks that any reusedauthenticators in the advancement agree withthose known so far in the basis for the sameAASL; then, the verifier updates that basiswith any new reusable authenticators includedin the newly received advancement.

16

B Algorithms

Here we describe the proof construction algo-rithms in detail. They do not participate inany of the security proofs, since the securityguarantees offered by AASLs have to do withwhat claims diligent verifiers accept.

First, Algorithm 6, describes how individ-ual proof components are constructed. Theseproof components participate in both member-ship and advancement proofs.

Algorithm 6 SingleProofComponent (j) ⇒C. Return a proof component C for the AASL ele-ment in position j.

1: Tvec ← ∅ {Authenticators.}2: for l = 0 to fj do

3: Tvec ← Tvec‖Tj−2

l

4: end for5: C ← 〈dj ;Tvec〉6: Return C

Then, we proceed by describing how a wholemembership proof (Algorithm 7) and a wholeadvancement proof (Algorithm 8) are con-structed.

Algorithm 7 ConstructMembershipProof(i, n) ⇒ E. Return a membership proof E for thei-th element of an AASL, verifiable against the n-thauthenticator, where n ≥ i.

1: E ← ∅ {The proof.}2: j ← i {Current element.}3: repeat4: C ← SingleProofComponent (j)5: E ← E‖C6: l← SingleHopTraversalLevel (j, n)7: j ← j + 2l

8: until j > n9: Return E

C Proofs of Additional Claims

In this appendix, we prove the intuitive claimswe have used in the security analysis of the pa-per.

First, we prove a claim necessary forthe collision-resistance theorem (Theorem 2),

Algorithm 8 ConstructAdvancementProof(i, n) ⇒ A. Construct an advancement proof fromthe i-th authenticator of an AASL to the n-th au-thenticator, where n > i.

1: A← ∅ {The proof.}2: j ← i {Current element.}3: while j < n do4: l← SingleHopTraversalLevel (j, n)5: j ← j + 2l

6: C ← SingleProofComponent (j)7: A← A‖C8: end while9: Return A

showing that ProcessProofComponent iscollision-resistant.

Lemma 1 (Different proof componentscannot yield the same authenticator).Consider two independent invocations of Pro-

cessProofComponent with inputs (j, C) and(j′, C ′) respectively. If the two invocations yieldthe same result T , then the inputs must be iden-tical (j = j′ and C = C ′).

In both invocations, Line 10 must yield thesame result T . Since h is collision resistant, theinput P to the hash function must be the sameacross invocations.

Input P is constructed in the loop of Lines 6- 9, by concatenating a hash result, produced inLine 7, to the running P in every iteration. Toensure that P is the same in both invocations,the loop must be iterated the same number oftimes (so as to construct P ’s of the same bitlength), and all appended L-elements in the re-spective invocations must be identical.

At every iteration of the loop, Line 7 com-putes the current L by hashing together theindex j of the assumed AASL element towhich the current proof component should cor-respond, the iteration number l (which is, bydefault, the same across invocations), the pur-ported data value of the j-th AASL element,and the l-th authenticator value contained inthe proof component. Again, due to the col-lision resistance of the hash function h, theL values computed in the two invocations canbe identical only if the input index j is equal

17

across invocations, and, similarly, if all partsof the input proof component C are respec-tively identical. This means that two invoca-tions of ProcessProofComponent for inputs(j, C) and (j′, C ′) can yield the same T if andonly if j = j′ and C = C ′.

As mentioned in the paper, second pre-imageresistance is a corollary of the collision resis-tance theorem.

Theorem 4 (AASL Membership ProofSecond Pre-image Resistance). Considera membership proof Ei,n,d that verifies againstauthenticator T the membership claim 〈i, n, d〉,where 0 < i ≤ n, and d is a data value. A com-putationally bound adversary cannot constructefficiently a different membership proof E′ veri-fiable against the same authenticator T that au-thenticates a conflicting membership claim.

Suppose that an adversary can, in fact, con-struct efficiently such a second proof E′ for themembership claim t′ = 〈i, n′, d′〉, where n 6= n′

or d 6= d′. This means that he has an efficientway to construct collisions as well: he createsa legitimate AASL, picks a random positionand constructs a membership proof E for it,then constructs another membership proof E′

for a different data element in the same posi-tion. The two proofs would be a collision asdefined in Theorem 2. However, we have al-ready shown that collisions are not possible, sothe proof machinery must also be second pre-image resistant.

Before we can prove the authenticator agree-ment claims, we must first establish thatskip list traversal, as described by SingleHop-

TraversalLevel, follows the rules of the skiplist, specifically that both source and destina-tion of an l-level hop are divisible by 2l.

Lemma 2 (Correctness of skip list traver-sal). In both advancement paths and member-ship proof paths, as accepted by the verifica-tion algorithms ProcessAdvancementProof

and ProcessMembershipProof, respectively,every hop from element i to element j haslength 2l, such that 2l divides both i and j.

We prove this claim informally, by inspectionof the corresponding algorithms.

The path of an advancement is verifiedby ProcessAdvancementProof. The verifiedpath starts with the source element i, givenin the input parameters to the algorithm, andproceeds by increments of 2l in Line 7 insidethe loop. The exponent l of the path lengthis determined by SingleHopTraversalLevel,given the current element j and the ultimatedestination n of the advancement.

Similarly, a membership proof path is veri-fied by ProcessMembershipProof. The pathstarts with the source element i where the ele-ment to be authenticated is claimed to reside inthe input parameters. Then the path proceedsby increments of 2l in Line 5 for the first hopand Line 15 for all subsequent hops. Both linesreceive their l from the result of SingleHop-

TraversalLevel, given the current element j(i in the case of Line 5) and the ultimate desti-nation n of the membership proof.

For both types of paths, it suffices to showthat the l computed by SingleHopTraversal-

Level is such that 2l divides j. Then it mustalso divide the destination j + 2l. SingleHop-

TraversalLevel uses as a fall-through selec-tion of l the value 0, which is consistent withthe claim, since 20 = 1 divides all elements.When the loop in the algorithm is executed atleast once, the variable L returned is alwaysone that has passed the conditional check ofthe loop, that is, 2L divides the source elementj (called i in SingleHopTraversalLevel).

We have shown that membership proofpaths, and paths of single advancements sat-isfy the claim. For advancement paths of mul-tiple advancements the claim also holds, sinceconnected advancements share an element: theearlier one ends where the later one begins.This means there are no additional hops in theresulting advancement path to those includedin the individual advancements, which alreadysatisfy the claim as we showed above.

We continue by analyzing the concept of thebasis. We use the two lemmata below in au-thenticator agreement.

18

Lemma 3 (Correspondence of bases tobinary representations). Given the l-thAASL element, if the binary representationbkbk−1 . . . b0 of l has a 0 in bit position i, thenthe corresponding basis vector Bl has an emptyvalue in vector position i, and a non-emptyvalue otherwise.

Bases are changed only via ProcessAd-

vancementProofComponent, so we concen-trate on that to prove this lemma. We provethe lemma by induction on all AASL elements,and for every element on all hop lengths leadingto that element.

By definition, the base case holds, since B0

has only empty values, just as the binary rep-resentation of 0 has only 0’s.

We assume that the lemma holds for all basesup to that of element k − 1: that is, the basisvector for AASL element index m ≤ k − 1 hasan empty value in position l if and only if thebinary representation of m has a 0 in bit posi-tion l. We show that this must also hold for thebasis Bk that corresponds to element index k.

ProcessAdvancementProofComponent

yields the basis Bk for element index k when-ever its input contains the source elementindex j and the hop level l and j = k − 2l.ProcessAdvancementProof expects the out-come of such an invocation to be Bk = Bj+2l

in Line 6.

There are fk + 1 ways in which ProcessAd-

vancementProofComponent can be invokedto return Bk, one for each different level l atwhich an advancement path reaches element k.This is because, as shown in Lemma 2, Line 5 ofProcessAdvancementProof can only return lssuch that the source (and consequently the des-tination) of the level-l hop (computed in Line 7)is divisible by 2l. Since fk is the exponent of thelargest power of 2 that divides k, as per Equa-tion 3, there are fk + 1 invocations of Line 6that make variable j in Line 7 to take the valuek.

We consider invocations of ProcessAd-

vancementProofComponent for all l suchthat 0 ≤ l ≤ fk, where j = k − 2l and B = Bj.All of the possible input bases B = Bj corre-

spond to element indices j that precede k, andas a result are covered by the inductive hypoth-esis, above.

In the “then” branch of the conditional(Line 7), the previous AASL element index jhad a 0 in the l-th bit position of its binaryrepresentation. By turning that 0 to a 1 viaassigning a non-empty value to the l-th basisvector element, we add 2l to the binary repre-sentation of j = k − 2l, and we therefore reachthe binary representation for k.

If, instead, the “else” branch of the condi-tional is executed, the previous basis vectormust have had a non-empty value in its l-thposition, and, as a result, the binary represen-tation of j must have had a 1 in the l-th bit posi-tion of its binary representation. The algorithmplaces empty values in all vector positions fromthe l-th one upwards that contain non-emptyvalues and sets to a non-empty value (the valueof the carry variable) the first vector positionm > l that it finds containing an empty value.This translates into zeroing out all 1 bits in thebinary representation of j from the l-th to them − 1-st bit positions, and placing a 1 in theformerly 0 m-th bit. Zeroing out a 1 bit in posi-tion p means subtraction by 2p, so the result ofthe operation is to add (2m−

∑m−1

p=l 2p = 2l) to

the binary representation of j = k − 2l, whichagain yields the binary representation of k.

This proves the inductive step, and as a re-sult the lemma holds for all bases computed byProcessAdvancementProofComponent.

Lemma 4 (Survival of authenticators ina basis). Consider a portion of an advance-ment path that goes through elements e ande′ = e+2l, for non-negative integers e and l. IfT e is the authenticator for element e computedby the advancement processing algorithm afterreaching that element, then the value for T e ispreserved by the algorithm in the basis, and stillregarded as that of T e during processing of ele-ment e′.

Informally, this lemma claims that while pro-cessing intermediate hops between two elementsthat are successive multiples of 2l, the advance-ment verification algorithm remembers the au-

19

thenticator of the first multiple, and uses itsvalue to check the correctness of the processedadvancement component when it reaches thesecond multiple.

Since both e and e′ are divisible by 2l, thenin the binary representation of e, bits 0 throughat least l− 1 are all 0. Because of Lemma 3, allbasis elements in positions 0 through at leastl − 1 must be the empty value.

Case 1: e and e′ are consecutive ele-ments in the advancement path. The ad-vancement path takes a single hop at level lfrom e to e′. To process this advancement hop,the verifier executes an iteration of the loopin ProcessAdvancementProof where the lo-cal variable j is equal to e and the level returnedin Line 5 is l.

The value for T e was either passed as inputTprev to the algorithm, if this hop is the firstin its advancement, or computed and storedin Tcur in the previous iteration of the loop inLine 8, and then copied to Tprev in Line 13.

Trivially, therefore, the value of Tprev , whichthe algorithm regards as T e during the loop it-eration that starts with j = e, is passed as inputto ProcessAdvancementProofComponent inLine 6 and checked for consistency in Line 10.This proves the claim for this case.

Case 2: e and e′ are not consecutive ele-ments in the advancement path. Leavingelement e, the advancement path takes a hop atlevel p, where p < l. Therefore, during the in-vocation of ProcessAdvancementProofCom-

ponent that takes as input the basis of elemente, Line 7 is executed. What the algorithm re-gards at the time as T e (passed to it in its inputparameters) is placed in the p-th position of thebasis. Since all vector positions up to positionl−1 contained the empty value before this mod-ification, T e is the last (indeed, the only) non-empty value in the newly created basis vectorin positions 0 through l − 1.

In what remains of the advancement path toe′, the value for T e is always the last non-emptyelement in vector positions 0 through l−1. This

is the case right after advancement element ehas been processed, as shown above. We usethis fact as the base case of an inductive argu-ment.

Assume that T e is the last non-empty valuein the first l elements of the basis vector, andit occupies position q < l. From Lemma 3,the current element index is only divisible, atmost, by powers of 2 up to 2q. This means thatthe next advancement hop, as determined bySingleHopTraversalLevel in Line 5 of Pro-

cessAdvancementProof can only proceed bya hop of length that is a power of 2 up to 2q.This only changes the q+1 least significant bitsof the element’s binary representation. There-fore, even if the “else” branch of the conditionalin ProcessAdvancementProofComponent isexecuted, the value of T e is the last non-emptyvalue before the l-th element of the basis, andas a result is pushed to a higher element posi-tion of the basis.

The only advancement hop that can elimi-nate T e from the first l elements of the ba-sis is the last one, leading to e′. Then valueT e occupies position (l − 1) of the basis: weshowed above there cannot be any non-emptyvalues between itself and position l, and thevalue must be eliminated from the first l posi-tions of the basis, since e′ is divisible by 2l andhas no 1’s in its binary representation up to andincluding bit position l − 1.

This means that when element e′ is reachedby the advancement proof verification algo-rithm, the value for T e is in the basis, in po-sition l− 1. This is the basis vector position inwhich the algorithm expects to find the valuefor T e during consistency checking in Line 12 ofProcessAdvancementProofComponent. In-deed, the last advancement proof componentthat is processed is the one corresponding toelement index e′, which has in the l-th posi-tion among its included authenticators whatthe prover sent as T e′−2l = T e. Note thatwhen Line 12 is executed and eliminates valueT e from basis vector position l − 1, the localloop variable c is equal to l − 1.

Consequently, we have shown that the claimholds for both possible cases of advancement

20

paths between e and e′, which proves thelemma.

The proofs for evolutionary collision resis-tance and for the authenticator agreement lem-mata rely heavily on common elements inmembership or advancement proof paths. Weproceed with two lemmata that examine thearrangement of common elements of parallelpaths. First, we look at common elements ofparallel paths, regardless of the path type (ad-vancement or membership proof). Then, weshow that between two common elements in amembership proof and advancement path, theadvancement path always takes shorter hopsthan the membership proof path.

Lemma 5 (Common elements of parallelpaths). Let i and j be positive integers, suchthat i < j.

1. Consider a path A that includes element iand continues to j or past it. There is atleast one element in [i, j] that is shared byA and every path that starts at or before iand includes element j. The last elementon path A before j (or j if it is in path A)is such an element.

2. (The mirror case) Consider a path A thatstarts at or before element i and includeselement j. There is at least one elementin [i, j] that is shared by A and every paththat includes element i and continues toelement j or past it. The first element onA after i (or i if it is in path A) is such anelement.

We prove only the first part of the lemma.The proof for the second part of the lemma is atrivial “mirror image” of the proof for the firstpart.

If path A contains element j, then we aretrivially done.

Now, assume that path A does not containelement j, and consider Figure 6. Path A mustbe able to overshoot element j on its way fromi to beyond j. For this to happen, path A mustadvance from its last element m before j (i.e.,i ≤ m < j) past j, by a hop of level l and

n

Level l’ hop

Level l hop

Path A

Path B’

m ji

Figure 6: Two parallel, interleaved paths A andB. A contains i, but not necessarily j. B con-tains j but not necessarily i. The thick graylines represent single hops, as picked by Sin-

gleHopTraversalLevel.

length 2l, where 2l divides m, and j must notparticipate in any linked list at level l or higher(i.e., 2l does not divide j). The end point ofthis hop is m+ 2l > j.

Suppose m is not the single common elementamong path A and every path that starts ator before i and includes element j. Then theremust be a path B′ that manages to overshootelement m on its way to j. For this to happen,path B′ must advance to its first element n afterm (i.e., m < n ≤ j) past m, by a hop of level l′

and length 2l′

, and element m must not partic-ipate in any linked list at level l′ or higher (i.e.,2l

′

does not divide m). This means that l′ > l,since m is divisible by 2l. If n participates inthe linked list at level l′, it must be divisible by2l

′

and, as a result, also by 2l. However, that isimpossible, since m < n ≤ j < m+ 2l.

Therefore, every path B that starts at or be-fore i and includes j must include element m,which also belongs to path A.

Lemma 6 (Common elements of proofand advancement paths). If a membershipproof path has two common elements e and e′

with an advancement path, then every elementin the proof path between e and e′ is also sharedby that advancement path.

Consider a membership proof path and anadvancement path that share elements e ande > e′, but share no other elements betweenthem.

To prove the lemma, we suppose that none ofthe proof elements between e and e′ belong to

21

Level l hop

AdvancementProof

e q 'ep

Figure 7: Proof and advancement paths be-tween their common elements e and e′. Thethick gray line indicates a single hop, as calcu-lated by SingleHopTraversalLevel.

the advancement path (see Figure 7). We showbelow that this hypothesis leads to a contradic-tion.

After common element e, the two paths di-verge. The membership proof takes a hop atlevel l, whereas the advancement takes a hopat a lower level l′ < l. The advancement can-not take a hop at a level higher than that ofthe proof; if such a hop were available thatdid not overshoot e′, then the proof would havealso taken it (see SingleHopTraversalLevel).Furthermore, the advancement cannot take ahop at the same level l as the proof, becausethat would make the two paths identical be-tween e and e′, which contradicts the hypoth-esis that intermediate membership proof ele-ments do not belong to the advancement path.We call the next element on the advancementpath p = e + 2l

′

, and the next element on themembership proof path q = e+ 2l.

Because of Lemma 5, there must be a com-mon element between the two paths in [p, q].However, this contradicts the hypothesis thatthe two paths share no elements between e ande′. As a result, all membership proof elementsbetween e and e′ must also belong to the ad-vancement path.

Finally, we prove the two authenticatoragreement lemmata.

Lemma 7 (Authenticator agreement be-tween a membership proof and an ad-vancement proof verification). If the mem-bership proof verification Algorithm 3 and theadvancement verification Algorithm 5, given an

advancement sequence and a membership proof,respectively, agree on the value of authenticatorT n for element n during their independent ex-ecutions, then they also agree on the authenti-cator value T e of every other earlier element e(e < n) that the advancement path and mem-bership proof path have in common.

Let k be the number of common elements inthe two paths up to element n, and n = e1 >e2 > . . . > ek the common elements, from lastto first. We prove the lemma using inductionon the common elements ei, by following back-wards Algorithms 3 and 5.

The base case for e1 holds from the lemmaassumption, since e1 = n.

For the inductive step, we assume that thetwo algorithms agree on the value of T ei . Wemust show that the two algorithms also agreeon the value of T ei+1 when they process the cor-responding proof component to reach elementei+1.

When the two algorithms process their re-spective proof component to compute the com-mon T ei they use Equations 1 and 2. Specifi-cally, they both compute

T ei = h(. . . ‖Llei‖ . . .)

= h(. . . ‖

Llei

︷ ︸︸ ︷

h(ei‖l‖di‖Tei−2l) ‖ . . .)

by invoking ProcessProofComponent inLine 8 of ProcessMembershipProof andLine 8 of ProcessAdvancementProof. Sinceh is collision resistant, when the two algorithmsprocess element ei they must agree on the val-ues of all T ei−2l , for every level l of linked listsin which element ei participates.

Consider what happens in the two paths be-tween elements ei+1 and ei. Common elementei+1 must be the membership proof element im-mediately preceding ei, because of Lemma 6.Therefore, because of Lemma 2, ei = ei+1 + 2l

′

for some non-negative l′. The advancement hopthat arrives at ei must be at the same level l′

or lower level. This is because a higher-levell′′ > l′ hop would have taken the advancementpath from ei+1 to element ei+1+2l

′′

, which must

22

lie beyond ei = ei+1 + 2l′

. Therefore, the ad-vancement path between ei+1 and ei follows ei-ther a single hop of level l′ and length 2l

′

, whichis identical to that followed by the membershipproof path, or a sequence of shorter hops atlevels lower then l′.

Case 1: The advancement path is iden-tical to the membership proof path. Thevalue for T ei+1 used to compute T ei in thetwo algorithms while processing element ei isthe same as that known by the algorithmswhile processing the previous element ei+1,from Line 10 of ProcessMembershipProof

and Line 10 of ProcessAdvancementProof,which proves the inductive step.

Case 2: The advancement path is notidentical to the membership proof path.We must establish that the value of T ei+1 thatProcessAdvancementProof computes whileprocessing element ei+1 is the same as thatknown while processing the next common el-ement ei. This follows from Lemma 4, sinceelements ei+1 and ei are successive multiples of2l

′

.

As a result, the value for T ei+1 produced bythe advancement verification algorithm whileprocessing element ei+1 is the same as the valuefor T ei+1 used by the membership proof verifi-cation algorithm while processing element ei.This is the same value as that for T ei+1 pro-duced by the proof verification algorithm whileprocessing element ei+1, as seen in Line 10 ofProcessMembershipProof. This proves theinductive step.

The inductive step holds for both possi-ble cases of advancement paths, and as a re-sult, the inductive argument holds, proving thelemma.

Lemma 8 (Authenticator agreement be-tween two independent advancementpaths). If two invocations of the advancementverification Algorithm 5, given two advance-ment sequences, respectively, agree on the valueof authenticator T n computed after reaching el-ement n during their independent executions,

then they also agree on the authenticator valueT e computed after reaching every other earlierelement e (e < n) that the advancement pathshave in common.

This proof is similar in structure to that ofthe preceding lemma.

Let k be the number of common elements inthe two paths up to element n, and n = e1 >e2 > . . . > ek the actual elements, from lastto first. We prove the lemma using inductionon the common elements ei, by following back-wards two invocations of Algorithm 5.

The base case for e1 holds from the lemmaassumption, since e1 = n.

For the inductive step, we assume that thetwo algorithms agree on the value of T ei , afterreaching element ei. We must show that thetwo algorithms also agree on the value of T ei+1

after they reach element ei+1.

When the two algorithms process their re-spective proof component to compute the com-mon T ei they use Equations 1 and 2. Specifi-cally, they both compute

T ei = h(. . . ‖Llei‖ . . .)

= h(. . . ‖

Llei

︷ ︸︸ ︷

h(ei‖l‖di‖Tei−2l) ‖ . . .)

by invoking ProcessProofComponent inLine 8 of ProcessAdvancementProof. Sinceh is collision resistant, when the two algorithmruns process element ei they must agree on thevalues of all T ei−2l , for every level l of linkedlists in which element ei participates.

Consider what happens in the two paths be-tween elements ei+1 and ei.

Case 1: Element ei+1 immediately pre-cedes element ei in both paths. Bothpaths advance from ei+1 to ei in a single hop atlevel l, of length 2l.

As shown above, the two runs agree on thevalue of T ei−2l . Since ei − 2l = ei+1, and fromLine 10 of ProcessAdvancementProof, thevalue for T ei+1 while processing element ei mustbe identical to the value that the two runs com-

23

pute for T ei+1 after processing the advancementat the previous element ei+1.

Case 2: Element ei+1 does not immedi-ately precede element ei in at least oneof the paths. The two paths merge fromtwo different immediate sources to element eion their way from element ei+1. Because ofLemma 2, for some non-negative integers 0 ≤l < l′ without loss of generality, the elementimmediately preceding ei on the first path isp = ei − 2l, and on the second it is q = ei − 2l

′

.Note that q < p.

Lemma 5 guarantees that there must be acommon element between the two paths in[q, p], since the first path starts at or beforeq and reaches p on its way to ei, whereas thesecond path starts at q and goes past p on itsway to ei. Since q is the element immediatelypreceding ei on the second path, it must bethe common element that Lemma 5 anticipates.Therefore, ei+1 = q.

Because of Lemma 4, both runs of the ad-vancement verification algorithm agree on thevalue of T ei+1 after processing element ei+1 andafter reaching element ei.

The inductive step holds for both possiblecases of advancement path commonalities and,as a result, the inductive argument holds, prov-ing the lemma.

D Implementation

We implement authenticated append-only skiplists using Java. We focus here on a disk-basedimplementation, since it allows much largerdata sequences than any memory-only imple-mentation can, as well as persistence in the faceof machine reboots.

An AASL is stored on disk as a linear filethat consists of a preamble and a sequence ofelement entries, one for each element currentlycontained in the AASL. An element entry con-sists of a data section and an authenticator sec-tion.

The data section primarily holds the datumstored in the associated AASL element. This is

the datum that participates in the computationof authenticators, as per Equations 1 and 2. Wecall this the sensitive datum. Every element ina single AASL has sensitive data of a constantlength, which is set when the AASL is initiallycreated.

The data section of element entries may alsocontain an insensitive datum. This is also afixed-length bit string. However, it does notparticipate in authenticator computations. In-sensitive data may be useful information to themaintainer, collocated with the sensitive datafor access efficiency, that need not be authen-ticated to remote verifiers of the AASL. Sinceinsensitive data do not participate in authen-ticator computations, they can be changed atwill by the AASL maintainer unobtrusively toAASL verifiers.

The authenticator section of an element entrycontains the authenticator computed for thatelement.

The preamble of the AASL file contains thelengths in bytes of the sensitive and insensitivedata in element entries, and the element posi-tion of the last incorporated element into theAASL.

An empty AASL contains exactly one ele-ment entry: the entry for element 0, which is aspecial entry. Element entry 0 has inconsequen-tial sensitive and insensitive data. Only its au-thenticator is meaningful. This authenticatoris a value from the result domain of the hashfunction used, and it is agreed upon among allusers of the AASL in advance.

Our implementation has a deviation fromthe abstract design of AASLs described in Sec-tion 3. We slightly modify how authenticatorsare computed for elements of odd indices, whichonly participate in a single linked list. For suchelements we skip the outer hash operation de-scribed in Equation 2, from concatenated par-tial authenticators to the actual authenticatorof the element. Since odd elements have only asingle partial authenticator, that single partialauthenticator is sufficient to ensure the collisionresistance of AASL digests, and can serve as theactual authenticator of the element. Further-more, since half of the element indices are odd,

24

this savings in computation can be significantcompared to the overall computation requiredby AASL operations.

Another implementation optimization in theimplemented AASLs deals with authentica-tor redundancy in membership and advance-ment proofs. In the idealized algorithmsProcessMembershipProof and ProcessAd-

vancementProof, authenticators computedfor the previous proof component are com-pared against the corresponding authentica-tor included in the next proof component (seeLines 10 and 10, respectively). Since we com-pute these authenticators in the process of veri-fying membership and advancement proofs any-way, there is no need also to include them in theproofs themselves. Consequently, we skip suchauthenticators in the AASL implementation.

$Id: PODC2003.tex,v 1.23 2003/02/07 01:11:25 maniatis Exp $