Skip to content

Commit

Permalink
edits
Browse files Browse the repository at this point in the history
  • Loading branch information
Chelsea Komlo committed Sep 12, 2023
1 parent 2211c58 commit 5d0ed9f
Showing 1 changed file with 6 additions and 3 deletions.
9 changes: 6 additions & 3 deletions draft-irtf-cfrg-frost.md
Original file line number Diff line number Diff line change
Expand Up @@ -137,8 +137,11 @@ key generation with a trusted dealer is specified in {{dep-dealer}}.
This document represents the consensus of the Crypto Forum Research
Group (CFRG). It is not an IETF product and is not a standard.

RFC EDITOR: PLEASE REMOVE THE FOLLOWING SUB-SECTION

## Change Log


draft-13 and draft-14

- Hash group public key into binding computation (#439)
Expand Down Expand Up @@ -615,7 +618,7 @@ to hold and use a signing key share. The Coordinator is an entity with the follo

FROST assumes that the Coordinator and the set of signer participants are chosen
externally to the protocol. Note that it is possible to deploy the protocol without
a distinguished Coordinator; see {{no-coordinator}} for more information.
designating a single Coordinator; see {{no-coordinator}} for more information.

FROST produces signatures that can be verified as if they were produced from a single signer
using a signing key `s` with corresponding public key `PK`, where `s` is a Scalar
Expand Down Expand Up @@ -736,7 +739,7 @@ def commit(sk_i):
return (nonces, comms)
~~~

The outputs `nonce` and `comm` from participant `P_i` SHOULD both be stored locally and
The outputs `nonce` and `comm` from participant `P_i` are both stored locally and
kept for use in the second round. The `nonce` value is secret and MUST NOT be shared, whereas
the public output `comm` is sent to the Coordinator. The nonce values produced by this
function MUST NOT be used in more than one invocation of `sign`, and the nonces MUST be generated
Expand Down Expand Up @@ -880,7 +883,7 @@ about dealing with invalid signatures and misbehaving participants.
The function for verifying a signature share, denoted `verify_signature_share`, is described below.
Recall that the Coordinator is configured with "group info" which contains
the group public key `PK` and public keys `PK_i` for each participant, so the `group_public_key` and
`PK_i` function arguments should come from that previously stored group info.
`PK_i` function arguments MUST come from that previously stored group info.

~~~
Inputs:
Expand Down

0 comments on commit 5d0ed9f

Please sign in to comment.