7a05466049
There's two ways which this could be tested. 1) Preprocess not taking in an arbitrary RNG item, yet the relevant bytes This would be an unsafe level of refactoring, in my opinion. 2) Test random_nonce and test the passed in RNG eventually ends up at random_nonce. This takes the latter route, both verifying random_nonce meets the vectors and that the FROST machine calls random_nonce properly. |
||
---|---|---|
.. | ||
src | ||
Cargo.toml | ||
LICENSE | ||
README.md |
Ciphersuite
Ciphersuites for elliptic curves premised on ff/group.
Secp256k1/P-256
Secp256k1 and P-256 are offered via k256 and p256, two libraries maintained by RustCrypto.
Their hash_to_F
is the
IETF's hash to curve,
yet applied to their scalar field.
Ed25519/Ristretto
Ed25519/Ristretto are offered via dalek-ff-group, an ff/group wrapper around curve25519-dalek.
Their hash_to_F
is the wide reduction of SHA2-512, as used in
RFC-8032. This is also compliant with
the draft
RFC-RISTRETTO.
The domain-separation tag is naively prefixed to the message.
Ed448
Ed448 is offered via minimal-ed448, an explicitly not recommended, unaudited, incomplete Ed448 implementation, limited to its prime-order subgroup.
Its hash_to_F
is the wide reduction of SHAKE256, with a 114-byte output, as
used in RFC-8032. The
domain-separation tag is naively prefixed to the message.