Ecosystem/serai
Ecosystem/serai
1
0
Fork 0
mirror of https://github.com/serai-dex/serai.git synced 2025-03-12 09:26:51 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 1

Add a comprehensive README to dleq

Browse source
This commit is contained in:
Luke Parker 2022-07-07 09:34:35 -04:00
parent 72afcf1f06
commit 7cbdcc8ae6
1 changed files with 57 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

62
crypto/dleq/README.md
View file

@ -2,9 +2,61 @@
Implementation of discrete log equality both within a group and across groups,
the latter being extremely experimental, for curves implementing the ff/group
APIs. This library has not undergone auditing.
APIs. This library has not undergone auditing and the cross-group DLEq proof has
no formal proofs available.
The cross-group DLEq is the one described in
https://web.getmonero.org/resources/research-lab/pubs/MRL-0010.pdf, augmented
with a pair of Schnorr Proof of Knowledges in order to correct for a mistake
present in the paper.
### Cross-Group DLEq
The present cross-group DLEq is based off
[MRL-0010](https://web.getmonero.org/resources/research-lab/pubs/MRL-0010.pdf),
which isn't computationally correct as while it proves both keys have the same
discrete-log value for the G'/H' component, yet 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 Secp256k1/Ed25519 on a
Intel i7-118567:
| Algorithm | Size | Performance |
|--------------------|-------------------------|-------------------|
| `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 choce 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.