16 research outputs found

    An Overview of Cryptographic Accumulators

    Get PDF
    This paper is a primer on cryptographic accumulators and how to apply them practically. A cryptographic accumulator is a space- and time-efficient data structure used for set-membership tests. Since it is possible to represent any computational problem where the answer is yes or no as a set-membership problem, cryptographic accumulators are invaluable data structures in computer science and engineering. But, to the best of our knowledge, there is neither a concise survey comparing and contrasting various types of accumulators nor a guide for how to apply the most appropriate one for a given application. Therefore, we address that gap by describing cryptographic accumulators while presenting their fundamental and so-called optional properties. We discuss the effects of each property on the given accumulator's performance in terms of space and time complexity, as well as communication overhead.Comment: Note: This is an extended version of a paper published In Proceedings of the 7th International Conference on Information Systems Security and Privacy (ICISSP 2021), pages 661-66

    Trading Accumulation Size for Witness Size: A Merkle Tree Based Universal Accumulator Via Subset Differences

    Get PDF
    Merkle-type trees are widely used to design cryptographic accumulators. The primary advantage in using Merkle tree for accumulators is that they only assume existence of collision-resistant hash functions. Merkle tree based accumulators produces constant size accumulation values. But, the size of the witness is always logarithmic in the number of values accumulated, opposed to the constant size witness as exhibited by some of the other popular accumulators that uses number theoretic techniques and problems. Surprisingly, there exists no Merkle tree based accumulator that provides a trade-off between accumulation size and witness size. Such a trade-off is warranted, as argued in this paper, in a situation where witnesses are stored in memory constrained devices and are being moved around continuously, as opposed to the accumulation values that remain stationary, often in devices with moderate storage capacity. In this paper we propose a Merkle-tree based accumulator scheme assuming only collision-resistant hash functions exist. Our scheme allows witness of size that is in general strictly less than logarithmic in the number of values accumulated, and in some cases reduces to constant size. The trade-off cost results in an increased accumulation size

    UC Updatable Databases and Applications

    Get PDF
    We define an ideal functionality \Functionality_{\UD} and a construction \mathrm{\Pi_{\UD}} for an updatable database (\UD). \UD 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 \mathrm{\Pi_{\UD}} 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, \mathrm{\Pi_{\UD}} is suitable for large databases. We implement \mathrm{\Pi_{\UD}} 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. \Functionality_{\UD} allows us to improve modularity in protocol design by separating those tasks. We show how to use \Functionality_{\UD} as building block of a hybrid protocol along with other functionalities

    UC Updatable Non-Hiding Committed Database with Efficient Zero-Knowledge Proofs

    Get PDF
    We define an ideal functionality \Functionality_{\DB} and a protocol \mathrm{\Pi_{\DB}} for an updatable non-hiding committed database (\DB). \DB is described as the task of storing a database into a suitable data structure that allows you to efficiently prove in zero-knowledge (ZK) that a value is stored in the database at a certain position. The database is \emph{non-hiding} because both prover and verifier know its content. It is \emph{committed} in the sense that only ZK proofs about position-value pairs that are actually stored are possible. It is \emph{updatable} because its contents can be modified dynamically throughout the protocol execution. The \DB task is used implicitly as building block of privacy-preserving protocols for e-commerce, smart billing and access control. In those protocols, this task is intertwined with others. Our functionality \Functionality_{\DB} allows us to study constructions for this task in isolation. Furthermore, it allows us to improve modularity in protocol design, by using \Functionality_{\DB} as building block of those protocols along with functionalities for other tasks. Our construction \mathrm{\Pi_{\DB}} uses a non-hiding vector commitment (VC) scheme as building block. Thanks to the efficiency properties of non-hiding VC schemes, \mathrm{\Pi_{\DB}} provides ZK proofs whose computation cost (after initialization) and whose size are both independent of the database size. Therefore, \mathrm{\Pi_{\DB}} is suitable for large databases. Moreover, the database can be updated dynamically and very efficiently

    Anonymous Device Authorization for Cellular Networks

    Get PDF
    Cellular networks connect nearly every human on the planet; they consequently have visibility into location data and voice, SMS, and data contacts and communications. Such near-universal visibility represents a significant threat to the privacy of mobile subscribers. In 5G networks, end-user mobile device manufacturers assign a Permanent Equipment Identifier (PEI) to every new device. Mobile operators legitimately use the PEI to blocklist stolen devices from the network to discourage device theft, but the static PEI also provides a mechanism to uniquely identify and track subscribers. Advertisers and data brokers have also historically abused the PEI for data fusion of location and analytics data, including private data sold by cellular providers. In this paper, we present a protocol that allows mobile devices to prove that they are not in the blocklist without revealing their PEI to any entity on the network. Thus, we maintain the primary purpose of the PEI while preventing potential privacy violations. We describe provably secure anonymous proof of blocklist non-membership for cellular network, based on the RSA accumulators and zero-knowledge proofs introduced by Camenisch and Lysyanskaya (Crypto\u2702) and expanded upon by Li, Li and Xue (ACNS\u2707). We show experimentally that this approach is viable for cellular networks: a phone can create a blocklist non-membership proof in only 3432 milliseconds of online computation, and the network can verify the proof in less than one second on average. In total this adds fewer than 4.5 seconds to the rare network attach process. This work shows that PEIs can be attested anonymously in 5G and future network generations, and it paves the way for additional advances toward a cellular network with guaranteed privacy

    Batching, Aggregation, and Zero-Knowledge Proofs in Bilinear Accumulators

    Get PDF
    An accumulator is a cryptographic primitive that allows a prover to succinctly commit to a set of values while being able to provide proofs of (non-)membership. A batch proof is an accumulator proof that can be used to prove (non-)membership of multiple values simultaneously. In this work, we present a zero-knowledge batch proof with constant proof size and constant verification in the Bilinear Pairings (BP) setting. Our scheme is 16x to 42x faster than state-of-the-art SNARK-based zero-knowledge batch proofs in the RSA setting. Additionally, we propose protocols that allow a prover to aggregate multiple individual non-membership proofs, in the BP setting, into a single batch proof of constant size. Our construction for aggregation satisfies a strong soundness definition - one where the accumulator value can be chosen arbitrarily. We evaluate our techniques and systematically compare them with RSA-based alternatives. Our evaluation results showcase several scenarios for which BP accumulators are clearly preferable and can serve as a guideline when choosing between the two types of accumulators

    Universally Composable Accumulators

    Get PDF
    Accumulators, first introduced by Benaloh and de Mare (Eurocrypt 1993), are compact representations of arbitrarily large sets and can be used to prove claims of membership or non-membership about the underlying set. They are almost exclusively used as building blocks in real-world complex systems, including anonymous credentials, group signatures and, more recently, anonymous cryptocurrencies. Having rigorous security analysis for such systems is crucial for their adoption and safe use in the real world, but it can turn out to be extremely challenging given their complexity. In this work, we provide the first universally composable (UC) treatment of cryptographic accumulators. There are many different types of accumulators: some support additions, some support deletions and some support both; and, orthogonally, some support proofs of membership, some support proofs of non-membership, and some support both. Additionally, some accumulators support public verifiability of set operations, and some do not. Our UC definition covers all of these types of accumulators concisely in a single functionality, and captures the two basic security properties of accumulators: correctness and soundness. We then prove the equivalence of our UC definition to standard accumulator definitions. This implies that existing popular accumulator schemes, such as the RSA accumulator, already meet our UC definition, and that the security proofs of existing systems that leverage such accumulators can be significantly simplified. Finally, we use our UC definition to get simple proofs of security. We build an accumulator in a modular way out of two weaker accumulators (in the style of Baldimtsi et. al (Euro S&P 2017), and we give a simple proof of its UC security. We also show how to simplify the proofs of security of complex systems such as anonymous credentials. Specifically, we show how to extend an anonymous credential system to support revocation by utilizing our results on UC accumulators

    Oblivious Accumulators

    Get PDF
    A cryptographic accumulator is a succinct set commitment scheme with efficient (non-)membership proofs that typically supports updates (additions and deletions) on the accumulated set. When elements are added to or deleted from the set, an update message is issued. The collection of all the update messages essentially leaks the underlying accumulated set which in certain applications is not desirable. In this work, we define oblivious accumulators, a set commitment with concise membership proofs that hides the elements and the set size from every entity: an outsider, a verifier or other element holders. We formalize this notion of privacy via two properties: element hiding and add-delete indistinguishability. We also define almost-oblivious accumulators, that only achieve a weaker notion of privacy called add-delete unlinkability. Such accumulators hide the elements but not the set size. We consider the trapdoorless, decentralized setting where different users can add and delete elements from the accumulator and compute membership proofs. We then give a generic construction of an oblivious accumulator based on key-value commitments (KVC). We also show a generic way to construct KVCs from an accumulator and a vector commitment scheme. Finally, we give lower bounds on the communication (size of update messages) required for oblivious accumulators and almost-oblivious accumulators

    Notus: Dynamic Proofs of Liabilities from Zero-knowledge RSA Accumulators

    Get PDF
    Proofs of Liabilities (PoL) allow an untrusted prover to commit to its liabilities towards a set of users and then prove independent users\u27 amounts or the total sum of liabilities, upon queries by users or third-party auditors. This application setting is highly dynamic. User liabilities may increase/decrease arbitrarily and the prover needs to update proofs in epoch increments (e.g., once a day for a crypto-asset exchange platform). However, prior works mostly focus on the static case and trivial extensions to the dynamic setting open the system to windows of opportunity for the prover to under-report its liabilities and rectify its books in time for the next check, unless all users check their liabilities at all epochs. In this work, we develop Notus, the first dynamic PoL system for general liability updates that avoids this issue. Moreover, it achieves O(1)O(1) query proof size, verification time, and auditor overhead-per-epoch. The core building blocks underlying Notus are a novel zero-knowledge (and SNARK-friendly) RSA accumulator and a corresponding zero-knowledge MultiSwap protocol, which may be of independent interest. We then propose optimizations to reduce the prover\u27s update overhead and make Notus scale to large numbers of users (10610^6 in our experiments). Our results are very encouraging, e.g., it takes less than 22ms to verify a user\u27s liability and the proof size is 256256 Bytes. On the prover side, deploying Notus on a cloud-based testbed with eight 32-core machines and exploiting parallelism, it takes 3{\sim}3 minutes to perform the complete epoch update, after which all proofs have already been computed
    corecore