Proposed fixe (after internal discussion with @gubsheep and semaphore team):
Take $\mod l$ on top of existing implementation. This ensures that the same public key is generated for the same input to the fn.
ignore below (keeping here for history):
Previous proposed fix:
So the private key derived has to be right shifted by at least 5 bits to get to 251 bits. Even then there's a very low non-zero chance that the key may be >= l.
(2^251-1) - r is 7.824... . So shift the key by 6 bits if you want to avoid this too. Else, you can shift it by 5 bits, and subtract 8 to get it in range.
so
lis of 251 bits (as used in eip-2494) (rin geometry's report; to be linked). The right shift by 3 bits make the private key outside this range.https://github.com/privacy-scaling-explorations/zk-kit/blob/ce826a9f754d8efa39993647f066dbec1d2b5093/packages/eddsa-poseidon/src/eddsa-poseidon.ts#L56
Proposed fixe (after internal discussion with @gubsheep and semaphore team):
ignore below (keeping here for history): Previous proposed fix:
So the private key derived has to be right shifted by at least 5 bits to get to 251 bits. Even then there's a very low non-zero chance that the key may be >=
l.(2^251-1) - r is 7.824... . So shift the key by 6 bits if you want to avoid this too. Else, you can shift it by 5 bits, and subtract 8 to get it in range.