* Label the version as an alpha
* Add versions to Cargo.tomls
* Update to Zeroize 1.5
* Drop patch versions from monero-serai Cargo.toml
* Add a repository field
* Move generators to OUT_DIR
IIRC, I didn't do this originally as it constantly re-generated them.
Unfortunately, since cargo is complaining about .generators, we have to.
* Remove Timelock::fee_weight
Transaction::fee_weight's has a comment, "Assumes Timelock::None since
this library won't let you create a TX with a timelock". Accordingly,
this is dead code.
* Theoretical ed448 impl
* Fixes
* Basic tests
* More efficient scalarmul
Precomputes a table to minimize additions required.
* Add a torsion test
* Split into a constant and variable time backend
The variable time one is still far too slow, at 53s for the tests (~5s a
scalarmul). It should be usable as a PoC though.
* Rename unsafe Ed448
It's not only unworthy of the Serai branding and deserves more clarity
in the name.
* Add wide reduction to ed448
* Add Zeroize to Ed448
* Rename Ed448 group.rs to point.rs
* Minor lint to FROST
* Ed448 ciphersuite with 8032 test vector
* Macro out the backend fields
* Slight efficiency improvement to point decompression
* Disable the multiexp test in FROST for Ed448
* fmt + clippy ed448
* Fix an infinite loop in the constant time ed448 backend
* Add b"chal" to the 8032 context string for Ed448
Successfully tests against proposed vectors for the FROST IETF draft.
* Fix fmt and clippy
* Use a tabled pow algorithm in ed448's const backend
* Slight tweaks to variable time backend
Stop from_repr(MODULUS) from passing.
* Use extended points
Almost two orders of magnitude faster.
* Efficient ed448 doubling
* Remove the variable time backend
With the recent performance improvements, the constant time backend is
now 4x faster than the variable time backend was. While the variable
time backend remains much faster, and the constant time backend is still
slow compared to other libraries, it's sufficiently performant now.
The FROST test, which runs a series of multiexps over the curve, does
take 218.26s while Ristretto takes 1 and secp256k1 takes 4.57s.
While 50x slower than secp256k1 is horrible, it's ~1.5 orders of
magntiude, which is close enough to the desire stated in
https://github.com/serai-dex/serai/issues/108 to meet it.
Largely makes this library safe to use.
* Correct constants in ed448
* Rename unsafe-ed448 to minimal-ed448
Enables all FROST tests against it.
* No longer require the hazmat feature to use ed448
* Remove extraneous as_refs
Potentially improves privacy with the reversion to a coordinator
setting, where the coordinator is the only party with the offset. While
any signer (or anyone) can claim key A relates to B, they can't prove it
without the discrete log of the offset. This enables creating a signing
process without a known offset, while maintaining a consistent
transcript format.
Doesn't affect security given a static generator. Does have a slight
effect on performance.
* 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
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
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.
Relies on the ff/group API, instead of the custom Curve type.
Also removes GENERATOR_TABLE, only used by dalek, as we should provide
our own API for that over ff/group instead. This slows down the FROST
tests, under debug, by about 0.2-0.3s. Ed25519 and Ristretto together
take ~2.15 seconds now.
Closes https://github.com/serai-dex/serai/issues/17 by using the
PrimeFieldBits API to do so.
Should greatly speed up small batches, along with batches in the
hundreds. Saves almost a full second on the cross-group DLEq proof.
Increases usage of standardization while expanding dalek_ff_group.
Closes https://github.com/serai-dex/serai/issues/26 by moving
dfg::EdwardsPoint to only be for the prime subgroup.
Modifies FROST behavior so group_key has the offset applied regardless
of if view was called. The unaltered secret_share and
verification_shares (as they have differing values depending on the
signing set) are no longer publicly accessible.
Doesn't fully utilize ec's hash2curve module as k256 Scalar doesn't have
FromOkm for some reason. The previously present bigint reduction is
preserved.
Updates ff/group to 0.12.
Premised on https://github.com/cfrg/draft-irtf-cfrg-frost/pull/205 being
merged, as while this Ed25519 is vector compliant, it's technically not
spec compliant due to that conflict.
Given the lack of vectors for k256, it's currently a match of the p256
spec (with a distinct context string), yet p256 is still always used
when testing.
