2022-11-10 22:35:09 -05:00
|
|
|
use core::ops::Deref;
|
|
|
|
|
|
|
|
|
|
use zeroize::Zeroizing;
|
2023-03-02 09:06:03 -05:00
|
|
|
use rand_core::OsRng;
|
2022-11-10 22:35:09 -05:00
|
|
|
|
2025-08-20 04:50:37 -04:00
|
|
|
use dalek_ff_group::Ed25519;
|
2023-03-07 03:46:16 -05:00
|
|
|
use ciphersuite::{
|
|
|
|
|
group::{ff::Field, Group},
|
Smash the singular `Ciphersuite` trait into multiple
This helps identify where the various functionalities are used, or rather, not
used. The `Ciphersuite` trait present in `patches/ciphersuite`, facilitating
the entire FCMP++ tree, only requires the markers _and_ canonical point
decoding. I've opened a PR to upstream such a trait into `group`
(https://github.com/zkcrypto/group/pull/68).
`WrappedGroup` is still justified for as long as `Group::generator` exists.
Moving `::generator()` to its own trait, on an independent structure (upstream)
would be massively appreciated. @tarcieri also wanted to update from
`fn generator()` to `const GENERATOR`, which would encourage further discussion
on https://github.com/zkcrypto/group/issues/32 and
https://github.com/zkcrypto/group/issues/45, which have been stagnant.
The `Id` trait is occasionally used yet really should be first off the chopping
block.
Finally, `WithPreferredHash` is only actually used around a third of the time,
which more than justifies it being a separate trait.
---
Updates `dalek_ff_group::Scalar` to directly re-export
`curve25519_dalek::Scalar`, as without issue. `dalek_ff_group::RistrettoPoint`
also could be replaced with an export of `curve25519_dalek::RistrettoPoint`,
yet the coordinator relies on how we implemented `Hash` on it for the hell of
it so it isn't worth it at this time. `dalek_ff_group::EdwardsPoint` can't be
replaced for an re-export of `curve25519_dalek::SubgroupPoint` as it doesn't
implement `zeroize`, `subtle` traits within a released, non-yanked version.
Relevance to https://github.com/serai-dex/serai/issues/201 and
https://github.com/dalek-cryptography/curve25519-dalek/issues/811#issuecomment-3247732746.
Also updates the `Ristretto` ciphersuite to prefer `Blake2b-512` over
`SHA2-512`. In order to maintain compliance with FROST's IETF standard,
`modular-frost` defines its own ciphersuite for Ristretto which still uses
`SHA2-512`.
2025-09-03 12:25:37 -04:00
|
|
|
GroupIo, WithPreferredHash,
|
2023-03-07 03:46:16 -05:00
|
|
|
};
|
2022-10-29 03:54:42 -05:00
|
|
|
use multiexp::BatchVerifier;
|
|
|
|
|
|
2025-08-19 21:45:59 -04:00
|
|
|
use crate::SchnorrSignature;
|
|
|
|
|
#[cfg(feature = "aggregate")]
|
|
|
|
|
use crate::aggregate::{SchnorrAggregator, SchnorrAggregate};
|
2022-10-29 03:54:42 -05:00
|
|
|
|
2023-03-02 09:06:03 -05:00
|
|
|
mod rfc8032;
|
|
|
|
|
|
Smash the singular `Ciphersuite` trait into multiple
This helps identify where the various functionalities are used, or rather, not
used. The `Ciphersuite` trait present in `patches/ciphersuite`, facilitating
the entire FCMP++ tree, only requires the markers _and_ canonical point
decoding. I've opened a PR to upstream such a trait into `group`
(https://github.com/zkcrypto/group/pull/68).
`WrappedGroup` is still justified for as long as `Group::generator` exists.
Moving `::generator()` to its own trait, on an independent structure (upstream)
would be massively appreciated. @tarcieri also wanted to update from
`fn generator()` to `const GENERATOR`, which would encourage further discussion
on https://github.com/zkcrypto/group/issues/32 and
https://github.com/zkcrypto/group/issues/45, which have been stagnant.
The `Id` trait is occasionally used yet really should be first off the chopping
block.
Finally, `WithPreferredHash` is only actually used around a third of the time,
which more than justifies it being a separate trait.
---
Updates `dalek_ff_group::Scalar` to directly re-export
`curve25519_dalek::Scalar`, as without issue. `dalek_ff_group::RistrettoPoint`
also could be replaced with an export of `curve25519_dalek::RistrettoPoint`,
yet the coordinator relies on how we implemented `Hash` on it for the hell of
it so it isn't worth it at this time. `dalek_ff_group::EdwardsPoint` can't be
replaced for an re-export of `curve25519_dalek::SubgroupPoint` as it doesn't
implement `zeroize`, `subtle` traits within a released, non-yanked version.
Relevance to https://github.com/serai-dex/serai/issues/201 and
https://github.com/dalek-cryptography/curve25519-dalek/issues/811#issuecomment-3247732746.
Also updates the `Ristretto` ciphersuite to prefer `Blake2b-512` over
`SHA2-512`. In order to maintain compliance with FROST's IETF standard,
`modular-frost` defines its own ciphersuite for Ristretto which still uses
`SHA2-512`.
2025-09-03 12:25:37 -04:00
|
|
|
pub(crate) fn sign<C: GroupIo>() {
|
|
|
|
|
let private_key = Zeroizing::new(C::F::random(&mut OsRng));
|
|
|
|
|
let nonce = Zeroizing::new(C::F::random(&mut OsRng));
|
|
|
|
|
let challenge = C::F::random(&mut OsRng); // Doesn't bother to craft an HRAm
|
2022-11-10 22:35:09 -05:00
|
|
|
assert!(SchnorrSignature::<C>::sign(&private_key, nonce, challenge)
|
|
|
|
|
.verify(C::generator() * private_key.deref(), challenge));
|
2022-10-29 03:54:42 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// The above sign function verifies signing works
|
|
|
|
|
// This verifies invalid signatures don't pass, using zero signatures, which should effectively be
|
|
|
|
|
// random
|
Smash the singular `Ciphersuite` trait into multiple
This helps identify where the various functionalities are used, or rather, not
used. The `Ciphersuite` trait present in `patches/ciphersuite`, facilitating
the entire FCMP++ tree, only requires the markers _and_ canonical point
decoding. I've opened a PR to upstream such a trait into `group`
(https://github.com/zkcrypto/group/pull/68).
`WrappedGroup` is still justified for as long as `Group::generator` exists.
Moving `::generator()` to its own trait, on an independent structure (upstream)
would be massively appreciated. @tarcieri also wanted to update from
`fn generator()` to `const GENERATOR`, which would encourage further discussion
on https://github.com/zkcrypto/group/issues/32 and
https://github.com/zkcrypto/group/issues/45, which have been stagnant.
The `Id` trait is occasionally used yet really should be first off the chopping
block.
Finally, `WithPreferredHash` is only actually used around a third of the time,
which more than justifies it being a separate trait.
---
Updates `dalek_ff_group::Scalar` to directly re-export
`curve25519_dalek::Scalar`, as without issue. `dalek_ff_group::RistrettoPoint`
also could be replaced with an export of `curve25519_dalek::RistrettoPoint`,
yet the coordinator relies on how we implemented `Hash` on it for the hell of
it so it isn't worth it at this time. `dalek_ff_group::EdwardsPoint` can't be
replaced for an re-export of `curve25519_dalek::SubgroupPoint` as it doesn't
implement `zeroize`, `subtle` traits within a released, non-yanked version.
Relevance to https://github.com/serai-dex/serai/issues/201 and
https://github.com/dalek-cryptography/curve25519-dalek/issues/811#issuecomment-3247732746.
Also updates the `Ristretto` ciphersuite to prefer `Blake2b-512` over
`SHA2-512`. In order to maintain compliance with FROST's IETF standard,
`modular-frost` defines its own ciphersuite for Ristretto which still uses
`SHA2-512`.
2025-09-03 12:25:37 -04:00
|
|
|
pub(crate) fn verify<C: GroupIo>() {
|
2023-03-28 04:38:01 -04:00
|
|
|
assert!(!SchnorrSignature::<C> { R: C::G::identity(), s: C::F::ZERO }
|
Smash the singular `Ciphersuite` trait into multiple
This helps identify where the various functionalities are used, or rather, not
used. The `Ciphersuite` trait present in `patches/ciphersuite`, facilitating
the entire FCMP++ tree, only requires the markers _and_ canonical point
decoding. I've opened a PR to upstream such a trait into `group`
(https://github.com/zkcrypto/group/pull/68).
`WrappedGroup` is still justified for as long as `Group::generator` exists.
Moving `::generator()` to its own trait, on an independent structure (upstream)
would be massively appreciated. @tarcieri also wanted to update from
`fn generator()` to `const GENERATOR`, which would encourage further discussion
on https://github.com/zkcrypto/group/issues/32 and
https://github.com/zkcrypto/group/issues/45, which have been stagnant.
The `Id` trait is occasionally used yet really should be first off the chopping
block.
Finally, `WithPreferredHash` is only actually used around a third of the time,
which more than justifies it being a separate trait.
---
Updates `dalek_ff_group::Scalar` to directly re-export
`curve25519_dalek::Scalar`, as without issue. `dalek_ff_group::RistrettoPoint`
also could be replaced with an export of `curve25519_dalek::RistrettoPoint`,
yet the coordinator relies on how we implemented `Hash` on it for the hell of
it so it isn't worth it at this time. `dalek_ff_group::EdwardsPoint` can't be
replaced for an re-export of `curve25519_dalek::SubgroupPoint` as it doesn't
implement `zeroize`, `subtle` traits within a released, non-yanked version.
Relevance to https://github.com/serai-dex/serai/issues/201 and
https://github.com/dalek-cryptography/curve25519-dalek/issues/811#issuecomment-3247732746.
Also updates the `Ristretto` ciphersuite to prefer `Blake2b-512` over
`SHA2-512`. In order to maintain compliance with FROST's IETF standard,
`modular-frost` defines its own ciphersuite for Ristretto which still uses
`SHA2-512`.
2025-09-03 12:25:37 -04:00
|
|
|
.verify(C::generator() * C::F::random(&mut OsRng), C::F::random(&mut OsRng)));
|
2022-10-29 03:54:42 -05:00
|
|
|
}
|
|
|
|
|
|
Smash the singular `Ciphersuite` trait into multiple
This helps identify where the various functionalities are used, or rather, not
used. The `Ciphersuite` trait present in `patches/ciphersuite`, facilitating
the entire FCMP++ tree, only requires the markers _and_ canonical point
decoding. I've opened a PR to upstream such a trait into `group`
(https://github.com/zkcrypto/group/pull/68).
`WrappedGroup` is still justified for as long as `Group::generator` exists.
Moving `::generator()` to its own trait, on an independent structure (upstream)
would be massively appreciated. @tarcieri also wanted to update from
`fn generator()` to `const GENERATOR`, which would encourage further discussion
on https://github.com/zkcrypto/group/issues/32 and
https://github.com/zkcrypto/group/issues/45, which have been stagnant.
The `Id` trait is occasionally used yet really should be first off the chopping
block.
Finally, `WithPreferredHash` is only actually used around a third of the time,
which more than justifies it being a separate trait.
---
Updates `dalek_ff_group::Scalar` to directly re-export
`curve25519_dalek::Scalar`, as without issue. `dalek_ff_group::RistrettoPoint`
also could be replaced with an export of `curve25519_dalek::RistrettoPoint`,
yet the coordinator relies on how we implemented `Hash` on it for the hell of
it so it isn't worth it at this time. `dalek_ff_group::EdwardsPoint` can't be
replaced for an re-export of `curve25519_dalek::SubgroupPoint` as it doesn't
implement `zeroize`, `subtle` traits within a released, non-yanked version.
Relevance to https://github.com/serai-dex/serai/issues/201 and
https://github.com/dalek-cryptography/curve25519-dalek/issues/811#issuecomment-3247732746.
Also updates the `Ristretto` ciphersuite to prefer `Blake2b-512` over
`SHA2-512`. In order to maintain compliance with FROST's IETF standard,
`modular-frost` defines its own ciphersuite for Ristretto which still uses
`SHA2-512`.
2025-09-03 12:25:37 -04:00
|
|
|
pub(crate) fn batch_verify<C: GroupIo>() {
|
2022-10-29 03:54:42 -05:00
|
|
|
// Create 5 signatures
|
|
|
|
|
let mut keys = vec![];
|
|
|
|
|
let mut challenges = vec![];
|
|
|
|
|
let mut sigs = vec![];
|
|
|
|
|
for i in 0 .. 5 {
|
Smash the singular `Ciphersuite` trait into multiple
This helps identify where the various functionalities are used, or rather, not
used. The `Ciphersuite` trait present in `patches/ciphersuite`, facilitating
the entire FCMP++ tree, only requires the markers _and_ canonical point
decoding. I've opened a PR to upstream such a trait into `group`
(https://github.com/zkcrypto/group/pull/68).
`WrappedGroup` is still justified for as long as `Group::generator` exists.
Moving `::generator()` to its own trait, on an independent structure (upstream)
would be massively appreciated. @tarcieri also wanted to update from
`fn generator()` to `const GENERATOR`, which would encourage further discussion
on https://github.com/zkcrypto/group/issues/32 and
https://github.com/zkcrypto/group/issues/45, which have been stagnant.
The `Id` trait is occasionally used yet really should be first off the chopping
block.
Finally, `WithPreferredHash` is only actually used around a third of the time,
which more than justifies it being a separate trait.
---
Updates `dalek_ff_group::Scalar` to directly re-export
`curve25519_dalek::Scalar`, as without issue. `dalek_ff_group::RistrettoPoint`
also could be replaced with an export of `curve25519_dalek::RistrettoPoint`,
yet the coordinator relies on how we implemented `Hash` on it for the hell of
it so it isn't worth it at this time. `dalek_ff_group::EdwardsPoint` can't be
replaced for an re-export of `curve25519_dalek::SubgroupPoint` as it doesn't
implement `zeroize`, `subtle` traits within a released, non-yanked version.
Relevance to https://github.com/serai-dex/serai/issues/201 and
https://github.com/dalek-cryptography/curve25519-dalek/issues/811#issuecomment-3247732746.
Also updates the `Ristretto` ciphersuite to prefer `Blake2b-512` over
`SHA2-512`. In order to maintain compliance with FROST's IETF standard,
`modular-frost` defines its own ciphersuite for Ristretto which still uses
`SHA2-512`.
2025-09-03 12:25:37 -04:00
|
|
|
keys.push(Zeroizing::new(C::F::random(&mut OsRng)));
|
|
|
|
|
challenges.push(C::F::random(&mut OsRng));
|
2022-11-10 22:35:09 -05:00
|
|
|
sigs.push(SchnorrSignature::<C>::sign(
|
|
|
|
|
&keys[i],
|
Smash the singular `Ciphersuite` trait into multiple
This helps identify where the various functionalities are used, or rather, not
used. The `Ciphersuite` trait present in `patches/ciphersuite`, facilitating
the entire FCMP++ tree, only requires the markers _and_ canonical point
decoding. I've opened a PR to upstream such a trait into `group`
(https://github.com/zkcrypto/group/pull/68).
`WrappedGroup` is still justified for as long as `Group::generator` exists.
Moving `::generator()` to its own trait, on an independent structure (upstream)
would be massively appreciated. @tarcieri also wanted to update from
`fn generator()` to `const GENERATOR`, which would encourage further discussion
on https://github.com/zkcrypto/group/issues/32 and
https://github.com/zkcrypto/group/issues/45, which have been stagnant.
The `Id` trait is occasionally used yet really should be first off the chopping
block.
Finally, `WithPreferredHash` is only actually used around a third of the time,
which more than justifies it being a separate trait.
---
Updates `dalek_ff_group::Scalar` to directly re-export
`curve25519_dalek::Scalar`, as without issue. `dalek_ff_group::RistrettoPoint`
also could be replaced with an export of `curve25519_dalek::RistrettoPoint`,
yet the coordinator relies on how we implemented `Hash` on it for the hell of
it so it isn't worth it at this time. `dalek_ff_group::EdwardsPoint` can't be
replaced for an re-export of `curve25519_dalek::SubgroupPoint` as it doesn't
implement `zeroize`, `subtle` traits within a released, non-yanked version.
Relevance to https://github.com/serai-dex/serai/issues/201 and
https://github.com/dalek-cryptography/curve25519-dalek/issues/811#issuecomment-3247732746.
Also updates the `Ristretto` ciphersuite to prefer `Blake2b-512` over
`SHA2-512`. In order to maintain compliance with FROST's IETF standard,
`modular-frost` defines its own ciphersuite for Ristretto which still uses
`SHA2-512`.
2025-09-03 12:25:37 -04:00
|
|
|
Zeroizing::new(C::F::random(&mut OsRng)),
|
2022-11-10 22:35:09 -05:00
|
|
|
challenges[i],
|
|
|
|
|
));
|
2022-10-29 03:54:42 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Batch verify
|
|
|
|
|
{
|
|
|
|
|
let mut batch = BatchVerifier::new(5);
|
|
|
|
|
for (i, sig) in sigs.iter().enumerate() {
|
2022-11-10 22:35:09 -05:00
|
|
|
sig.batch_verify(&mut OsRng, &mut batch, i, C::generator() * keys[i].deref(), challenges[i]);
|
2022-10-29 03:54:42 -05:00
|
|
|
}
|
2023-03-02 08:45:09 -05:00
|
|
|
batch.verify_vartime_with_vartime_blame().unwrap();
|
2022-10-29 03:54:42 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Shift 1 from s from one to another and verify it fails
|
|
|
|
|
// This test will fail if unique factors aren't used per-signature, hence its inclusion
|
|
|
|
|
{
|
|
|
|
|
let mut batch = BatchVerifier::new(5);
|
|
|
|
|
for (i, mut sig) in sigs.clone().drain(..).enumerate() {
|
|
|
|
|
if i == 1 {
|
2023-03-28 04:38:01 -04:00
|
|
|
sig.s += C::F::ONE;
|
2022-10-29 03:54:42 -05:00
|
|
|
}
|
|
|
|
|
if i == 2 {
|
2023-03-28 04:38:01 -04:00
|
|
|
sig.s -= C::F::ONE;
|
2022-10-29 03:54:42 -05:00
|
|
|
}
|
2022-11-10 22:35:09 -05:00
|
|
|
sig.batch_verify(&mut OsRng, &mut batch, i, C::generator() * keys[i].deref(), challenges[i]);
|
2022-10-29 03:54:42 -05:00
|
|
|
}
|
2023-03-02 08:45:09 -05:00
|
|
|
if let Err(blame) = batch.verify_vartime_with_vartime_blame() {
|
2022-10-29 03:54:42 -05:00
|
|
|
assert!((blame == 1) || (blame == 2));
|
|
|
|
|
} else {
|
|
|
|
|
panic!("Batch verification considered malleated signatures valid");
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2025-08-19 21:45:59 -04:00
|
|
|
#[cfg(feature = "aggregate")]
|
Smash the singular `Ciphersuite` trait into multiple
This helps identify where the various functionalities are used, or rather, not
used. The `Ciphersuite` trait present in `patches/ciphersuite`, facilitating
the entire FCMP++ tree, only requires the markers _and_ canonical point
decoding. I've opened a PR to upstream such a trait into `group`
(https://github.com/zkcrypto/group/pull/68).
`WrappedGroup` is still justified for as long as `Group::generator` exists.
Moving `::generator()` to its own trait, on an independent structure (upstream)
would be massively appreciated. @tarcieri also wanted to update from
`fn generator()` to `const GENERATOR`, which would encourage further discussion
on https://github.com/zkcrypto/group/issues/32 and
https://github.com/zkcrypto/group/issues/45, which have been stagnant.
The `Id` trait is occasionally used yet really should be first off the chopping
block.
Finally, `WithPreferredHash` is only actually used around a third of the time,
which more than justifies it being a separate trait.
---
Updates `dalek_ff_group::Scalar` to directly re-export
`curve25519_dalek::Scalar`, as without issue. `dalek_ff_group::RistrettoPoint`
also could be replaced with an export of `curve25519_dalek::RistrettoPoint`,
yet the coordinator relies on how we implemented `Hash` on it for the hell of
it so it isn't worth it at this time. `dalek_ff_group::EdwardsPoint` can't be
replaced for an re-export of `curve25519_dalek::SubgroupPoint` as it doesn't
implement `zeroize`, `subtle` traits within a released, non-yanked version.
Relevance to https://github.com/serai-dex/serai/issues/201 and
https://github.com/dalek-cryptography/curve25519-dalek/issues/811#issuecomment-3247732746.
Also updates the `Ristretto` ciphersuite to prefer `Blake2b-512` over
`SHA2-512`. In order to maintain compliance with FROST's IETF standard,
`modular-frost` defines its own ciphersuite for Ristretto which still uses
`SHA2-512`.
2025-09-03 12:25:37 -04:00
|
|
|
pub(crate) fn aggregate<C: GroupIo + WithPreferredHash>() {
|
2023-03-02 09:29:37 -05:00
|
|
|
const DST: &[u8] = b"Schnorr Aggregator Test";
|
|
|
|
|
|
2022-11-04 08:03:29 -04:00
|
|
|
// Create 5 signatures
|
|
|
|
|
let mut keys = vec![];
|
|
|
|
|
let mut challenges = vec![];
|
2023-03-02 10:04:18 -05:00
|
|
|
let mut aggregator = SchnorrAggregator::<C>::new(DST);
|
2022-11-04 08:03:29 -04:00
|
|
|
for i in 0 .. 5 {
|
Smash the singular `Ciphersuite` trait into multiple
This helps identify where the various functionalities are used, or rather, not
used. The `Ciphersuite` trait present in `patches/ciphersuite`, facilitating
the entire FCMP++ tree, only requires the markers _and_ canonical point
decoding. I've opened a PR to upstream such a trait into `group`
(https://github.com/zkcrypto/group/pull/68).
`WrappedGroup` is still justified for as long as `Group::generator` exists.
Moving `::generator()` to its own trait, on an independent structure (upstream)
would be massively appreciated. @tarcieri also wanted to update from
`fn generator()` to `const GENERATOR`, which would encourage further discussion
on https://github.com/zkcrypto/group/issues/32 and
https://github.com/zkcrypto/group/issues/45, which have been stagnant.
The `Id` trait is occasionally used yet really should be first off the chopping
block.
Finally, `WithPreferredHash` is only actually used around a third of the time,
which more than justifies it being a separate trait.
---
Updates `dalek_ff_group::Scalar` to directly re-export
`curve25519_dalek::Scalar`, as without issue. `dalek_ff_group::RistrettoPoint`
also could be replaced with an export of `curve25519_dalek::RistrettoPoint`,
yet the coordinator relies on how we implemented `Hash` on it for the hell of
it so it isn't worth it at this time. `dalek_ff_group::EdwardsPoint` can't be
replaced for an re-export of `curve25519_dalek::SubgroupPoint` as it doesn't
implement `zeroize`, `subtle` traits within a released, non-yanked version.
Relevance to https://github.com/serai-dex/serai/issues/201 and
https://github.com/dalek-cryptography/curve25519-dalek/issues/811#issuecomment-3247732746.
Also updates the `Ristretto` ciphersuite to prefer `Blake2b-512` over
`SHA2-512`. In order to maintain compliance with FROST's IETF standard,
`modular-frost` defines its own ciphersuite for Ristretto which still uses
`SHA2-512`.
2025-09-03 12:25:37 -04:00
|
|
|
keys.push(Zeroizing::new(C::F::random(&mut OsRng)));
|
2023-03-02 09:29:37 -05:00
|
|
|
// In practice, this MUST be a secure challenge binding to the nonce, key, and any message
|
Smash the singular `Ciphersuite` trait into multiple
This helps identify where the various functionalities are used, or rather, not
used. The `Ciphersuite` trait present in `patches/ciphersuite`, facilitating
the entire FCMP++ tree, only requires the markers _and_ canonical point
decoding. I've opened a PR to upstream such a trait into `group`
(https://github.com/zkcrypto/group/pull/68).
`WrappedGroup` is still justified for as long as `Group::generator` exists.
Moving `::generator()` to its own trait, on an independent structure (upstream)
would be massively appreciated. @tarcieri also wanted to update from
`fn generator()` to `const GENERATOR`, which would encourage further discussion
on https://github.com/zkcrypto/group/issues/32 and
https://github.com/zkcrypto/group/issues/45, which have been stagnant.
The `Id` trait is occasionally used yet really should be first off the chopping
block.
Finally, `WithPreferredHash` is only actually used around a third of the time,
which more than justifies it being a separate trait.
---
Updates `dalek_ff_group::Scalar` to directly re-export
`curve25519_dalek::Scalar`, as without issue. `dalek_ff_group::RistrettoPoint`
also could be replaced with an export of `curve25519_dalek::RistrettoPoint`,
yet the coordinator relies on how we implemented `Hash` on it for the hell of
it so it isn't worth it at this time. `dalek_ff_group::EdwardsPoint` can't be
replaced for an re-export of `curve25519_dalek::SubgroupPoint` as it doesn't
implement `zeroize`, `subtle` traits within a released, non-yanked version.
Relevance to https://github.com/serai-dex/serai/issues/201 and
https://github.com/dalek-cryptography/curve25519-dalek/issues/811#issuecomment-3247732746.
Also updates the `Ristretto` ciphersuite to prefer `Blake2b-512` over
`SHA2-512`. In order to maintain compliance with FROST's IETF standard,
`modular-frost` defines its own ciphersuite for Ristretto which still uses
`SHA2-512`.
2025-09-03 12:25:37 -04:00
|
|
|
challenges.push(C::F::random(&mut OsRng));
|
2022-11-04 08:03:29 -04:00
|
|
|
aggregator.aggregate(
|
|
|
|
|
challenges[i],
|
2022-11-10 22:35:09 -05:00
|
|
|
SchnorrSignature::<C>::sign(
|
|
|
|
|
&keys[i],
|
Smash the singular `Ciphersuite` trait into multiple
This helps identify where the various functionalities are used, or rather, not
used. The `Ciphersuite` trait present in `patches/ciphersuite`, facilitating
the entire FCMP++ tree, only requires the markers _and_ canonical point
decoding. I've opened a PR to upstream such a trait into `group`
(https://github.com/zkcrypto/group/pull/68).
`WrappedGroup` is still justified for as long as `Group::generator` exists.
Moving `::generator()` to its own trait, on an independent structure (upstream)
would be massively appreciated. @tarcieri also wanted to update from
`fn generator()` to `const GENERATOR`, which would encourage further discussion
on https://github.com/zkcrypto/group/issues/32 and
https://github.com/zkcrypto/group/issues/45, which have been stagnant.
The `Id` trait is occasionally used yet really should be first off the chopping
block.
Finally, `WithPreferredHash` is only actually used around a third of the time,
which more than justifies it being a separate trait.
---
Updates `dalek_ff_group::Scalar` to directly re-export
`curve25519_dalek::Scalar`, as without issue. `dalek_ff_group::RistrettoPoint`
also could be replaced with an export of `curve25519_dalek::RistrettoPoint`,
yet the coordinator relies on how we implemented `Hash` on it for the hell of
it so it isn't worth it at this time. `dalek_ff_group::EdwardsPoint` can't be
replaced for an re-export of `curve25519_dalek::SubgroupPoint` as it doesn't
implement `zeroize`, `subtle` traits within a released, non-yanked version.
Relevance to https://github.com/serai-dex/serai/issues/201 and
https://github.com/dalek-cryptography/curve25519-dalek/issues/811#issuecomment-3247732746.
Also updates the `Ristretto` ciphersuite to prefer `Blake2b-512` over
`SHA2-512`. In order to maintain compliance with FROST's IETF standard,
`modular-frost` defines its own ciphersuite for Ristretto which still uses
`SHA2-512`.
2025-09-03 12:25:37 -04:00
|
|
|
Zeroizing::new(C::F::random(&mut OsRng)),
|
2022-11-10 22:35:09 -05:00
|
|
|
challenges[i],
|
|
|
|
|
),
|
2022-11-04 08:03:29 -04:00
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
let aggregate = aggregator.complete().unwrap();
|
|
|
|
|
let aggregate =
|
|
|
|
|
SchnorrAggregate::<C>::read::<&[u8]>(&mut aggregate.serialize().as_ref()).unwrap();
|
2023-03-02 10:04:18 -05:00
|
|
|
assert!(aggregate.verify(
|
2023-03-02 09:29:37 -05:00
|
|
|
DST,
|
2022-11-04 08:03:29 -04:00
|
|
|
keys
|
|
|
|
|
.iter()
|
2022-11-10 22:35:09 -05:00
|
|
|
.map(|key| C::generator() * key.deref())
|
2023-07-08 11:29:05 -04:00
|
|
|
.zip(challenges.iter().copied())
|
2022-11-04 08:03:29 -04:00
|
|
|
.collect::<Vec<_>>()
|
2023-03-02 09:29:37 -05:00
|
|
|
.as_ref(),
|
2022-11-04 08:03:29 -04:00
|
|
|
));
|
|
|
|
|
}
|
|
|
|
|
|
2022-10-29 03:54:42 -05:00
|
|
|
#[test]
|
|
|
|
|
fn test() {
|
2023-03-02 09:06:03 -05:00
|
|
|
sign::<Ed25519>();
|
|
|
|
|
verify::<Ed25519>();
|
|
|
|
|
batch_verify::<Ed25519>();
|
2025-08-19 21:45:59 -04:00
|
|
|
#[cfg(feature = "aggregate")]
|
2023-03-02 09:06:03 -05:00
|
|
|
aggregate::<Ed25519>();
|
2022-10-29 03:54:42 -05:00
|
|
|
}
|