Values for P-521 have an odd number of limbs in 32-bit mode, which
means we can't keep using `TOBN`, and also Montgomery-encoded
values are different for 32-bit and 64-bit.
Generate some of the C boilerplate, particularly the large constants.
The output is written into target/curves/, and can be merged into
the actual code in crypto/fipsmodule/ec/ using a two-way merge tool;
this is the same as the Rust code generation.
Changes to gfp_p{256,384}.c are due to differences in the generator's
output:
* The generator doesn't generate trailing commas in arrays.
* The generator consistently avoids adding leading zeros to hex
constants, and consistently format values less than 10 in decimal;
the exiting code used a mix of styles.
* The generator wraps arrays consistently; the existing code used a
mix of wrapping styles.
* The generator does not nest constants in the functions that need
them. This was changed to support future refactorings.
Do it because BoringSSL does it. BoringSSL has some other headers it
includes here but we intentionally do not have them and/or we
intentionally do not include them here (string.h and assert.h).
Add a new scalar base point multiplication test case generator that
where the points are *not* Montgomery-encoded. This way we don't need
to generate different test data files when the Montgomery encoding
for a curve isn't the same for 32-bit and 64-bit targets (P-521).
This version of the generator produces the test cases for all the
scalars that the current P-256 and P-384 tests generate, in the same
format; the only exception is that the point is not
Montgomery-encoded.
Avoid using the P384_POINT type on the C side. It seems to work for all
the targets we support, for P-384, but this pattern probably doesn't
work in general. Especially due to alignment issues for 32-bit targets,
it is doubtful it would work for P-521.
Better match the Rust declarations of these functions. Prepare to
support more target platforms and more weird things (like P-521) that
by avoiding any kind of alignment assumptions at the language
boundary (or elsewhere).
Enable `ring::agreement` for wasm32 targets using the small
implementation of Curve25519.
Use the small Curve25519 implementation of Curve25519 (and
P-256) for all targets except for Aarch64 and x86-64.
Besides being smaller, the small implementations are likely
more resistant to compiler-introduced side-channels, which
is especially important for the wasm32 virtual machine and
other targets that we don't QA as thoroughly as AAarch64
and x86-64.
Bring in the previously-removed definition of `fe_mul_llt`
from BoringSSL as of commit
8d71d244c0debac4079beeb02b5802fde59b94bd.
*ring* defined a function named `OPENSSL_memcmp` that did what
`CRYPTO_memcmp` does in BoringSSL, and BoringSSL has a different
function called `OPENSSL_memcmp`. *ring* doesn't need
`OPENSSL_memcmp` so sync the `CRYPTO_memcmp` stuff with BoringSSL.
This eliminates unnecessary differences from BoringSSL.
It's probably worth explaining in a comment that this is about
implementation-defined behavior, and why we consider it okay to make
assumptions like uint8_t == unsigned char.
Change-Id: Ia35248aef7895b0998831b6bac06993e845e6297
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/63285
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Originally I was trying to be pedantic and avoid any use of `_t`-
suffixed names. However, this hasn't really accomplished anything
except annoying me, so just do what BoringSSL does.
The *ring* counterpart to `copy_from_prebuf` is `LIMBS_select_512_32`
which is already written very (too?) conservatively w.r.t. compiler-
introduced side channels. I inspected the generated code before/after
adding additional `value_barrier_w` and it made no difference.
