Use a conditional move of the same kind we use for the affine points in the storage type instead of multiplying with the infinity flag and adding. This results in fewer constructions to worry about for sidechannel behavior.
It also might be faster: It doesn’t appear to benchmark as slower for me at least; but I think the CMOV is faster than the mul_int + add, but slower than the set+add; making it a wash.
Use a conditional move of the same kind we use for the affine points
in the storage type instead of multiplying with the infinity flag
and adding. This results in fewer constructions to worry about for
sidechannel behavior.
It also might be faster: It doesn't appear to benchmark as slower for
me at least; but I think the CMOV is faster than the mul_int + add,
but slower than the set+add; making it a wash.
I also tried adding a fe_add_int (e.g. r[0]+=a;) that made do strictly no more work, but I couldn’t benchmark it as any faster; and it didn’t seem worth the additional code to review. … but inlined it should save a fair chunk of code size (one instruction vs … many). @sipa if you want I can post the trivial code for that.
[I was specifically looking at what code paths touched the affine x,y to figure out if it would be valuable for a ‘small table’ implementation running on a platform with magnitude dependent multipliers to have a specially computed Z (using the effective-affine style isomorphism) to achieve a property where all the entries in the table had all the words in their field have the same log(2). ]
