Oblivious TreesA Concurrent Cryptographic Data Structure

William StricklandChristopher Fontaine

[10-12-2011]

Table of Contents

1. Digital Signatures2. Incremental Signatures

a. Concernsb. Early Work

3. Oblivious Treesa. Obliviousnessb. Implementationc. Concurrencyd. Goalse. Challengesf. Test Application Domains

4. References5. Q & A

Digital Signatures• Useful for detecting or preventing forgery and

tampering of digital data.• Most useful with asymmetric key schemes.• Critical to Software distribution, Email, E-commerce.• Many algorithms and schemes exist.• Any change to the document invalidates the

signature, even authorized changes.• Can a new valid signature be generated by only

processing the updates of the document?

Incremental Signatures• Potential performance improvements in applications

where signatures a repeatedly computed for often changing documents.

• Signature generation proportional to updates.• Signature size and verification difficulty does not grow

with repeated updates.• Must maintain security and privacy of non-incremental

schemes.• Security to tampering and forgery.• Privacy of revision history.

Incremental Concerns• Security more complicated with incremental signatures.• Security is of foremost concern.• Attacker has new avenues to attack observing result of incremental

changes.• No longer practical to hide which chunks have changed with a fast

algorithm.• Privacy becomes an issue.• No previous versions to be concerned with in non-incremental.• Do no wish to leak information about previous edits with signature.• Some incremental signature schemes may be secure while still

leaking revision history.

Early Work• An early incremental signature scheme presented by

Bellare, Goldreich and Goldwasser in 1994 utilized 2-3 trees to provide incremental signatures with proven security.

• Utilized generic non-incremental signature function as building block.

• This scheme was later found to leak revision history in by the structure of the tree.

• Previous state information was leaked solely by the structure of the 2-3 tree.

Obliviousness• An Oblivious data structure is defined as one

that reveals no information about what operations have been performed on it.

• Adding the oblivious property to the 2-3 tree signature scheme would resolve the privacy issues.

Oblivious Trees• Implementation– 2-3 Tree Basis– Why?• Leaf Nodes at the same level

– Fast Access to leaves– Good probability of a balanced tree

• Leaf Nodes are in sorted order– Easy to locate using only size information

Oblivious Trees• Implementation– Create

• O(n)

– Insert• O(log n)

– Delete• O(log n)

• Key Issues– Maintain Obliviousness– Maintain Performance

Oblivious Trees• CREATE– Observation: Structure Reveals History

• Bottom-up Construction• foreach(level i)

1. Traverse nodes from right to left2. Choose d from {2,3} uniformly at random

a. Or set d to number of nodes left

3. Create a new node with d as its degree4. Stop when number of nodes created = 1

Oblivious Trees• INSERT

1. INSERT(b, i, CREATE(L)) == CREATE(L')2. Locate the ith leaf3. Insert new node b4. Starting from i's parent

1. foreach(level l)– Moving from left to right, rebuild the tree in the same manner

as CREATE, but with new random coin tosses.

Oblivious Trees• DELETE

1. DELETE(i, CREATE(L)) == CREATE(L')2. Locate the ith leaf3. Delete the ith leaf4. Starting from i's parent

1. foreach(level l)– Moving from left to right, rebuild the tree in the same manner

as CREATE, but with new random coin tosses.

Oblivious Tree

R

?

L L L L L L

Root

InternalNodes

Leaves

Approach to ConcurrencyObservations• Tree structure is randomized.• There is no 'correct' tree structure, so long as

the result is a 2-3 tree.• Outputting the current signature is akin to a

snapshot of the tree. • Inserts and deletes only randomize the tree

structure to the right of the affected index.

Goals• First known implementation of Oblivious Tree

data structure• Lock-free implementation of Oblivious Trees• Prove lock-free nature of implementation• Create representative parallel test application• Show improved performance over non-

incremental signature schemes in test application

Challenges• Creating a sequential implementation• Refine sequential implementation to be lock-

free• Exploit randomized structure to enable

concurrency• Develop test application and test data set• Tune hashing function and chunk size

Test Application Domains• Signed Source Code Repository• Incremental Backup• Streaming Security Footage• Collaborative Photo/Text Editing

References1. Daniele Micciancio. 1997. Oblivious data structures: applications to cryptography. In

Proceedings of the twenty-ninth annual ACM symposium on Theory of computing (STOC '97). ACM, New York, NY, USA, 456-464. DOI=10.1145/258533.258638 http://doi.acm.org/10.1145/258533.258638

2. Mihir Bellare, Oded Goldreich, and Shafi Goldwasser. 1994. Incremental Cryptography: The Case of Hashing and Signing. In Proceedings of the 14th Annual International Cryptology Conference on Advances in Cryptology (CRYPTO '94), Yvo Desmedt (Ed.). Springer-Verlag, London, UK, 216-233.

3. Qingji Zheng and Shouhuai Xu. 2011. Fair and dynamic proofs of retrievability. In Proceedings of the first ACM conference on Data and application security and privacy (CODASPY '11). ACM, New York, NY, USA, 237-248. DOI=10.1145/1943513.1943546 http://doi.acm.org/10.1145/1943513.1943546

4. Mihir Bellare and Daniele Micciancio. 1997. A new paradigm for collision-free hashing: incrementality at reduced cost. In Proceedings of the 16th annual international conference on Theory and application of cryptographic techniques (EUROCRYPT'97), Walter Fumy (Ed.). Springer-Verlag, Berlin, Heidelberg, 163-192.