serai/crypto
Luke Parker 6fec95b1a7
3.7.2 Remove code randomizing which side odd elements end up on
This could still be gamed. For [1, 2, 3], the options were ([1], [2, 3]) or
([1, 2], [3]). This means 2 would always have the maximum round count, and
thus this is still game-able. There's no point to keeping its complexity
accordingly when the algorithm is as efficient as it is.

While a proper random could be used to satisfy 3.7.2, it'd break the
expected determinism.
2023-03-02 11:16:00 -05:00
..
ciphersuite 3.8.6 Correct transcript to scalar derivation 2023-03-02 10:04:18 -05:00
dalek-ff-group 3.5.2 Add more tests to ff-group-tests 2023-02-24 06:03:56 -05:00
dkg 3.6.9 Add several tests to the FROST library 2023-03-01 08:02:45 -05:00
dleq 3.4.a Panic if generators.len() != scalars.len() for MultiDLEqProof 2023-02-28 00:00:29 -05:00
ed448 3.5.2 Add more tests to ff-group-tests 2023-02-24 06:03:56 -05:00
ff-group-tests 3.5.2 Add more tests to ff-group-tests 2023-02-24 06:03:56 -05:00
frost 3.6.9 Add several tests to the FROST library 2023-03-01 08:02:45 -05:00
multiexp 3.7.2 Remove code randomizing which side odd elements end up on 2023-03-02 11:16:00 -05:00
schnorr 3.8.6 Correct transcript to scalar derivation 2023-03-02 10:04:18 -05:00
transcript 3.9.1 Fix SecureDigest trait bound 2023-03-02 10:57:22 -05:00