Replies: 2 comments 1 reply
-
From RFC 9591:
FROST assumes reliable message delivery between the Coordinator and
participants in order for the protocol to complete. An attacker
masquerading as another participant will result only in an invalid
signature; see Section 7
<https://www.rfc-editor.org/rfc/rfc9591.html#sec-considerations>. However,
in order to identify misbehaving participants, we assume that the network
channel is additionally authenticated; confidentiality is not required.
Similar wording is found in
https://www.rfc-editor.org/rfc/rfc9591.html#section-5.4 and
https://www.rfc-editor.org/rfc/rfc9591.html#section-7
…On Wed, Dec 18, 2024, 10:52 AM Matthew Mitchell ***@***.***> wrote:
I see in the docs (
https://frost.zfnd.org/tutorial/signing.html#participants-round-1) that
it states:
SigningCommitments must be sent to the Coordinator using an authenticated
channel <https://frost.zfnd.org/terminology.html#peer-to-peer-channel>.
However I see no mention in the FROST paper about this or the draft
protocol (
https://www.ietf.org/archive/id/draft-irtf-cfrg-frost-14.html#section-5.2).
There is no mention of participants verifying that the commitments belong
to the other participants in the commitment set. The commitments are sent
by the coordinator and could be anything.
I assumed that if the coordinator could send arbitrary commitments to
participants, that the coordinator could not use this to forge signatures.
I assumed that it would only result in failure for the signature to be
generated.
Is this wrong? Is there a security concern that isn't mentioned in the
FROST paper or draft standard?
—
Reply to this email directly, view it on GitHub
<#814>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEHAAKH6HF2LZMPRWBMFJ32GGK2JAVCNFSM6AAAAABT3ALAKSVHI2DSMVQWIX3LMV43ASLTON2WKOZSG42DQMJYGA2DCOI>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
0 replies
-
@dconnolly Thank you for that. This is as expected. The tutorial docs are not clear on this as "authenticated channel" links to "Peer to peer channel" instead of mentioning mere authentication between the peer and coordinator for the purpose of avoiding invalid signatures and identifying misbehaving participants. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I see in the docs (https://frost.zfnd.org/tutorial/signing.html#participants-round-1) that it states:
However I see no mention in the FROST paper about this or the draft protocol (https://www.ietf.org/archive/id/draft-irtf-cfrg-frost-14.html#section-5.2). There is no mention of participants verifying that the commitments belong to the other participants in the commitment set. The commitments are sent by the coordinator and could be anything.
I assumed that if the coordinator could send arbitrary commitments to participants, that the coordinator could not use this to forge signatures. I assumed that it would only result in failure for the signature to be generated.
Is this wrong? Is there a security concern that isn't mentioned in the FROST paper or draft standard?
Beta Was this translation helpful? Give feedback.
All reactions