2023-04-10 06:05:17 -04:00
|
|
|
#![cfg_attr(docsrs, feature(doc_auto_cfg))]
|
|
|
|
|
#![doc = include_str!("../README.md")]
|
2025-09-15 23:16:11 -04:00
|
|
|
#![cfg_attr(not(feature = "std"), no_std)]
|
2023-04-10 06:05:17 -04:00
|
|
|
|
2025-09-15 23:16:11 -04:00
|
|
|
#[allow(unused_imports)]
|
|
|
|
|
use std_shims::prelude::*;
|
|
|
|
|
use std_shims::io::{self, Read};
|
2023-04-10 06:05:17 -04:00
|
|
|
|
|
|
|
|
use rand_core::{RngCore, CryptoRng};
|
|
|
|
|
|
|
|
|
|
use zeroize::Zeroizing;
|
|
|
|
|
|
|
|
|
|
use transcript::{Transcript, MerlinTranscript};
|
|
|
|
|
|
2025-08-20 04:50:37 -04:00
|
|
|
use ciphersuite::{
|
|
|
|
|
group::{ff::PrimeField, GroupEncoding},
|
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
|
|
|
WrappedGroup,
|
2025-08-20 04:50:37 -04:00
|
|
|
};
|
2023-04-10 06:05:17 -04:00
|
|
|
use schnorr::SchnorrSignature;
|
|
|
|
|
|
|
|
|
|
use ::frost::{
|
|
|
|
|
Participant, ThresholdKeys, ThresholdView, FrostError,
|
|
|
|
|
algorithm::{Hram, Algorithm, Schnorr},
|
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
|
|
|
curve::Ristretto,
|
2023-04-10 06:05:17 -04:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/// The [modular-frost](https://docs.rs/modular-frost) library.
|
|
|
|
|
pub mod frost {
|
|
|
|
|
pub use ::frost::*;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
use schnorrkel::{PublicKey, Signature, context::SigningTranscript, signing_context};
|
|
|
|
|
|
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
|
|
|
type RistrettoPoint = <Ristretto as WrappedGroup>::G;
|
|
|
|
|
type Scalar = <Ristretto as WrappedGroup>::F;
|
2023-04-10 06:05:17 -04:00
|
|
|
|
|
|
|
|
#[cfg(test)]
|
|
|
|
|
mod tests;
|
|
|
|
|
|
|
|
|
|
#[derive(Clone)]
|
|
|
|
|
struct SchnorrkelHram;
|
|
|
|
|
impl Hram<Ristretto> for SchnorrkelHram {
|
|
|
|
|
#[allow(non_snake_case)]
|
|
|
|
|
fn hram(R: &RistrettoPoint, A: &RistrettoPoint, m: &[u8]) -> Scalar {
|
|
|
|
|
let ctx_len =
|
|
|
|
|
usize::try_from(u32::from_le_bytes(m[0 .. 4].try_into().expect("malformed message")))
|
|
|
|
|
.unwrap();
|
|
|
|
|
|
|
|
|
|
let mut t = signing_context(&m[4 .. (4 + ctx_len)]).bytes(&m[(4 + ctx_len) ..]);
|
|
|
|
|
t.proto_name(b"Schnorr-sig");
|
|
|
|
|
let convert =
|
|
|
|
|
|point: &RistrettoPoint| PublicKey::from_bytes(&point.to_bytes()).unwrap().into_compressed();
|
|
|
|
|
t.commit_point(b"sign:pk", &convert(A));
|
|
|
|
|
t.commit_point(b"sign:R", &convert(R));
|
|
|
|
|
Scalar::from_repr(t.challenge_scalar(b"sign:c").to_bytes()).unwrap()
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/// FROST Schnorrkel algorithm.
|
|
|
|
|
#[derive(Clone)]
|
|
|
|
|
pub struct Schnorrkel {
|
|
|
|
|
context: &'static [u8],
|
|
|
|
|
schnorr: Schnorr<Ristretto, MerlinTranscript, SchnorrkelHram>,
|
|
|
|
|
msg: Option<Vec<u8>>,
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
impl Schnorrkel {
|
|
|
|
|
/// Create a new algorithm with the specified context.
|
2023-04-24 23:49:06 -04:00
|
|
|
///
|
|
|
|
|
/// If the context is greater than or equal to 4 GB in size, this will panic.
|
2023-04-10 06:05:17 -04:00
|
|
|
pub fn new(context: &'static [u8]) -> Schnorrkel {
|
|
|
|
|
Schnorrkel {
|
|
|
|
|
context,
|
|
|
|
|
schnorr: Schnorr::new(MerlinTranscript::new(b"FROST Schnorrkel")),
|
|
|
|
|
msg: None,
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
impl Algorithm<Ristretto> for Schnorrkel {
|
|
|
|
|
type Transcript = MerlinTranscript;
|
|
|
|
|
type Addendum = ();
|
|
|
|
|
type Signature = Signature;
|
|
|
|
|
|
|
|
|
|
fn transcript(&mut self) -> &mut Self::Transcript {
|
|
|
|
|
self.schnorr.transcript()
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
fn nonces(&self) -> Vec<Vec<<Ristretto as WrappedGroup>::G>> {
|
2023-04-10 06:05:17 -04:00
|
|
|
self.schnorr.nonces()
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
fn preprocess_addendum<R: RngCore + CryptoRng>(
|
|
|
|
|
&mut self,
|
|
|
|
|
_: &mut R,
|
|
|
|
|
_: &ThresholdKeys<Ristretto>,
|
|
|
|
|
) {
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
fn read_addendum<R: Read>(&self, _: &mut R) -> io::Result<Self::Addendum> {
|
|
|
|
|
Ok(())
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
fn process_addendum(
|
|
|
|
|
&mut self,
|
|
|
|
|
_: &ThresholdView<Ristretto>,
|
|
|
|
|
_: Participant,
|
2023-12-16 20:54:24 -05:00
|
|
|
(): (),
|
2023-04-10 06:05:17 -04:00
|
|
|
) -> Result<(), FrostError> {
|
|
|
|
|
Ok(())
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
fn sign_share(
|
|
|
|
|
&mut self,
|
|
|
|
|
params: &ThresholdView<Ristretto>,
|
|
|
|
|
nonce_sums: &[Vec<RistrettoPoint>],
|
|
|
|
|
nonces: Vec<Zeroizing<Scalar>>,
|
|
|
|
|
msg: &[u8],
|
|
|
|
|
) -> Scalar {
|
|
|
|
|
self.msg = Some(msg.to_vec());
|
|
|
|
|
self.schnorr.sign_share(
|
|
|
|
|
params,
|
|
|
|
|
nonce_sums,
|
|
|
|
|
nonces,
|
|
|
|
|
&[
|
|
|
|
|
&u32::try_from(self.context.len()).expect("context exceeded 2^32 bytes").to_le_bytes(),
|
|
|
|
|
self.context,
|
|
|
|
|
msg,
|
|
|
|
|
]
|
|
|
|
|
.concat(),
|
|
|
|
|
)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
fn verify(
|
|
|
|
|
&self,
|
|
|
|
|
group_key: RistrettoPoint,
|
|
|
|
|
nonces: &[Vec<RistrettoPoint>],
|
|
|
|
|
sum: Scalar,
|
|
|
|
|
) -> Option<Self::Signature> {
|
|
|
|
|
let mut sig = (SchnorrSignature::<Ristretto> { R: nonces[0][0], s: sum }).serialize();
|
|
|
|
|
sig[63] |= 1 << 7;
|
|
|
|
|
Some(Signature::from_bytes(&sig).unwrap()).filter(|sig| {
|
|
|
|
|
PublicKey::from_bytes(&group_key.to_bytes())
|
|
|
|
|
.unwrap()
|
|
|
|
|
.verify(&mut signing_context(self.context).bytes(self.msg.as_ref().unwrap()), sig)
|
|
|
|
|
.is_ok()
|
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
fn verify_share(
|
|
|
|
|
&self,
|
|
|
|
|
verification_share: RistrettoPoint,
|
|
|
|
|
nonces: &[Vec<RistrettoPoint>],
|
|
|
|
|
share: Scalar,
|
|
|
|
|
) -> Result<Vec<(Scalar, RistrettoPoint)>, ()> {
|
|
|
|
|
self.schnorr.verify_share(verification_share, nonces, share)
|
|
|
|
|
}
|
|
|
|
|
}
|