-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
1-round DKG without re-attempts #576
Comments
For the eVRF implementation, https://github.com/kayabaNerve/fcmp-plus-plus/ has all of the code necessary. |
The issue with the above protocol is that there's a risk of creating a To recap, we have an elliptic curve The eVRF premised DKG is initialized with The eVRF paper simply says to send the secrets to each party. We assume a verifiable broadcast channel which orders the messages broadcast over it. We broadcast the commitments to the coefficients (with the relevant eVRF proof) and the encrypted secret shares here. The novel part now introduced is proving the encryptions are correct. We detail the existing scheme for reference. This is the same scheme used for the PedPoP DKG, which was audited by Cypher Stack:
This achieves quite strong properties. It allows proving an encryption was malformed. If a received share fails to decrypt/is invalid, it can be broadcast potentially with the ECDH and a proof the ECDH is correctly formed. If the format is invalid, or the PoK, the sender is faulty. If the format and PoK are correct, and the ECDH isn't provided, the accuser is faulty. If the ECDH is provided with a faulty proof, the accuser is faulty. If the decrypted message is incorrect, the sender is faulty. If the decrypted message is correct, the accuser is faulty. It also only decrypts messages the sender had the discrete logarithm of the ephemeral key for. If a sender wanted to burn their reputation, yet in doing so learn about another message, they could create a malformed message using someone else's ephemeral message key. Since the PoK is binding to the sender/receiver, and the sender cannot forge a PoK for someone else's key, this will fail and no ECDH will be included in the blame. It cannot be directly applied to the eVRF model as we cannot announce ephemeral receiving keys in the first round. Instead, we reuse the eVRF keys. Since the eVRF keys are used to derive secrets of the form We propose the following scheme such that the encryption can have a ZK proof it's well-formed, removing the entire blame process:
Anyone can verify the encrypted secret share is correct by checking This is notable as never revealing an ECDH. It solely expects the CDH to be hard over the curve This would ensure the result of the DKG is always a |
We also could've used a class group for verifiable encryption, yet this solely relies on the (C/D?)DH over the embedded elliptic curve. |
This isn't unbiased. By modifying the protocol to only use a subset |
Closing since the branch for this was merged. |
We currently have a 2-round DKG, where we perform re-attempts as necessary.
https://eprint.iacr.org/2024/397 proposes a 1-round DKG. Since we don't vary our threshold upon re-attempt, we can do the 1-round DKG where the first
t
entities to participate decide the key. Then, we get at leastt
confirmations of a lack of malicious behavior and we have a usable key.We actually want the full
n
to confirm the keys validity. Once we have at leastt
confirmations, we set a timer to expire in(n-c)w + w
(wherec
is the amount of confirmations) time since the we receivedt
confirmations. If we receive a new confirmation, we recreate the timer. Only once we haven
confirmations or the timer expires would we move forward.This has the benefit where if we have 100 validators, performing a DoS on 33 of them to attempt to exclude them from the DKG will incur a time delay of
33w
and adds resistance against such classes of attack.Parties that don't participate on-time would be removed on-chain (as currently done).
If a broken key share is identified during the timer, we would reselect the participants to be the first
t
participants excluding the ones malicious.The text was updated successfully, but these errors were encountered: