The original idea of `Width` was that we'd support operatings that
worked on multiple same-width but different-modulus values, and/or
we'd support splitting a 2N-limb `BoxedLimb` into two N-limb
`&[Limb]`, etc. However, as things are now, `Width` doesn't really
serve a useful purpose.
When we added `rsa::PublicKey` we changed the `ring::signature` RSA
implementation to construct an `rsa::PublicKey` and then verify the
signature using it. Unfortunately for backward compatibility with old
uses of `RsaKeyPair`, `rsa::PublicKey` constructor constructs (and
allocates) a copy of the ASN.1-serialized public key. This is not
acceptable for users who are using `ring::signature` to verify a
single signature. Refactor `PublicKey` so that it can be bypassed
by the `ring::signature` implementation.
This is a step towards implementing allocation-free RSA signature
verification.
For now, just put `#[allow(...)]` directives in the places where the
conversions are done. We'll follow up in the future with the correct
replacement for `as` for each case, as several PRs.
When I generated these test vectors, I gave all of them the same point: the
generator of the curve. Consequently these input files are 100% redundant
with the `point_mul_base.txt` input files. So just remove them and use the
`point_mul_base.txt` files instead.
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.
When `elem_exp_consttime` replaced `BN_mod_exp_mont_consttime` I did
not fully understand the way the table was constructed in the original
function. Recent BoringSSL changes clarify the table construction. Do
it the same way, to restore performance to what it was previously.
This addresses the `// TODO: Optimize this to avoid gathering`.
When this code was written, it wasn't clear which assembly language
functions took a pointer to the entire state vs. just a pointer to
the accumulator (etc.). Now upstream clarified things and we can
clarify this code.
The current macro initializer is not uniform across architectures,
and doesn't work when the number of 64bit limbs is not exactly half
that of 32bit limbs, (i.e. 521 bit).
This change replaces all limbs! initializers with a new const
function with hex string initializers, which is more portable and
more ergonomic.
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.
Don't warn during `cargo build` or `cargo test`, but deny them
in `mk/clippy.sh` so that they are caught in CI. Limit `cargo build`
warnings to things that matter during the edit/test cycle.
In particular, eliminate the use of `ArrayEncoding::as_byte_array` as
we work towards removing that function because it uses `unsafe`.
Where `Block` is used in parameters to C/assembly code, I verified that
the C/assembly code uses `uint8_t *` as the function type (meaning
`uint8_t[16]`) in the BoringSSL headers. Until recently the stuff in
GCM was using `uint64_t` or a union containing `uint64_t`, which is why
block was previously defined in terms of `BigEndian<u64>`.
This is a step towards eliminating `unsafe` usage in `ring::endian` by
eliminating one use of `ArrayEncoding::as_byte_array`.
Since this is the only usage of `LittleEndian`, it is removed
completely.
This simple `array_flatten` polyfill will be useful for multiple
improvements towards eliminating the unsafe code in `endian`.
