FROST: Flexible Round-Optimized Schnorr Threshold Signatures
draft-irtf-cfrg-frost-00

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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

11.2.  Informative References

   [frost]    Komlo, C. and I. Goldberg, "FROST: Flexible Round-
              Optimized Schnorr Threshold Signatures", 8 July 2020,
              <https://eprint.iacr.org/2020/852.pdf>.

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