absolutebi/serai
1
0
Fork 0
mirror of https://github.com/serai-dex/serai.git synced 2025-12-12 14:09:25 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update spec to the new DKG

Browse Source
This commit is contained in:
Luke Parker
2024-08-05 06:58:44 -04:00
parent e74c8f38d5
commit 2ae2883106
3 changed files with 17 additions and 75 deletions
Download Patch File Download Diff File Expand all files Collapse all files

23
spec/DKG Exclusions.md
View File

@@ -1,23 +0,0 @@
Upon an issue with the DKG, the honest validators must remove the malicious
validators. Ideally, a threshold signature would be used, yet that would require
a threshold key (which would require authentication by a MuSig signature). A
MuSig signature which specifies the signing set (or rather, the excluded
signers) achieves the most efficiency.
While that resolves the on-chain behavior, the Tributary also has to perform
exclusion. This has the following forms:
1) Rejecting further transactions (required)
2) Rejecting further participation in Tendermint
With regards to rejecting further participation in Tendermint, it's *ideal* to
remove the validator from the list of validators. Each validator removed from
participation, yet not from the list of validators, increases the likelihood of
the network failing to form consensus.
With regards to the economic security, an honest 67% may remove a faulty
(explicitly or simply offline) 33%, letting 67% of the remaining 67% (4/9ths)
take control of the associated private keys. In such a case, the malicious
parties are defined as the 4/9ths of validators with access to the private key
and the 33% removed (who together form >67% of the originally intended
validator set and have presumably provided enough stake to cover losses).

38
spec/cryptography/Distributed Key Generation.md
View File

@@ -1,35 +1,7 @@
# Distributed Key Generation
Serai uses a modification of Pedersen's Distributed Key Generation, which is
actually Feldman's Verifiable Secret Sharing Scheme run by every participant, as
described in the FROST paper. The modification included in FROST was to include
a Schnorr Proof of Knowledge for coefficient zero, preventing rogue key attacks.
This results in a two-round protocol.
### Encryption
In order to protect the secret shares during communication, the `dkg` library
establishes a public key for encryption at the start of a given protocol.
Every encrypted message (such as the secret shares) then includes a per-message
encryption key. These two keys are used in an Elliptic-curve Diffie-Hellman
handshake to derive a shared key. This shared key is then hashed to obtain a key
and IV for use in a ChaCha20 stream cipher instance, which is xor'd against a
message to encrypt it.
### Blame
Since each message has a distinct key attached, and accordingly a distinct
shared key, it's possible to reveal the shared key for a specific message
without revealing any other message's decryption keys. This is utilized when a
participant misbehaves. A participant who receives an invalid encrypted message
publishes its key, able to without concern for side effects, With the key
published, all participants can decrypt the message in order to decide blame.
While key reuse by a participant is considered as them revealing the messages
themselves, and therefore out of scope, there is an attack where a malicious
adversary claims another participant's encryption key. They'll fail to encrypt
their message, and the recipient will issue a blame statement. This blame
statement, intended to reveal the malicious adversary, also reveals the message
by the participant whose keys were co-opted. To resolve this, a
proof-of-possession is also included with encrypted messages, ensuring only
those actually with per-message keys can claim to use them.
Serai uses a modification of the one-round Distributed Key Generation described
in the [eVRF](https://eprint.iacr.org/2024/397) paper. We only require a
threshold to participate, sacrificing unbiased for robustness, and implement a
verifiable encryption scheme such that anyone can can verify a ciphertext
encrypts the expected secret share.

31
spec/processor/Processor.md
View File

@@ -9,29 +9,22 @@ This document primarily discusses its flow with regards to the coordinator.
### Generate Key
On `key_gen::CoordinatorMessage::GenerateKey`, the processor begins a pair of
instances of the distributed key generation protocol specified in the FROST
paper.
instances of the distributed key generation protocol.
The first instance is for a key to use on the external network. The second
instance is for a Ristretto public key used to publish data to the Serai
blockchain. This pair of FROST DKG instances is considered a single instance of
Serai's overall key generation protocol.
The first instance is for a Ristretto public key used to publish data to the
Serai blockchain. The second instance is for a key to use on the external
network. This pair of DKG instances is considered a single instance of Serai's
overall DKG protocol.
The commitments for both protocols are sent to the coordinator in a single
`key_gen::ProcessorMessage::Commitments`.
The participations in both protocols are sent to the coordinator in a single
`key_gen::ProcessorMessage::Participation`.
### Key Gen Commitments
### Key Gen Participations
On `key_gen::CoordinatorMessage::Commitments`, the processor continues the
specified key generation instance. The secret shares for each fellow
participant are sent to the coordinator in a
`key_gen::ProcessorMessage::Shares`.
#### Key Gen Shares
On `key_gen::CoordinatorMessage::Shares`, the processor completes the specified
key generation instance. The generated key pair is sent to the coordinator in a
`key_gen::ProcessorMessage::GeneratedKeyPair`.
On `key_gen::CoordinatorMessage::Participation`, the processor stores the
contained participation, verifying participations as sane. Once it receives `t`
honest participations, the processor completes the DKG and sends the generated
key pair to the coordinator in a `key_gen::ProcessorMessage::GeneratedKeyPair`.
### Confirm Key Pair