CFRG C. Komlo Internet-Draft University of Waterloo, Zcash Foundation Intended status: Informational I. Goldberg Expires: 12 August 2021 University of Waterloo 8 February 2021 FROST: Flexible Round-Optimized Schnorr Threshold Signatures draft-irtf-cfrg-frost-00 Abstract In this draft, we present FROST, a Flexible Round-Optimized Schnorr Threshold signature scheme that reduces network overhead during signing operations while protecting against forgery attacks applicable to prior similar threshold and multisignature constructions. FROST can be safely used without limiting concurrency of signing operations yet allows for true threshold signing, as only a threshold number of participants are required for signing operations. Here, we define FROST as a two-round protocol, but it can be optimized to a single-round single-round signing protocol as the first round can be performed as a batched pre-processing stage. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the FROST Working Group mailing list (frost@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/frost/. Source for this draft and an issue tracker can be found at https://github.com/chelseakomlo/frost-spec. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 12 August 2021. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction 2. Change Log 3. Terminology 4. Security Considerations 5. Basic Assumptions 5.1. Selection of participants 5.2. Communication channels 5.3. Protocol Failures 6. Notation 7. Cryptographic Dependencies 8. Protocol Overview 9. FROST Key Generation 10. FROST Signing 11. References 11.1. Normative References 11.2. Informative References Acknowledgments Authors' Addresses 1. Introduction DISCLAIMER: This is a work-in-progress draft of FROST. RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH The source for this draft is maintained in GitHub. Suggested changes should be submitted as pull requests at https://github.com/chelseakomlo/frost-spec. Instructions are on that page as well. In this draft, we present FROST, a Flexible Round-Optimized Schnorr Threshold signature scheme. FROST reduces network overhead during signing operations by optimizing for efficiency over robustness. FROST uses a novel technique to allow for fully parallelized use while protecting against forgery attacks that are applicable to prior similar threshold and multisignature constructions. FROST achieves its efficiency improvements in part by allowing the signing protocol to abort in the presence of a misbehaving participant (who can be identified and excluded from future signing operations). 2. Change Log draft-00 * Submitted a basic draft after adoption of draft-komlo-frost as a working group item. 3. Terminology 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 4. Security Considerations In this draft, we specify key generation using a trusted dealer. 5. Basic Assumptions We maintain assumptions about how participants are selected as well as responsibilities of the underlying network channel. Further, we do not specify how implementations should handle failures that occur during the execution of FROST key generation or signing operations. 5.1. Selection of participants We assume that at the time of key generation, participants have a mechanism to select other participants. 5.2. Communication channels We assume that participants communicate over an authenticated and trustworthy channel. Note that during signing, participants can communicate over any channel. We assume that communication failures (dropped messages, etc) are handled externally to the protocol. 5.3. Protocol Failures FROST is not robust; in the case of failures, participants must abort the protocol and try again. However, failures may occur due to participant misbehavior. As such, we do not specify what implementations should do in the case of failure after aborting the protocol. 6. Notation To be completed 7. Cryptographic Dependencies To be completed 8. Protocol Overview To be completed 9. FROST Key Generation To be completed 10. FROST Signing To be completed 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 11.2. Informative References [frost] Komlo, C. and I. Goldberg, "FROST: Flexible Round- Optimized Schnorr Threshold Signatures", 8 July 2020, . Acknowledgments TODO acknowledge. Authors' Addresses Chelsea Komlo University of Waterloo, Zcash Foundation Email: ckomlo@uwaterloo.ca Ian Goldberg University of Waterloo Email: iang@uwaterloo.ca