Closed burdges closed 4 years ago
We've one call to witness_scalar in each of cert.rs, musig.rs, sign.rs, and vrf.rs. Yet, the VRF one uses the result a couple times, which prevents encapsulation outside these signing methods.
We should probably wait for const generics to stabalize, and for smallvec to adopt const generics, so that we can do
trait SigningTranscript {
...
fn witness_scalars<const N: usize>(
&self,
label: &'static [u8],
nonce_seeds: &[&[u8]],
) -> [Scalar; N]
{
let bytes = &mut [0u8; 64*N];
self.witness_bytes(label, bytes, nonce_seeds);
bytes.chunks(64)
.map( |b| Scalar::from_bytes_mod_order_wide(array_ref![&b,0,64]) )
.collect::<SmallVec::<[Scalar; N]>>()
.into_inner().unwrap()
}
}
I'll close this but there are DJB's comments cited in https://minerva.crocs.fi.muni.cz/ which sound interesting: We do mod the group order more than an ed25519 implementation, but we're doing so with extra wid scalaars
We've almost complete confidence in curve25519-dalek being constant-time thanks to arithmetic designed by DJB and Tanja Lange and careful implementations, but..
There are increasing worries now ala https://minerva.crocs.fi.muni.cz/ so we should maybe do split nonce generation, which double's signing time, but improves resistance. We could even split across signing operations, ala https://github.com/w3f/bls/issues/3 but likely using a
static mut Option<(Scalar,RistrettoPoint)>
We could confine all nonce generation to contest.rs to make nonce splitting configurable.