Update spec to the new DKG

spec/DKG Exclusions.md

@@ -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).

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
+Serai uses a modification of the one-round Distributed Key Generation described
-actually Feldman's Verifiable Secret Sharing Scheme run by every participant, as
+in the [eVRF](https://eprint.iacr.org/2024/397) paper. We only require a
-described in the FROST paper. The modification included in FROST was to include
+threshold to participate, sacrificing unbiased for robustness, and implement a
-a Schnorr Proof of Knowledge for coefficient zero, preventing rogue key attacks.
+verifiable encryption scheme such that anyone can can verify a ciphertext
-This results in a two-round protocol.
+encrypts the expected secret share.
-
-### 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.

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