[cosi] Make each node verify the challenge

[nikkolasg]

This PR brings an additional important check for the cosigners. Each cosigners should perform a verification on the challenge received by the leader, otherwise, there is no guarantee about what they are signing. This PR brings the following changes:

• the statement S to sign is now always included in the announcement. This requirement may be relaxed later but for the moment, this is the only way to make the draft consistent. (we can't send the statement during the challenge phase, otherwise each node that refuses to sign will make the protocol stop).
• each node performs a syntactic and semantic check on the statement S during the commitment phase. If the check output a negative result, then the node quit the protocol.
• the leader sends the challenge AND the aggregate commitment during the challenge phase
• each node performs a check on the received challenge, namely they reconstruct c' = H(R || A || S) and check c' == c.

[bford]

Good, thanks Nicolas.

One consistency issue with the writing: The draft currently uses the letter 'M' to represent a set of participants, which is confusing and inconsistent with common usage where 'M' almost always represents the Message to be signed. Note that RFC 8032 uses M to mean Message, as per this common practice, and we should definitely remain consistent with that since that's clearly the most closely-related document.

It looks like you're using both N and M to represent (slightly-different) participant sets? If you need two participant sets, why not call one N and the other N' for example?

And N isn't a great letter for a participant set either; usually N represents a number (perhaps a number of participants, but a number not a set). Is the letter P used for something else at the moment? Perhaps P and P' would be a better letter to use for participant sets?

[Daeinar]

The letter P seems not to be used at the moment. So we can use P and P' for the set of participants and then switch to M as the message / statement. Moreover, I noticed that we switch back and forth between 'nodes' and 'participants' to denote the co-signers. We should probably be consistent there as well. Any preferences?

[Daeinar]

After briefly talking to @nikkolasg, we use 'participants' for flat CoSi and 'nodes' for the tree-version.

[Daeinar]

To avoid misunderstandings between the messages (announcement, commitment, challenge, response) that are sent during the CoSi protocol and the message M that gets signed, should we go with 'the statement M' instead of 'the message M'?

[bford]

Yes, 'statement M' is a bit awkward but perhaps a reasonable compromise. Maybe say 'statement message M' at least the first time it's used, and then just 'statement M' thereafter?

It might also be good to clarify the terms used for the announce/commit/etc messages as well: e.g., perhaps call them 'CoSi messages' or (or even 'CoSi protocol messages' the first time) instead of just 'messages'?

[nikkolasg]

What about keeping message M but finding another name for the announcement / commitments etc ? I'm not a fan of statement M, I find it removes one ambiguity to introduce another.. (why not go with statement S then ;) We could for example describe these four CoSi protocol messages as "packets" in the beginning and then refer to them later as the Announcement packet etc.

The CoSi protocol makes use of four distinct packets, one for each phase: 
+ the Announcement packet,
+ the Commitment packet, 
+ the Challenge packet
+ the Response packet.

Otherwise looking at other RFCs, people often use the word "records" to describe actual "structured packets" that goes into the network. Even though I agree that feels a bit unnatural, it may be worth considering.

[Daeinar]

I'm fine with message M and CoSi packet or CoSi record.

@nikkolasg: Why do you think records are unnatural? TLS for example also uses this notion: https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_record

[bford]

The alternative term 'packet' had also occurred to me as well, but I didn't suggest it because it sounds a bit weird in this context - but at the same time it would be consistent with many other uses of the term 'packet' (including in the OpenPGP protocol etc), so given that both of thought of it independently maybe that's not a bad idea.

'record' is also fine with me in principle, but I don't know if it's any better than 'packet'.

[nikkolasg]

I picked the word records exactly from the TLS 1.3 RFC but tp me it sounds more like a record is a structured list of constant sized fields. Our RFC uses protobuf to marshal our packet, so to me, a protobuf-marshalled packet (the actual slice of bytes) is a record, but the protobuf definition is not. Packet sounds more general. In the end, it's only nitpicking, I'm ok with both ;)

[bford]

Agreed, I think 'packet' is more generally and marginally better in this context; let's go with that.