Commit Graph

8 Commits

Author SHA1 Message Date
Luke Parker
797be71eb3 Utilize zeroize (#76)
* 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
2022-08-03 03:25:18 -05:00
Luke Parker
76a7160ea5 Correct clippy warnings
Currently intended to be done with:
cargo clippy --features "recommended merlin batch serialize experimental 
ed25519 ristretto p256 secp256k1 multisig" -- -A clippy::type_complexity 
-A dead_code
2022-07-22 02:35:17 -04:00
Luke Parker
e67033a207 Apply an initial set of rustfmt rules 2022-07-16 15:16:30 -05:00
Luke Parker
5ede5b9e8f Update the DLEq proof for any amount of generators
The two-generator limit wasn't required nor beneficial. This does 
theoretically optimize FROST, yet not for any current constructions. A 
follow up proof which would optimize current constructions has been 
noted in #38.

Adds explicit no_std support to the core DLEq proof.

Closes #34.
2022-07-13 23:29:48 -04:00
Luke Parker
4dbf50243b Fix serialization
This enabled getting the proof sizes, which are:
- ConciseLinear had a proof size of 44607 bytes
- CompromiseLinear had a proof size of 48765 bytes
- ClassicLinear had a proof size of 56829 bytes
- EfficientLinear had a proof size of 65145 byte
2022-07-07 08:36:23 -05:00
Luke Parker
44e0a41ca1 Add Classic/Compromise DLEqs and a benchmark
Formatted results from my laptop:

EfficientLinear had a average prove time of 188ms
EfficientLinear had a average verify time of 126ms

CompromiseLinear had a average prove time of 176ms
CompromiseLinear had a average verify time of 141ms

ConciseLinear had a average prove time of 191ms
ConciseLinear had a average verify time of 160ms

ClassicLinear had a average prove time of 214ms
ClassicLinear had a average verify time of 159ms

There is a decent error margin here. Concise is a drop-in replacement 
for Classic, in practice *not* theory. Efficient is optimal for 
performance, yet largest. Compromise is a middleground.
2022-07-07 08:36:23 -05:00
Luke Parker
1a2e6dc5cf Consolidate concise/efficient and clean 2022-07-07 08:36:23 -05:00
Luke Parker
26cee46950 Add a batch verified DLEq
The batch verified one offers ~23% faster verification. While this 
massively refactors for modularity, I'm still not happy with the DLEq 
proofs at the top level, nor am I happy with the AOS signatures. I'll 
work on cleaning them up more later.
2022-07-07 08:36:23 -05:00