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.
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.
Reduces proof size by 21.5% without notable computational complexity
changes. I wouldn't be surprised if it has minor ones, yet I can't
comment in which way they go without further review.
Bit now verifies it can successfully complete the ring under debug,
slightly increasing debug times.
Few percent faster. Enables accumulating the current bit's point
representation, whereas the blinding keys can't be accumulated. Also
theoretically enables pre-computation of the bit points, removing
hundreds of additions from the proof. When tested, this was less
performant, possibly due to cache/heap allocation.
Instead of having if statements for the bits, it now has constant time
ops. While there are still if statements guiding the proof itself, they
aren't dependent on the data within.
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.
This does reduce the strength of the challenges to that of the weaker
field, yet that doesn't have any impact on whether or not this is ZK due
to the key being shared across fields.
Saves ~8kb.
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.
While Serai only needs the simple DLEq which was already present under
monero, this migrates the implementation of the cross-group DLEq I
maintain into Serai. This was to have full access to the ecosystem of
libraries built under Serai while also ensuring support for it.
The cross_group curve, which is extremely experimental, is feature
flagged off. So is the built in serialization functionality, as this
should be possible to make nostd once const generics are full featured,
yet the implemented serialization adds the additional barrier of
std::io.
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.
Collisions were possible depending on static label substrings. Now,
labels are prefixed by their length to prevent this from being possible.
All variables are also flagged by their type, preventing other potential
conflicts.
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.
