Take a step towards having RSA keys support encryption/decryption
in addition to signing/verification.
No functional changes are intended.
Some documentation was moved around.
0.17.0-alpha.9 was released off the b/0.17.0-alpha.9 branch. Similarly for
0.17.0-alpha.10 on the b/0.17.0-alpha.10 branch.
Having the version number on the main branch say "0.17.0-alpha.9" or any
version number like that is confusing and misleading. We have to have a
version number, so use one that's clearer while we work on finishing
0.17.0.
Now "links" in Cargo.toml is the only thing that needs to be manually modified
when the prefix changes.
build.rs enforces that the package name and version are consistent with the
"links" field.
Eliminate the extra Cargo.toml that was used just for this feature. It was
too error-prone to keep it in sync with the real Cargo.toml. Having one
Cargo.toml will allow us to reliably use the `CARGO_MANIFEST_LINKS` value
to keep the symbol prefix in sync with the `links` field in Cargo.toml in
the near future.
Revert the names used in the BoringSSL C/asm code to the names used in
BoringSSL. This substantially reduces the diff between *ring* and
BoringSSL for these files.
Use a variant of BoringSSL's symbol prefixing machinery to semi-
automatically prefix FFI symbols with the `GFp_` prefix. The names aren't
all exactly the same as before, because previously we *replaced* a
symbol's original prefix with the `GFp_` prefix; now we're prepending
`GFp_`. In the future we'll use a different prefix entirely.
This paves the way for using different prefixes for each version so that
multiple versions of *ring* can be linked into an executable at once.
Use Fiat Crypto for non-x86_64 platforms, like BoringSSL. Continue
using the nistz256 code on Windows, differently from BoringSSL.
Make *ring* more consistent with BoringSSL.
Ensure we're always passing in u32-aligned values to `GFp_ChaCha20_ctr32`.
Get rid of the attempt to abstract away the difference between ChaCha20
and AES-CTR w.r.t. counters and IVs. The abstraction wasn't actually used
by any shared code. The AES-CTR (GCM) code does endian conversion in the
assembly so endian conversion cannot easily be deferred to later. For
ChaCha20, it makes more sense to do endian conversion at the time of
`Counter`/`Iv` construction. Despite the slight duplication of logic in
having two `Counter` types and two `Iv` types, this is actually a net
reduction of code. If we ever have a third implementation of these types
we can apply the Rule of Three to factor out the commonality.
Clarify that, on ARM/Aarch64, runtime feature detection is done only for Linux (including
Android) and Fuchsia. Reduce some of the duplication between Linux and Fuchsia; probably we should
do more later.
Previously the OpenSSL implementation was being used. Switch to the BoringSSL
version.
Switching to the BoringSSL implementation will make it easier to refactor the CPU feature
detection, which is important for upcoming ports.
This switch will also implicitly add support for BTI and pointer authentication for
Poly1305.
This is based on BoringSSL 63d06626d3a104868eee622e8e56d9f2dd643366.
Replace `GFp_bn_mul_add_word` with a clearer, simpler implementation.
The new `GFp_limbs_mul_add_limb` avoid explicit branches at the C code
level, unlike the code it replaces. (Obviously, even with the new
"branchless" code the compiler might be able to synthesize branches.)
Add the BoringSSL aes_nohw implementation with minimal changes needed to
build. Enable the AES-GCM AEAD tests for wasm32 targets gated on the "wasm_c"
feature.
