ZIP 312: change randomizer handling

[conradoplg]

Changes to randomizer handling after I realized that it couldn't possibly be generated using the message as an input. It does simplify things too.

Some additional fixes (using "Re-Randomized FROST" consistently; updating Owners)

[str4d]

Does the math not work out if each participant generates a share of alpha and commits to it in round 1, then uses their share in round 2? If it didn't then I guess the way to remove the trust assumption on the Coordinator here would be to still do that commitment in round 1, and then have a round 1.5 that is just participants revealing their alpha shares, but that would turn this into a three-round protocol, or two-round with preprocessing (where participants precompute and save their shares of both R and alpha), which isn't ideal for some usage scenarios where the Coordinator is trusted. Maybe that should be left as an option?

[daira]

One way to reduce the requirements on the Coordinator's RNG is to have it generate the randomizer by hashing the commitments and an extra random seed. The participants then recalculate it using that hash. The Coordinator can grind on the seed in order to create a subliminal channel, but this means you're not trusting the Coordinator's RNG. (Also, no participant can grind on their contribution in order to influence the randomizer, because the Coordinator only reveals the seed after it has the commitments.)

[conradoplg]

I tried @daira 's approach in 62833e6

[str4d]

I think the mechanism for using FROST for transaction spend auth should not be outside the scope of this ZIP, given that this ZIP is "FROST for Spend Authorization Multisignatures" (rather than the smaller-scoped "Re-randomized FROST"). However, I agree that most of the content that mechanism would entail is what would go into creating and checking PCZTs, so what we should do here is incorporate by reference the ZIP that eventually contains that specification (#693), and then either use it as appropriate directly in this section, or divide the specification into "Re-randomized FROST" (for more general consumption) and "Using Re-randomized FROST for Zcash transactions" (which then augments it further with the Zcash-specific logic like PCZT usage).

[conradoplg]

I agree, let's leave this pending until we get more concrete on PCZTs

[daira]

It's an overspecification to imply that the randomizer needs to be generated uniformly at random. As suggested above, it could be chosen depending on the commitments sent in round 1.

Also, the spec actually says to generate the randomizer $\alpha$ like this:

Define $\mathsf{RedDSA.GenRandom} ⦂ () \rightarrow \mathsf{RedDSA.Random}$ as:

• Choose a byte sequence $T$ uniformly at random on $\mathbb{B}^{\mathbb{Y}[(\ell_{\mathsf{H}} + 128) / 8]}$.
• Return $\mathsf{H}^⊛(T)$.

Note that the output range of $\mathsf{H}^⊛$ is exactly the intended range of $\alpha$, i.e. $[0, r_{\mathbb{G}})$.

To refine my suggestion, $T$ would be the "seed" and then the randomizer would be computed by all participants as $\mathsf{H}^⊛(T \hspace{0.2em}\mathsf{||}\hspace{0.2em} \mathsf{commitments}).$ The encoding of the list of commitments as a byte sequence would need to be specified. This works without needing another round because nothing in round 1 depends on the message. Each participant can fill in the computed $\alpha$ having already seen a PCZT that has the necessary information excluding $\alpha$.

[conradoplg]

Great idea. I went ahead with it in 62833e6

[daira]

ACK with suggestions.

[str4d]

This is somewhat confusing, given that random_bytes gets its own paragraph. Separate encode_signing_commitments into its own paragraph, and then maybe turn those two paragraphs into bullet points? or something that clarifies these are references to functions defined elsewhere that are used by the two new helper functions, not the two new helper functions being defined. Maybe also import the references first, and then say "Two new helper functions are defined" immediately before the actual definitions.

[conradoplg]

Agreed, I restructured this in c74bed5

[str4d]

Move this above Re-Randomized FROST and make it a same-level section. So this ZIP's Specification section then has:

• Key Generation
• Randomizer Generation
• Re-Randomized FROST
  • Round One - Commitment
  • Round Two - Signature Share Generation
  • Signature Share Verification and Aggregation
• Ciphersuites
  • FROST(Jubjub, BLAKE2b-512)
  • FROST(Pallas, BLAKE2b-512)

which then means that the "Re-Randomized FROST" sub-section is just focused on modifications to FROST, and everything else is stuff canonically specified in ZIP 312 (although maybe parts of "Key Generation" move elsewhere to e.g. ZIP 32, but we'll figure that out in #883).

[conradoplg]

Good point, done in c74bed5

[str4d]

There is a risk here that a Coordinator and Participant (or multiple Participants) might have different implementations, and attempt to use them in the same signing session. That would be incompatible and cause a failure, which violates the defintion of MAY in RFC 2119:

5. MAY This word, or the adjective "OPTIONAL", mean that an item is
   truly optional. One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)

So we will need to specify the full encoding here.

[conradoplg]

Done in c74bed5 by using the serialization function from the RFC

[conradoplg]

Addressed comments in did some additional improvements/cleanups

[conradoplg]

Done in c74bed5 by using the serialization function from the RFC

[conradoplg]

Good point, done in c74bed5

[conradoplg]

Agreed, I restructured this in c74bed5