Verify that secp256k1_ge_set_gej_zinv does not operate on infinity.

[roconnor-blockstream]

a->x and a->y should not be used if the infinity flag is set.

[roconnor-blockstream]

There is a minor question as to whether the last line should be replaced with r->infinity = 0;

[real-or-random]

utACK 3233817

Setting the infinity flag: I think it's okay to keep this line. It errs on the safe side.

[roconnor-blockstream]

rebased.

[jonasnick]

a->x and a->y should not be used if the infinity flag is set.

Why exactly? x and y are cleared in ge{,j}_set_infinity.

One could argue that it's a bug to call this function with a being infinity because there's no corresponding zi. On the other hand, since the behavior is not documented one may think that zi is ignored if a is infinity. It seems like there are quite a few call sites to go through to verify that gej_zinv is guaranteed to not be called with such an a.

[roconnor-blockstream]

It certainly used to be the case that the infinity flag could be set without the coordinates being initialized at all. I have been working at eliminating these cases: e.g. 31c0f6d

As part of "defense in depth" I think we should both endeavor to both always initialize all fields of these structures (because even copying structures with uninitialized fields is questionable) while also maintaining the invariant that the coordinates are never accessed when the infinity flag is set.

To this end I want to get to a state where fe_clear will set the memory to uninitialized for the purposes of valgrind, and use set_int(...,0) for those cases were were explicitly want the value to be 0.

[real-or-random]

To this end I want to get to a state where fe_clear will set the memory to uninitialized for the purposes of valgrind, and use set_int(...,0) for those cases were were explicitly want the value to be 0.

This will be b33a8e4 (and maybe the following commit in that PR for other modules).

I can take these out of #636 after this PR.

[robot-dreams]

ACK 099bad9

[real-or-random]

ACK 099bad9 I inspected all call sites, they all ensure that a is not infinity

By the way, secp256k1_ecmult_odd_multiples_table_globalz_windowa is in the wrong module. This function had been used within ecmult in the past but since 8c1c831, it is only used in ecmult_const. This also means its comment is wrong. We can fix this in another PR.