This should make side-channel attacks much more difficult. However,
1. Timing of bn_inverse, which is used in point_add depends on input.
2. Timing of reading secp256k1_cp may depend on input due to cache.
3. The conditions in point_add are not timing attack safe.
However point_add is always a straight addition, never double or some
other special case.
In the long run, I would like to use a specialized point_add using Jacobian
representation plus a randomization when converting the first point to
Jacobian representation. The Jacobian representation would also make
the procedure a bit faster.
The new method needs about 30 % less time for prime256k1 and is about
twice as fast for other moduli. The base algorithm is the same.
The code is also a bit smaller and doesn't need the 8 kb precomputed
table.
Important canges:
1. even/odd distinction so that we need to test only one of the numbers
for being even. This also leads to less duplicated code.
2. Allow for shifting by 32 bits at a time in the even test.
3. Pack u,s and v,r into the same array, which saves a bit of stack memory.
4. Don't divide by two after subtraction; this simplifies code.
5. Abort as soon as u,v are equal, instead of subtracting them.
6. Use s instead of r after the loop; no negation needed.
7. New code that divides by 2^k fast without any precomputed values.
Added invariants for bn_multiply and bn_inverse.
Explain that bn_multiply and bn_fast_mod doesn't work for
an arbitrary modulus. The modulus must be close to 2^256.
An invalid point may crash the implementation or, worse,
reveal information about the private key if used in a ECDH
context (e.g. cryptoMessageEn/Decrypt).
Therefore, check all user supplied points even if
USE_PUBKEY_VALIDATE is not set.
To improve speed, we don't check if the point lies in the
main group, since the secp256k1 curve does not have
any other subgroup.
The bridge is using https with a certificate signed for localback.net.
Use a session object (self.conn) to keep connection alive and
prevent costly ssl handshakes for every call.
Most time in signing transaction on the Trezor side is spent
in layoutProgress. This patch reduces the calls to this functions.
We also compute the progress differently, reserving 50 % for downloading
input transactions and 50 % for the signing process. This gives a
smoother experience if the input transactions are large.
