macos-11.0 is pre-production. Use macos-latest instead, to (I hope)
make macOS jobs more likely to succeed. (Presently, they frequently
fail with no logs.)
Upgrade to Xcode 12.4 in hopes that this will make things work.
Inline the implementation of the old `open_within_` function into
`LessSafeKey::open_within`. Rename the inner `open_within` function to
`open_within_`.
Implement `UnboundKey`, `OpeningKey`, and `SealingKey` in terms of
`LessSafeKey`. Ultimately those key types are restrictoins on the
interface of `LessSafeKey`. It wasn't done this way previously because
we had the idea that code that uses `BoundKey` shouldn't ever touch
`LessSafeKey`. That sounded nice in theory, but the unintended result
was that we introduced code duplication and otherwise made things harder
to understand. Continuing on the previous path would have seen us
duplicate `LessSafeKey` as `KeyInner` or something similar.
Now each bound key opening/sealing function is implemented in terms of
the same-named function in `LessSafeKey`.
Replace the old `LessSafeKey::new()` with an implementation of
`From<UnboundKey>`.
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.
Don't require a specialized implementation of field element addition for
each curve; instead share an implementation between RSA and ECC.
Refactor the code to avoid needing `elem_sum`.
Emulate the `copy_within` API so that the use of `unsafe` can be isolated
into a single place.
Remove the test for encryption into disjoint buffers. We should expose
such an API in the future, but currently we don't, so this was testing a
scenerio that would never occur. Removing this part of the test was
necessary to enable this refactoring. We'll need to bring it back when
we implement out-of-place encryption.
When the test was originally written, it was calling the assembly
function directly. Now it is calling the wrapper that works around the
problem, so we can verify that the workaround works.
The code had this comment:
```
/// XXX: Although this takes an `Iv`, this actually uses it like a
/// `Counter`.
```
With the recent refactorings we can fix the type to be `&Counter`. Further
we can get rid of `CounterOrIv`.
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.
This will let us simplify `aead::block`.
The previous implementation of `poly1305_update_padded_16` was optimized for
the API of the earlier Poly1305 implementation, and was duplicating some
I-U-F logic from the current Poly1305 implementation. Simplify it to avoid
that duplication.
Many (most?) KDFs are infallible, so optimize for that case. If the KDF
is fallible then the result will be `Ok(Err(_))` which is messy.
This eliminates the `error_value` parameter.
