|ring::hmac::verify_with_own_key| takes a |SigningKey| instead of a
|VerificationKey|. This is more efficient than constructing a
|VerificationKey| with the same key value and then using `verify`. It
also better matches the mental model for the type of applications that
need such functionality; the need to construct two different keys with
the same value was confusing.
Also, the documentation now more clearly explains how to use the HMAC
API for the three different use cases I could think of today.
The use of `u8` comes from when the structure had to be binary
compatible with BoringSSL's C structure. That's no longer the case.
This change allows us to remove the last remaining uses of Rust's
dangerous `as` operator.
Having the constant-time utilities in |ring::ffi| is misleading as
|use ring::ffi| gives the impression that a module was using the FFI
when really it is FFI-free. |ring::hmac| and |ring::pbkdf2| are
examples of that.
At some point, |ring::constant_time| may be added to the public API,
but for now it is private.
The libc crate is full of badness and we need almost none of it. We
don't want to use the C standard library at all from Rust and we
definitely don't want to force users of *ring* to have to link to the
C standard library. (The C code inherited from BoringSSL depends on the
C standard library, but we've removed a lot of those dependencies and
we'll continue to do so.)
Also the definition of |libc::size_t| as an alias for a type that isn't
implicitly convertable to |usize| was forcing us to do a lot of
unnecessary casting, which is inherently danger-prone and thus
dangerous.
Until Rust 1.4, rustc will warn when `usize` or `isize` is used in an
FFI declaration. This patch silences those warnings so that *ring* can
compile without warnings with rustc 1.3 (the current stable version).
This workaround will be reverted when Rust 1.4 is released.
The code doesn't actually trigger this warning yet, but the next commit
would have made it do so.
The tests in crypto/cipher/test/chacha20_poly1305_deprecated_tests.txt
were adapted to the RFC 7539 AEAD construction by recalculating the tags.
Also a few additional vectors were added. These vectors were verified
against nettle. See
feb7292bf1.
Change the implementation of the C AEAD interface to enforce the
requirement that the nonce length is equal to the result of
|EVP_AEAD_nonce_length| for all AEADs. Previously, the requirement was
not enforced for AES-GCM cipher suites. This in turn enforces that the
input nonces for |open_in_place| and |seal_in_place| are equal to
|ring::aead::Algorithm::nonce_len|.
An issue was filed to remove the underlying code that supports oddball
nonce lengths in the AES-GCM code:
https://github.com/briansmith/ring/issues/22.
In order to move the enforcement of the nonce length to the common code
paths shared by all AEADs, the interface for the AES key wrap AEADs
(currently only available through the C API, not the Rust API) was
changed as described in openssl/include/aead.h.
Some updates were need to keep the C version of the AEAD tests in
crypto/cipher/aead_test.cc working. In particular, the tests were
reorganized so that the tests for |EVP_AEAD_CTX_open| don't depend on
the output of |EVP_AEAD_CTX_seal|, since |EVP_AEAD_CTX_seal| won't
succeed when an invalid nonce is given to it, but we need the test to
keep on going so that we can verify that |EVP_AEAD_CTX_open| also
rejects the invalid nonce. In turn, because we changed the
interpretation of the FAILS attribute in these tests, the old logic
that supported the tests for the removed-in-*ring* stateful AEADs
was removed.
Also, don't allow values to be omitted; instead require empty values to
be given as empty quoted strings.
This also removes some debugging println! calls that were accidentally
left in.
The previous interface supported only the role that receives its peer's
public key point before it has to send its own public key point. The
new interface supports both roles, symmetrically.
Some protocols may benefit slightly performance-wise if it is possible
to use the same intermediate PRK value for multiple operations. See
https://github.com/tlswg/tls13-spec/pull/248.
Now PBKDF2-HMAC is available as `ring::pbkdf2_hmac::derive` and
`ring::pbkdf2_hmac::verify`. The former function is the new name for
the old `ring::pbkdf2_hmac` function and the new function is new,
implementing constant-time comparison of the expected and computed
derived keys.
The C function |ECDH_ephemeral| was accidentally included in commit
1dd99fe (Split |ring::signature| into |ring:ecc| and |ring::rsa|) but
it was really supposed to be part of this commit.
Ilari Liusvaara pointed out that an Init-Update-Finalize interface for
HMAC verification is generally unneeded and encourages the bad practice
of processing streams of data before the HMAC over that data has been
verified.
This commit also improves some of the documentation.
This HMAC implementation is built on top of |ring::digest| in Rust
instead of using the FFI to call into the C implementation of HMAC.
This also adds constant-time byte slice comparison to |ring::ffi|,
which is used for HMAC verification.
The previous interface suffered from multiple problems that made it
annoying to use in contexts that needed to digest data with a digest
function that wasn't known statically at build time. The old interface
was also hard to avoid uses of the heap when digest algorithm agility
is required. It was also annoying that one had to import the |Digest|
trait even in code that only wanted to use a statically-chosen digest
function, because calling a method declared in a trait requires that.
The updates to examples/checkdigest.rs demonstrate the improved
usability.
This change also moves to a new style where it is assumed that users of
*ring* will |use ring::*| and then access submodules using
partially-qualified syntax. For example, instead of naming the digest
context type |DigestContext|, it is named just |Context| with the
expectation that code will refer to it as |digest::Context|. Future
sub-modules will follow this convention so that, for example, the HMAC
context type will be |ring::hmac::Context|.
The new interface also helps establish the convention that algorithms
exposed as |pub static| values of some type, usually a struct type.
This convention help enable the linker to discard the code for unused
algorithms.
The fact that |SignatureDigestAlgorithm| is no longer needed in this
new design is a good indication that we're on a better track.
We need a PRNG function that operates on slices that aren't |Vec|, but
it isn't clear we need a function that appends to a |Vec|. The new
function is not re-exported from the main |ring| module.
