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.
This diff contains three changes.
1. Make timing isPinCorrect independent of storage.pin, to avoid timing attacks
2. Only update failed PIN counter if the user entered a PIN.
Of course, the fail counter is still incremented, before the PIN is checked.
3. Don't cache the PIN, but just the fact that the PIN was entered. The
cache should be in sync with storage.pin in any case.
