]> University of Delaware

jimouris@udel.edu

Cloudflare

chrispatton+ietf@gmail.com

Boston University

pratik93@bu.edu

University of Delaware

tsoutsos@udel.edu

IRTF Crypto Forum Internet-Draft This document describes Plabels, a two-party VDAF for the following aggregation task: each Client holds a bit string, and the Collector wishes to count how many of these strings begin with a candidate prefix. Such a VDAF can be used to solve the heavy hitters problem, where the goal is compute the subset of the measurements that occur most frequently. This document also describes various modes of operation for Plabels. First, its output type can be enriched to support aggregation functions beyond prefix counts. Second, an extension to the aggregation phase is described that significantly reduces communication cost compared to existing techniques. Third, a three-party variant is described that is robust in the honest majority setting. About This Document Status information for this document may be found at . Discussion of this document takes place on the Crypto Forum Research Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction

• TODO Introduction. Outline: - Recall the heavy hitters problem - Describe Poplar , IDPF, and how the VDAF abstraction relates to IDPF - Say that Poplar isn't ideal for solving this problem - Introduce

Poplar described a protocol for solving the t-heavy-hitters problem in a privacy-preserving manner. Each client holds a bit-string of length n, and the goal of the aggregation servers is to compute the set of inputs that occur at least t times. The core primitive used in their protocol is a specialized Distributed Point Function (DPF) , called Incremental DPF (IDPF), that allows the servers to "query" their DPF shares on any bit-string of length shorter than or equal to n. As a result of this query, each of the servers has an additive share of a bit indicating whether the string is a prefix of the client's input. The protocol also specifies a multi-party computation for verifying that at most one string among a set of candidates is a prefix of the client's input.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Preliminaries This document makes use of Fully Linear Proofs (FLPs) and eXtendable Output Functions (XOFs) as described in . It also makes use of an extension of Incremental Distributed Point Functions (IDPFs), known as "Verifiable IDPFs (VIDFS)" first described by . VIDPFs are specified below.

Verifiable IDPF (VIDPF) De Castro and Polychroniadou introduced Verifiable DPF (VDPF), a DPF scheme that supports a well-formedness check. More specifically, VDPFs allows verifying that the client’s inputs are well-formed, meaning that the client will not learn any unauthorized information about the servers' database or modify the database in an unauthorized way. PLASMA introduced the notion of Verifiable Incremental DPF (VIDPF) that builds upon IDPF and VDPF . VIDPF is an IDPF that allows verifying that clients’ inputs are valid by relying on hashing while preserving the client’s input privacy.

• TODO(Dimitris)

Interactive Aggregation for VDAFs In order to accommadating Plabel's improvemnt in communication cost require, it is necessary to replace the non-interactive aggregation algorithm Vdaf.aggregate() with a 1-round, interactive protocol implemented by the following methods:

• Vdaf.aggregate_init(agg_info: AggInfo, out_shares: list[OutShare]) -> tuple[AggState, AggMessage] is the deterministic aggregation initialization algorithm called by each Aggregator. It takes as input the set output shares to be aggregated and a parameter called the "aggregation information". Its outputs are the Aggregator's state and broadcast message.
• Vdaf.aggregate_finish(agg_state: AggState, agg_msgs: list[AggMessage]) -> AggShare. is the deterministic aggregation finalization aglorithm called by each Aggregator on its aggregation state and the sequence of messages broadcast by each Aggregator.

• CP: The binary search described in obviously doesn't fit into a 1-round protocol, as the number of rounds required depends on how deep down the Merkle we have to before we've identified all bad reports. The idea is that aggregation protocol would be invoked multiple times, each time with a different agg_info.

• CP: Let's try to come up with a better name than agg_info.

The Plabels VDAF

• TODO(Hannah) Describe the implementation of the base Vdaf interface.

Reducing Communication Cost via Interactive Aggregation

• TODO(Dimitris) Describe the implementation of the interface in

Improved Robustness via

• TODO Describe 3-party PLASMA

Security Considerations

• TODO Security

IANA Considerations This document has no IANA actions.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References n.d. Cisco ISRG Cloudflare Google This document describes Verifiable Distributed Aggregation Functions (VDAFs), a family of multi-party protocols for computing aggregate statistics over user measurements. These protocols are designed to ensure that, as long as at least one aggregation server executes the protocol honestly, individual measurements are never seen by any server in the clear. At the same time, VDAFs allow the servers to detect if a malicious or misconfigured client submitted an measurement that would result in an invalid aggregate result.

Acknowledgments

• TODO(Dimitris)