In https://moderncrypto.org/mail-archive/curves/2020/001012.html Greg Maxwell argues that nonce generation should hash all parameters that challenge generation does because signature schemes commonly input keypairs in which the public key might diverge from the secret key.
We might ideally fix this by hashing the public key earlier before computing r, but doing so breaks VRF compatibility. Instead we should hash the pk along side the nonce, which gets uglier. We should perhaps do the output point earlier too, but doing so runs into the same problems with similarly ugly fixes.
I think the risk described by Maxwell is reduced by both our derandomized+randomized nonce approach and our Keypair type and that VRFs should rarely run twice on the same input, but some small key compromise risk remains.
In https://moderncrypto.org/mail-archive/curves/2020/001012.html Greg Maxwell argues that nonce generation should hash all parameters that challenge generation does because signature schemes commonly input keypairs in which the public key might diverge from the secret key.
We take Maxwell's prefered approach for signing in https://github.com/w3f/schnorrkel/blob/master/src/sign.rs#L174 but not for VRF proofs in https://github.com/w3f/schnorrkel/blob/master/src/vrf.rs#L606
We might ideally fix this by hashing the public key earlier before computing r, but doing so breaks VRF compatibility. Instead we should hash the pk along side the nonce, which gets uglier. We should perhaps do the output point earlier too, but doing so runs into the same problems with similarly ugly fixes.
I think the risk described by Maxwell is reduced by both our derandomized+randomized nonce approach and our
Keypairtype and that VRFs should rarely run twice on the same input, but some small key compromise risk remains.