Subject: [CFRG] draft-irtf-cfrg-frost-02 - On the wire formats and other nits

From: Michael StJohns <[email-masked]>
Date: Sun, 10 Apr 2022 21:02:59 -0400

Hi -

I've been following the above document and am pleased that it's 
progressing.  I've got a few different possibilities for where I might 
use it.

That said, the CFRG is a research group and not an IETF WG - so the 
specification of on-the-wire formats here, especially when they exclude 
(by the use of MUST) other on-the-wire formats, is problematic.

E.g. Section 5.3 has

> The output signature (R, z) from the aggregation step MUST be encoded 
> as follows:
>    struct {
>      opaque R_encoded[Ne];
>      opaque z_encoded[Ns];
>    } Signature;

Given that CMS for example uses a different encoding for EC signatures - 
ASN1 SEQUENCE { INTEGER r, INTEGER s }, or hardware devices tend to 
provide or require the signature as an even length array of n where R 
and S are concatenated n/2 subarrays - specifying the signature encoding 
as this and only this would lead to this document causing problems when 
an IETF side WGs want to adopt the math for use in a CMS scheme.  Or 
even in a DNS RRSig scheme.  Unclear why this requirement is here.

In addition, why use "z" here instead of "S" which is the more common 
terminology?

Section C is less problematic in that it's only "recommended", but still 
- these are all things that should probably be left to a WG actually 
building a protocol around the math.

If the authors choose to include this section, please include the entire 
grammar here, so whoever is using this doesn't have to page back and 
forth to figure out what a "commitment hiding factor" is?  I *think* it 
might be hiding_nonce_commitment from 5.1 but that's far from clear.  
And provide actual encoding examples.

Other Notes:

Section 2 - where the document does various "struct" constructs later 
on,  it appears it's using some form of TLS encoding as a guess.  
However, that's not stated here and probably should be.

Section 3.1 and elsewhere - the language here is confusing related to 
other elliptic curve specifications.   AFAICT - Group == Curve + 
Generator or simply Curve; Element == Point.   Is there a reason for 
this disconnect?

Section 4.1 -

>   def schnorr_signature_generate(msg, SK):
>      PK = G.ScalarBaseMult(SK)
>      k = G.RandomScalar()
>      R = G.ScalarBaseMult(k)

I believe that it should be k = G.RandomNonzeroScalar().  NIST at least 
(FIPS186-4, B.5.1) requires k to be  1 <= k <= n-1.

Hmm... is there any place where G.RandomScalar() should be used? Mostly 
its followed by G.ScalarBaseMult() of the generated scalar.  If the 
scalar is 0 then the result of the multiplication is?

Section 5:  Figure 1 does not appear to match up with the text of 
5.2.    I.e., the only message from the coordinator is "message" at the 
beginning, rather than deferring that to after Round 1 and including it 
with the set of commitments (which aren't listed in the diagram).

Section 5.1 - since the commitments can be calculated from the nonces, 
and since the nonces aren't secret, why send both the nonce and its 
commitment?  E.g. move the calculation of the various commitment values 
to section 5.2, round 2.  One less thing to screw up.

Section 5.2 -  The Input comments have: "group_public_key, public key 
corresponding to the signer secret key share." I thought the 
group_public_key was the public point of Gs?  Not Gsk_i?  So this should 
be "group_public_key -  public key corresponding to the group secret key 
(i.e. G.ScalarMultBase(s) where s is the group secret key)."

Section 5.2 - "... MUST validate the input signature..." -is probably 
"MUST validate the input signature SHARE...".

Section 5.2 - Is the implication of "If validation fails, the 
Coordinator MUST abort..."  that the coordinator must pre-select a set 
of signers for participation, rather than sending out the data to be 
signed by all and then being able to select THRESHOLD signature shares 
from the group?  Otherwise, if I have THRESHOLD + 1 signature shares and 
1 signature share is bad, then I should be able to still validate the 
signature with the remaining THRESHOLD signature shares. Or am I missing 
something?  If I can cause a failure of the signing process simply by 
sending the coordinator a random number (or a signature share against a 
random number...) that looks like a signature share, it seems like a 
pretty obvious DOS attack.

6.4 - Since pretty much every implemented protocol uses the uncompressed 
point representation for P256, requiring the serialized form to be the 
compressed point representation seems a bit strange.

Later, Mike