paint-brush
Verifiable Privacy-Preserving Computing: Preliminariesby@encapsulation

Verifiable Privacy-Preserving Computing: Preliminaries

tldt arrow

Too Long; Didn't Read

This section offers a comprehensive background on decentralized ledger technologies (DLTs) and decentralized computations. Explore the diverse applications of blockchain, from cryptocurrencies to decentralized apps (dApps) in various domains. Understand the role of DLTs in privacy-preserving schemes and their significance in group computations. Additionally, gain insights into the common threat models that define security in cryptographic solutions for decentralized realms, setting the stage for a deeper exploration of privacy and verifiability in subsequent sections.
featured image - Verifiable Privacy-Preserving Computing: Preliminaries
Bundling data and functions into a single unit HackerNoon profile picture

This paper is available on arxiv under CC 4.0 license.

Authors:

(1) Tariq Bontekoe, University of Groningen;

(2) Dimka Karastoyanova, University of Groningen;

(3) Fatih Turkmen, University of Groningen.

Abstract & Introduction

Preliminaries

Zero-knowledge proofs and verifiable computing

Privacy-preserving computations

Requirements: an application’s perspective

Verifiable, privacy-preserving computing

Open challenges and future directions

Conclusion & References

2. Preliminaries

This section provides background on DLTs and methods for decentralized computation. Next to this, we provide an overview of the most common threat models used to describe cryptographic solutions for verifiable or privacypreserving computations.

2.1. DLTs and decentralized computations

DLTs describe the collection of technologies where a (large) number of parties collectively create, maintain, and agree on a shared state or ledger. The shared state can be known completely to all parties, but can also be spread out over the respective parties. A well-known example of a DLT is blockchain, where all parties agree — via some predetermined consensus mechanism — on a public ledger containing the full state of a system. Blockchain is best known for realizing decentralized currencies such as Bitcoin [10], or smart contract systems like Ethereum [11]. However, DLTs, and specifically blockchains, also have applications in many other domains: from identity management [12] (e.g., self-sovereign identity (SSI)) to healthcare [13]. We specifically observe the proliferation of decentralized apps (or dApps), each of which can be seen as a blockchainbased autonomous application, whose behavior is defined by a collection of scripts (or smart contracts).


In lockstep with an increasing number of dApps, we also observe an increase in using DLT for decentralized computations. Such decentralized computations can be applied in a DLT setting, but more importantly to any situation where multiple parties wish to perform a group computation. In this case, group computation can refer to: (1) a single computation on distributed data; (2) a decentralized computation on centrally stored data; (3) a combination of the first two.


Decentralized computation becomes especially of interest when privacy of data or computation has to be taken into consideration. Examples of decentralized computation use cases that take privacy into account can be found in literature on outsourced computations, MPC, federated learning (FL), and DLTs. In subsequent sections, we will see that both DLTs and MPC are often used as base building blocks for realizing decentralized, verifiable, privacypreserving computation schemes. To analyze the privacy and security guarantees provided by those schemes, we also require an understanding of relevant threat models.

2.2. Threat models

We informally describe the three most common security models regarding the possible behavior of the parties that have been corrupted by the adversary. For a more detailed treatment of the topic, we refer the reader to e.g., [14]:


• Semi-honest adversaries: In this scenario, also known as the honest-but-curious or passive model, corrupted parties do not deviate from the selected protocol. The adversary does have access to all data received and owned by the corrupted parties, and tries to deduce as much as possible from this.


• Malicious adversaries: In the malicious or active setting, the adversary can make corrupted parties deviate from the protocol in any way. A protocol is secure if it can prevent any malicious adversary from breaking security or privacy. When a protocol not only prevents cheating but also allows for determining who cheated, the protocol is said to support cheater detection, e.g., [15].


• Covert adversaries: Corrupted parties show the same behavior as in the malicious model. However, honest parties need only detect cheating parties with a given probability. In practice, it is assumed that the risk of getting caught and receiving a financial or reputation penalty is sufficient to deter an adversary. The notion of covert security with public verifiability was introduced in [16]. With public verifiability, not only can honest parties detect cheating with some probability, they can also construct a publicly verifiable certificate proving that a certain party has cheated, without revealing information on the private data of any honest party.