diff --git a/spec/DKG Exclusions.md b/spec/DKG Exclusions.md deleted file mode 100644 index 1677da8a..00000000 --- a/spec/DKG Exclusions.md +++ /dev/null @@ -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). diff --git a/spec/cryptography/Distributed Key Generation.md b/spec/cryptography/Distributed Key Generation.md index fae5ff90..d0f209c1 100644 --- a/spec/cryptography/Distributed Key Generation.md +++ b/spec/cryptography/Distributed Key Generation.md @@ -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. diff --git a/spec/processor/Processor.md b/spec/processor/Processor.md index ca8cf428..22c83474 100644 --- a/spec/processor/Processor.md +++ b/spec/processor/Processor.md @@ -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