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 |
||
|---|---|---|
| .. | ||
| src | ||
| Cargo.toml | ||
| LICENSE | ||
| README.md | ||
Discrete Log Equality
Implementation of discrete log equality proofs for curves implementing
ff/group. There is also a highly experimental cross-group DLEq proof, under
the experimental feature, which has no formal proofs available yet is
available here regardless. This library has NOT undergone auditing.
Cross-Group DLEq
The present cross-group DLEq is based off
MRL-0010,
which isn't computationally correct as while it proves both keys have the same
discrete logarithm for their G'/H' component, it doesn't prove a lack of a
G/H component. Accordingly, it was augmented with a pair of Schnorr Proof of
Knowledges, proving a known G'/H' component, guaranteeing a lack of a
G/H component (assuming an unknown relation between G/H and G'/H').
The challenges for the ring signatures were also merged, removing one-element from each bit's proof with only a slight reduction to challenge security (as instead of being uniform over each scalar field, they're uniform over the mutual bit capacity of each scalar field). This reduction is identical to the one applied to the proved-for scalar, and accordingly should not reduce overall security. It does create a lack of domain separation, yet that shouldn't be an issue.
The following variants are available:
-
ClassicLinear. This is only for reference purposes, being the above described proof, with no further optimizations. -
ConciseLinear. This proves for 2 bits at a time, not increasing the signature size for both bits yet decreasing the amount of commitments/challenges in total. -
EfficientLinear. This provides ring signatures in the form((R_G, R_H), s), instead of(e, s), and accordingly enables a batch verification of their final step. It is the most performant, and also the largest, option. -
CompromiseLinear. This provides signatures in the form((R_G, R_H), s)AND proves for 2-bits at a time. While this increases the amount of steps in verifying the ring signatures, which aren't batch verified, and decreases the amount of items batched (an operation which grows in efficiency with quantity), it strikes a balance between speed and size.
The following numbers are from benchmarks performed with k256/curve25519_dalek on a Intel i7-118567:
| Algorithm | Size | Verification Time |
|---|---|---|
ClassicLinear |
56829 bytes (+27%) | 157ms (0%) |
ConciseLinear |
44607 bytes (Reference) | 156ms (Reference) |
EfficientLinear |
65145 bytes (+46%) | 122ms (-22%) |
CompromiseLinear |
48765 bytes (+9%) | 137ms (-12%) |
CompromiseLinear is the best choice by only being marginally sub-optimal
regarding size, yet still achieving most of the desired performance
improvements. That said, neither the original postulation (which had flaws) nor
any construction here has been proven nor audited. Accordingly, they are solely
experimental, and none are recommended.
All proofs are suffixed "Linear" in the hope a logarithmic proof makes itself available, which would likely immediately become the most efficient option.