Resistance against timing attacks

[mkaihara]

Do we need to make the field arithmetic resistant to timing attacks? For example, removing the final conditional branch in the Montgomery multiplication or making the computation of the modular inversion constant? Can an adversary take advantage of these attacks to break the security of the system?

[burdges]

I'd focus on the jubjubs before worrying about the pairing friendly curves, not sure if zcash's jubjub is constant time. Also see https://github.com/zkcrypto/bls12_381/

[UlrichHaboeck75]

I agree with @burdges, we first should focus on constant time twisted Edwards arithmetics (and all that is then needed for field arithmetics). For any primitive based on a pairing-friendly curve (except the pairing evaluation itself) we can always transform to Edwards, avoiding the pitfalls of affine Weierstrass arithmetics.

[95DDB]

Also all binary exponentiation functions for field elements (like pow()) and elliptic curve points (like mul_bits()) which branches conditionally based on the current bit value of the exponent being iterated over. This conditional branch will incur different computational load based on the exponent value. For certain use cases, and under certain conditions, this timing leak may be observed by an attacker and used to recover the exponent. While we added a disclaimer for each of these functions, would be nice to implement an efficient-constant time variant for them, maybe to be enabled using a compilation feature.