Cargando…

UC Updatable Databases and Applications

We define an ideal functionality [Formula: see text] and a construction [Formula: see text] for an updatable database ([Formula: see text]). [Formula: see text] is a two-party protocol between an updater and a reader. The updater sets the database and updates it at any time throughout the protocol e...

Descripción completa

Detalles Bibliográficos
Autores principales: Damodaran, Aditya, Rial, Alfredo
Formato: Online Artículo Texto
Lenguaje:English
Publicado: 2020
Materias:
Acceso en línea:https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7334996/
http://dx.doi.org/10.1007/978-3-030-51938-4_4
Descripción
Sumario:We define an ideal functionality [Formula: see text] and a construction [Formula: see text] for an updatable database ([Formula: see text]). [Formula: see text] is a two-party protocol between an updater and a reader. The updater sets the database and updates it at any time throughout the protocol execution. The reader computes zero-knowledge (ZK) proofs of knowledge of database entries. These proofs prove that a value is stored at a certain position in the database, without revealing the position or the value. (Non-)updatable databases are implicitly used as building block in priced oblivious transfer, privacy-preserving billing and other privacy-preserving protocols. Typically, in those protocols the updater signs each database entry, and the reader proves knowledge of a signature on a database entry. Updating the database requires a revocation mechanism to revoke signatures on outdated database entries. Our construction [Formula: see text] uses a non-hiding vector commitment (NHVC) scheme. The updater maps the database to a vector and commits to the database. This commitment can be updated efficiently at any time without needing a revocation mechanism. ZK proofs for reading a database entry have communication and amortized computation cost independent of the database size. Therefore, [Formula: see text] is suitable for large databases. We implement [Formula: see text] and our timings show that it is practical. In existing privacy-preserving protocols, a ZK proof of a database entry is intertwined with other tasks, e.g., proving further statements about the value read from the database or the position where it is stored. [Formula: see text] allows us to improve modularity in protocol design by separating those tasks. We show how to use [Formula: see text] as building block of a hybrid protocol along with other functionalities.