mirror of
https://github.com/serai-dex/serai.git
synced 2025-12-11 13:39:25 +00: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`.
This commit is contained in:
@@ -20,7 +20,7 @@ use ciphersuite::{
|
||||
ff::{Field, PrimeField},
|
||||
Group, GroupEncoding,
|
||||
},
|
||||
Ciphersuite,
|
||||
GroupIo,
|
||||
};
|
||||
use multiexp::{multiexp_vartime, BatchVerifier};
|
||||
|
||||
@@ -33,20 +33,20 @@ mod tests;
|
||||
|
||||
/// A Schnorr signature of the form (R, s) where s = r + cx.
|
||||
///
|
||||
/// These are intended to be strict. It is generic over Ciphersuite which is for PrimeGroups,
|
||||
/// These are intended to be strict. It is generic over `GroupIo` which is for `PrimeGroup`s,
|
||||
/// and mandates canonical encodings in its read function.
|
||||
///
|
||||
/// RFC 8032 has an alternative verification formula, 8R = 8s - 8cX, which is intended to handle
|
||||
/// torsioned nonces/public keys. Due to this library's strict requirements, such signatures will
|
||||
/// not be verifiable with this library.
|
||||
/// RFC 8032 has an alternative verification formula for Ed25519, `8R = 8s - 8cX`, which is
|
||||
/// intended to handle torsioned nonces/public keys. Due to this library's strict requirements,
|
||||
/// such signatures will not be verifiable with this library.
|
||||
#[allow(non_snake_case)]
|
||||
#[derive(Clone, Copy, PartialEq, Eq, Debug, Zeroize)]
|
||||
pub struct SchnorrSignature<C: Ciphersuite> {
|
||||
pub struct SchnorrSignature<C: GroupIo> {
|
||||
pub R: C::G,
|
||||
pub s: C::F,
|
||||
}
|
||||
|
||||
impl<C: Ciphersuite> SchnorrSignature<C> {
|
||||
impl<C: GroupIo> SchnorrSignature<C> {
|
||||
/// Read a SchnorrSignature from something implementing Read.
|
||||
pub fn read<R: Read>(reader: &mut R) -> io::Result<Self> {
|
||||
Ok(SchnorrSignature { R: C::read_G(reader)?, s: C::read_F(reader)? })
|
||||
|
||||
Reference in New Issue
Block a user