797be71eb3
* Apply Zeroize to nonces used in Bulletproofs Also makes bit decomposition constant time for a given amount of outputs. * Fix nonce reuse for single-signer CLSAG * Attach Zeroize to most structures in Monero, and ZOnDrop to anything with private data * Zeroize private keys and nonces * Merge prepare_outputs and prepare_transactions * Ensure CLSAG is constant time * Pass by borrow where needed, bug fixes The past few commitments have been one in-progress chunk which I've broken up as best read. * Add Zeroize to FROST structs Still needs to zeroize internally, yet next step. Not quite as aggressive as Monero, partially due to the limitations of HashMaps, partially due to less concern about metadata, yet does still delete a few smaller items of metadata (group key, context string...). * Remove Zeroize from most Monero multisig structs These structs largely didn't have private data, just fields with private data, yet those fields implemented ZeroizeOnDrop making them already covered. While there is still traces of the transaction left in RAM, fully purging that was never the intent. * Use Zeroize within dleq bitvec doesn't offer Zeroize, so a manual zeroing has been implemented. * Use Zeroize for random_nonce It isn't perfect, due to the inability to zeroize the digest, and due to kp256 requiring a few transformations. It does the best it can though. Does move the per-curve random_nonce to a provided one, which is allowed as of https://github.com/cfrg/draft-irtf-cfrg-frost/pull/231. * Use Zeroize on FROST keygen/signing * Zeroize constant time multiexp. * Correct when FROST keygen zeroizes * Move the FROST keys Arc into FrostKeys Reduces amount of instances in memory. * Manually implement Debug for FrostCore to not leak the secret share * Misc bug fixes * clippy + multiexp test bug fixes * Correct FROST key gen share summation It leaked our own share for ourself. * Fix cross-group DLEq tests |
||
|---|---|---|
| .. | ||
| 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.