mirror of
https://github.com/serai-dex/serai.git
synced 2024-11-17 01:17:36 +00:00
5b3c9bf5d0
* Standardize the DLEq serialization function naming They mismatched from the rest of the project. This commit is technically incomplete as it doesn't update the dkg crate. * Rewrite DKG encryption to enable per-message decryption without side effects This isn't technically true as I already know a break in this which I'll correct for shortly. Does update documentation to explain the new scheme. Required for blame. * Add a verifiable system for blame during the FROST DKG Previously, if sent an invalid key share, the participant would realize that and could accuse the sender. Without further evidence, either the accuser or the accused could be guilty. Now, the accuser has a proof the accused is in the wrong. Reworks KeyMachine to return BlameMachine. This explicitly acknowledges how locally complete keys still need group acknowledgement before the protocol can be complete and provides a way for others to verify blame, even after a locally successful run. If any blame is cast, the protocol is no longer considered complete-able (instead aborting). Further accusations of blame can still be handled however. Updates documentation on network behavior. Also starts to remove "OnDrop". We now use Zeroizing for anything which should be zeroized on drop. This is a lot more piece-meal and reduces clones. * Tweak Zeroizing and Debug impls Expands Zeroizing to be more comprehensive. Also updates Zeroizing<CachedPreprocess([u8; 32])> to CachedPreprocess(Zeroizing<[u8; 32]>) so zeroizing is the first thing done and last step before exposing the copy-able [u8; 32]. Removes private keys from Debug. * Fix a bug where adversaries could claim to be using another user's encryption keys to learn their messages Mentioned a few commits ago, now fixed. This wouldn't have affected Serai, which aborts on failure, nor any DKG currently supported. It's just about ensuring the DKG encryption is robust and proper. * Finish moving dleq from ser/deser to write/read * Add tests for dkg blame * Add a FROST test for invalid signature shares * Batch verify encrypted messages' ephemeral keys' PoP
35 lines
1.9 KiB
Markdown
35 lines
1.9 KiB
Markdown
# 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.
|