We do not currently force the VRF pre-output to lie in the prime order subgroup, but instead ask users call VRFInOut::make_ methods. In schnorrkel, if users missues the VRF pre-outout ala paritytech/substrate#5785 then they only loose the random oracle assumption or whatever, but here our cofactor creates a real exploit. We should maybe fix this by force the VRF pre-output to lie in the prime order subgroup.
I think this approach works cleanly:
dleq_proove: multiply R and Hr by the cofactor before hashing,dleq_verify: multiply c and s by the cofactor so that R and Hr get multiplied by the cofactorshorten_dleq and vrf_verify_batch: multiply R and Hr by the cofactor directly
We could however only push Hr and c * pk into the prime order subgroup, and avoid doing so for R, which marginally speeds up verification and might improve something somehow.
I'd rather address some zcash issues first though, so that vrf_verify_batch works and tests work for it and shorten_dleq.
We do not currently force the VRF pre-output to lie in the prime order subgroup, but instead ask users call
VRFInOut::make_methods. In schnorrkel, if users missues the VRF pre-outout ala paritytech/substrate#5785 then they only loose the random oracle assumption or whatever, but here our cofactor creates a real exploit. We should maybe fix this by force the VRF pre-output to lie in the prime order subgroup.I think this approach works cleanly:
dleq_proove: multiplyRandHrby the cofactor before hashing,dleq_verify: multiplycandsby the cofactor so thatRandHrget multiplied by the cofactorshorten_dleqandvrf_verify_batch: multiplyRandHrby the cofactor directlyWe could however only push
Hrandc * pkinto the prime order subgroup, and avoid doing so forR, which marginally speeds up verification and might improve something somehow.I'd rather address some zcash issues first though, so that
vrf_verify_batchworks and tests work for it andshorten_dleq.