RT#4625

(Imported from upstream's e3057a57caf4274ea1fb074518e4714059dfcabf.)

Add a test in ec_test to cover the ecp_nistz256_points_mul change. Also
revise the low-level infinity tests to cover the changes in
ecp_nistz256_point_add. Upstream's 'infty' logic was also cleaned up to
be simpler and take advantage of the only cases where |p| is infinity.

Change-Id: Ie22de834bf79ecb6191e824ad9fc1bd6f9681b8b
Reviewed-on: https://boringssl-review.googlesource.com/12225
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>

Addition was not preserving inputs' property of being fully reduced.

Thanks to Brian Smith for reporting this.

(Imported from upstream's b62b2454fa and
d3034d31e7c04b334dd245504dd4f56e513ca115.)

See also this thread.
https://mta.openssl.org/pipermail/openssl-dev/2016-August/008179.html

Change-Id: I3731f949e2e2ef539dec656c58f1820cc09a56a6
Reviewed-on: https://boringssl-review.googlesource.com/11409
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>

This is just to reduce the diff with upstream's files so it's easier to
tell what's going on. Upstream's files have lots and lots of trailing
whitespace. We were also missing a comment.

Change-Id: Icfc3b52939823a046a3744fd8e619b5bd6160715
Reviewed-on: https://boringssl-review.googlesource.com/11408
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>

Depending on architecture, perlasm differed on which one or both of:

  perl foo.pl flavor output.S
  perl foo.pl flavor > output.S

Upstream has now unified on the first form after making a number of
changes to their files (the second does not even work for their x86
files anymore). Sync those portions of our perlasm scripts with upstream
and update CMakeLists.txt and generate_build_files.py per the new
convention.

This imports various commits like this one:
184bc45f68 (this was done by taking a
diff, so I don't have the full list)

Confirmed that generate_build_files.py sees no change.

BUG=14

Change-Id: Id2fb5b8bc2a7369d077221b5df9a6947d41f50d2
Reviewed-on: https://boringssl-review.googlesource.com/8518
Reviewed-by: Adam Langley <agl@google.com>

(Imported from upstream's 64333004a41a9f4aa587b8e5401420fb70d00687.)

RT#4284.

This case should be impossible to hit because |EC_POINT_add| doesn't use
this function and trying to add equal inputs should never occur during a
multiplication. Support for this exists because the pattern has been
copied from the first 64-bit P-224 and P-256 work that Emilia, Bodo and
I did. There it seemed like a reasonable defense-in-depth in case the
code changed in the future.

Change-Id: I7ff138669c5468b7d7a5153429bec728cb67e338
Reviewed-on: https://boringssl-review.googlesource.com/7246
Reviewed-by: David Benjamin <davidben@google.com>

Change-Id: I9d0b3fa39445d08202c67d905d2c676d5d968c33
Reviewed-on: https://boringssl-review.googlesource.com/6561
Reviewed-by: Adam Langley <agl@google.com>

This change incorporates Intel's P-256 implementation. The record of
Intel's submission under CLA is in internal bug number 25330687.

Before:
Did 3582 ECDH P-256 operations in 1049114us (3414.3 ops/sec)
Did 8525 ECDSA P-256 signing operations in 1028778us (8286.5 ops/sec)
Did 3487 ECDSA P-256 verify operations in 1008996us (3455.9 ops/sec)
build/tool/bssl is 1434704 bytes after strip -s

After:
Did 8618 ECDH P-256 operations in 1027884us (8384.2 ops/sec)
Did 21000 ECDSA P-256 signing operations in 1049490us (20009.7 ops/sec)
Did 8268 ECDSA P-256 verify operations in 1079481us (7659.2 ops/sec)
build/tool/bssl is 1567216 bytes after strip -s

Change-Id: I147971a8e19849779c8ed7e20310d41bd4962299
Reviewed-on: https://boringssl-review.googlesource.com/6371
Reviewed-by: Adam Langley <agl@google.com>