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.
Align with the other use of `OPENSSL_memcpy` in `curve25519_64_adx.h`.
`string.h` will no longer be needed.
Signed-off-by: Jiaqi Gao <jiaqi.gao@intel.com>
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.
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).
When this benchmark was imported from crypto-bench to *ring* and
ported from the libtest `#[bench]` framework to Criterion.rs, we
kept the macro-based structure from the original benchmarks. However,
Criterion.rs actually supports the kind of parameterized benchmarking
we do much more naturally, and so we don't need the macros. Get rid of
them.
Also remove distinction between TLS 1.2 and TLS 1.3 AAD. These
benchmarks were originally written long ago when the TLS 1.3 draft
specified a different AAD format.
I hope this will serve as a better example of how to write such
benchmarks than it previously did.
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.
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.
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).
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.
