serai/crypto/dleq
Luke Parker 79aff5d4c8
ff 0.13 (#269)
* Partial move to ff 0.13

It turns out the newly released k256 0.12 isn't on ff 0.13, preventing further
work at this time.

* Update all crates to work on ff 0.13

The provided curves still need to be expanded to fit the new API.

* Finish adding dalek-ff-group ff 0.13 constants

* Correct FieldElement::product definition

Also stops exporting macros.

* Test most new parts of ff 0.13

* Additionally test ff-group-tests with BLS12-381 and the pasta curves

We only tested curves from RustCrypto. Now we test a curve offered by zk-crypto,
the group behind ff/group, and the pasta curves, which is by Zcash (though
Zcash developers are also behind zk-crypto).

* Finish Ed448

Fully specifies all constants, passes all tests in ff-group-tests, and finishes moving to ff-0.13.

* Add RustCrypto/elliptic-curves to allowed git repos

Needed due to k256/p256 incorrectly defining product.

* Finish writing ff 0.13 tests

* Add additional comments to dalek

* Further comments

* Update ethereum-serai to ff 0.13
2023-03-28 04:38:01 -04:00
..
src ff 0.13 (#269) 2023-03-28 04:38:01 -04:00
Cargo.toml ff 0.13 (#269) 2023-03-28 04:38:01 -04:00
LICENSE Update licenses 2023-01-11 23:05:31 -05:00
README.md Fully document crypto/ 2023-03-20 20:10:00 -04:00

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, except for the experimental feature, was audited by Cypher Stack in March 2023, culminating in commit 669d2dbffc1dafb82a09d9419ea182667115df06. Any subsequent changes have 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.