Re: [CFRG] RGLC on draft-irtf-cfrg-frost-11

[Armando Faz <[e-mail]>]

Hi CFRG and FROST authors,

I have reviewed draft-irtf-cfrg-frost-11  Commit: 113bd5a74,
I have implemented FROST ciphersuites P-256 and ristretto255 in Go
CIRCL library (https://github.com/cloudflare/circl/pull/349), test
vectors match. But I haven't verified those for EdDSA.

Here are some comments:

#1
- we introduce separate domain-separated hashes
+ we introduce domain-separated hashes

#2
- to Scalar elements of the prime-order group scalar field
+ to Scalar elements of the prime-order group.

#3
- These sections describes these operations in more detail.
+ These sections describe these operations in more detail.

Like this one, there are a few other errors that can be easily catched
by a spellchecker.

#4
- A polynomial of maximum degree t+1 is represented as a list of t coefficients
+ A polynomial of maximum degree t is represented as a list of t+1 coefficients

#5
derive_lagrange_coefficient
I think it is more accurate to name this function as
"lagrange_basis_at_0"  since the Lagrange basis is defined as  l_i(x)
= \prod i\neq j (x-x_j)/(x_i-x_j), which must be evaluated at 0.

#6
In Section 5. (without reading the Appendix) it is not clear what is
the (mathematical) relation, if any, between the key shares (sk_i),
and the signing key (sk).

#7
Is this statement true with respect to EdDSA as in RFC8032?

"FROST produces signatures that are indistinguishable from those
produced with a single participant using a signing key s with
corresponding public key PK, where s is a Scalar value and PK =
G.ScalarBaseMult(s)."

Let
  s0 = sign(m,s,pk) using RFC8032;
  s1 = threshold_sign(m,s,pk) using FROST.

any s1 can be distinguished as a FROST signature as is expected to be
different from s0 because FROST signing is not deterministic.

#8
- The nonce values produced by this function MUST NOT be reused in
more than one invocation of FROST, and it MUST be generated from a
source of secure randomness.
+ The nonce values produced by this function MUST NOT be reused in
more than one invocation of FROST, and they MUST be generated from a
source of secure randomness.

#9
- Moreover, each participant MUST ensure that their identifier appears
in commitment_list along with their commitment from the first round.
+ Moreover, each participant MUST ensure that its identifier and the
commitments  (from the first round) appear in the commitment_list.

- signing set than the the aggregated response
+ signing set than the aggregated response

#10
The alternative check [S]B = R + [k]A' is not safe or interoperable in practice.

I understand why it is not interoperable, but why is it not safe? A
comment about these two restrictions is appreciated.

Also, unify name of variables in the verification equation: [S]B = R + [k]A'

#11
For FROST(Ed448, SHAKE256) ciphersuite:

SerializeScalar(s): Implemented by outputting the little-endian
48-byte encoding of the Scalar value.
DeserializeScalar(buf): Implemented by attempting to deserialize a
Scalar from a little-endian 48-byte string.

Scalars are 57-byte strings.

#12
For FROST(Ed448, SHAKE256) ciphersuite:
Ed448 allows specifying a context string, and the FROST ciphersuite
vanishes the context string. why?
Note it is still possible to include the Ed448 context string in H2,
so it makes this ciphersuite fully compatible with RFC8032.

#13
"This includes checking that the coordinates of the resulting point
are in the correct range, that the point is on the curve, and that the
point is not the point at infinity. Additionally, this function
validates that the resulting element is not the group identity
element."

It looks like the second sentence is redundant.

#14
For secp256r1:
partial public-key validation as defined in section 5.6.2.3.4 of [KEYAGREEMENT].

For secp256k1:
partial public-key validation as defined in section 3.2.2.1 of [SEC1].

Are these validation methods different? If not, why make a distinction?

#15
- H(contextString \|\| "pre-hash" \|\| m)
+ H(contextString || "pre-hash" || m)

#16
- create secret shares of s, denoted s_i for i = 0, ...,
MAX_PARTICIPANTS, to be sent to all MAX_PARTICIPANTS participants.
+ create secret shares of s, denoted s_i for i = 1, ...,
MAX_PARTICIPANTS, to be sent to all MAX_PARTICIPANTS participants.

#17
...participants MUST abort if they do not have the same view of vss_commitment.

In practice, how this checking is performed (without adding a
communication round)?

#18
- that any cooperating subset of MIN_PARTICIPANTS participants
+ that any cooperating subset of at least MIN_PARTICIPANTS participants

#19
"invalid parameters", if MIN_PARTICIPANTS > MAX_PARTICIPANTS or if
MIN_PARTICIPANTS is less than 2

This prevents splitting the secret between two entities, is this correct?

Also note that in the Test Vector Section
MIN_PARTICIPANTS = 2

#20
Section 4.2.1 is only useful for App C. So it can be moved there.

#21
"points, a set of t distinct points on a polynomial f"

Note that (1,2) != (1,3), these points are different, but they are an
invalid input to polynomial_interpolation function

#22
Adding references to Feldman and Shamir secret sharing.

#23
Outputs: 1 if sk_i is valid, and 0 otherwise
Better to return true/false?

#24
In verify_signature_share, at which point the Coordinator learns the
PK_i from participants?

#25
In the VSS section:
"We now define how the Coordinator and participants can derive group
info, which is an input into the FROST signing protocol."

If the group info is the input of the FROST protocol, then VSS is a dependency?

#26
Appendix D is equal to Section 4.3 of VOPRF. Should this section be
replaced by reference or by a verbatim copy of Sec 4.3?

https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-voprf#section-4.3

#27

Exponents do not render ok. (*we should fix this also in VOPRF draft)

p - 2<sup>b</sup>| < 2<sup>(b/2)</sup>,

The ASCII version looks ok:  | p - 2^b | < 2^(b/2)

-- 
Armando Faz
Cloudflare Inc.