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...
Autores principales: | , |
---|---|
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 |
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. |
---|