Question: authenticated data structures you are designing securebox an authenticated online...
Authenticated Data Structures. You are designing SecureBox, an authenticated online file storage system. For simplicity, there is only a single folder. Users must be able to add, edit, delete, and retrieve files, and to list the folder contents. When a user retrieves a file, SecureBox must provide a proof that the file hasn’t been tampered with since its last update. If a file with the given name doesn’t exist, the server must report that — again with a proof.
We want to minimize the size of these proofs, the time complexity of verifying them, and the size of the digest that the user must store between operations. (Naturally, to be able to verify proofs, users must at all times store some nonzero amount of state derived from the folder contents. Other than this digest the user has no memory of the contents of the files she added.)
Here’s a naive approach. The user’s digest is a hash of the entire folder contents, and proofs are copies of the entire folder contents. This results in a small digest but large proofs and long verification times. Besides, before executing add/delete/edit operations, the user must retrieve the entire folder so that she can recompute the digest.
Alternatively, the digest could consist of a separate hash for each file, and each file would be its own proof. The downside of this approach is that it requires digest space that is linear in the number of files in the system.
Can you devise a protocol where proof size, verification time, and digest size are all sublinear? You might need a sub‐protocol that involves some amount of two‐way communication for the user to be able to update her digest when she executes and add, delete, or edit.
Hint: use the Merkle tree idea from Section 1.2. (Page 32-36) ( https://d28rh4a8wq0iu5.cloudfront.net/bitcointech/readings/princeton_bitcoin_book.pdf )