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.
Define the input data structures for the integrated assembly almost exactly
like BoringSSL does, except for the caveat mentioned in the comments.
Similarly, define the output type as a structure containing a byte array, like
BoringSSL, again with the caveats mentioned in the comments.
Abstract the union types into a single parameterized type.
Unwrap the ChaCha20 key earlier so we can use stronger types in the code that calls into
the integrated assembly. Either way we do the unwrapping in two places, but this way we
do it earlier.
The original version avoided `unsafe` but doesn't work for older
versions of Rust that we're still trying to support. Switch to the
`unsafe` implementation that works everywhere.
In the future we may exposes the `chacha` module publicly and then it
would be wrong for the `Key` type to implement `as_ref()` as that would
then expose the key material outside the module.
The original version avoided `unsafe` but doesn't work for older
versions of Rust that we're still trying to support. Switch to the
`unsafe` implementation that works everywhere.
Current:
Did 2916000 ChaCha20-Poly1305 (16 bytes) seal operations in 1015000us (2872906.4 ops/sec): 46.0 MB/s
Did 1604750 ChaCha20-Poly1305 (256 bytes) seal operations in 1016000us (1579478.3 ops/sec): 404.3 MB/s
Did 516750 ChaCha20-Poly1305 (1350 bytes) seal operations in 1015000us (509113.3 ops/sec): 687.3 MB/s
Did 99750 ChaCha20-Poly1305 (8192 bytes) seal operations in 1016000us (98179.1 ops/sec): 804.3 MB/s
Did 50500 ChaCha20-Poly1305 (16384 bytes) seal operations in 1016000us (49704.7 ops/sec): 814.4 MB/s
With fix:
Did 6366750 ChaCha20-Poly1305 (16 bytes) seal operations in 1016000us (6266486.2 ops/sec): 100.3 MB/s
Did 3938000 ChaCha20-Poly1305 (256 bytes) seal operations in 1016000us (3875984.3 ops/sec): 992.3 MB/s
Did 1207750 ChaCha20-Poly1305 (1350 bytes) seal operations in 1015000us (1189901.5 ops/sec): 1606.4 MB/s
Did 258500 ChaCha20-Poly1305 (8192 bytes) seal operations in 1016000us (254429.1 ops/sec): 2084.3 MB/s
Did 131500 ChaCha20-Poly1305 (16384 bytes) seal operations in 1016000us (129429.1 ops/sec): 2120.6 MB/s
Change-Id: Iec6417b9855b9d3d1d5154c93a370f80f219c65f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44347
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
If using precompiled headers then this is needed otherwise bn/internal.h
doesn't have a definition for BN_ULONG etc.
Change-Id: I41b331465abae7108f255722a156d2ffb3016ba3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44604
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
This involves adding a new function |DH_compute_key_hashed| that
combines the FFDH with the output hashing inside the FIPS module. This
new function uses the padded FFDH output, as newly specified in SP
800-56Ar3.
Change-Id: Iafcb7e276f16d39bf7d25d3b2f163b5cd6f67883
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44504
Reviewed-by: David Benjamin <davidben@google.com>
This change also drops ex_data from DH objects. The global would need
special handling in the FIPS module, which isn't hard, but just dropping
it saves some of the code-size costs of this change and I cannot find
any signs of use of this functionality.
Change-Id: I984bd70698c2ec329f340d294b3b9ec169cd0c4e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44524
Reviewed-by: David Benjamin <davidben@google.com>
Imported from upstream's 617b49db14fa4c1211bfc5d0e88294d0f159c9a9.
Change-Id: I64349b7cbbda8fbacf1e20ca609081ed42f10550
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44565
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
As of
https://chromium-review.googlesource.com/c/chromium/tools/build/+/2586225,
we no longer test on Yasm. Yasm hasn't seen a release for over six years
now and is missing support for newer x86 instructions.
This removes the remnants of support for Yasm on the CI. It also removes
the Yasm support we patched into x86nasm.pl, which removes a now
unnecessary divergence from upstream.
Update-Note: If a x86 Windows asm build breaks, switch from Yasm to
NASM. We're also no longer testing NASM on x86_64 Windows, but there
wasn't any patch to revert.
Change-Id: I016bad8757fcc13240db9f56dd622be518e649d7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44564
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Rather than the FIPS module actively collecting entropy from the CPU or
OS, this change configures Android FIPS to passively receive entropy.
See FIPS IG 7.14 section two.
Change-Id: Ibfc5c5042e560718474b89970199d35b67c21296
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44305
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
This should fix the Chromium roll.
Windows shared library builds are fussy about dllexport vs. dllimport in
a way that's incompatible with external uses of the asn1t.h macros. The
issue is the DECLARE_* macros will add dllexport vs. dllimport on the
assumption the symbols are defined in libcrypto, but external
definitions need a different selector.
Rather than add more complex macros for this, just exclude those tests.
Ideally we wouldn't supoport asn1t.h outside the library at all, if we
can manage it, so no sense in trying to make it work.
This excludes both the new and the old tests. Although this has been
working thus far, it only works because we've been setting the
BORINGSSL_IMPLEMENTATION symbol for test targets wrong in Chromium. I'm
confused how that's been working at all (maybe dllexport vs. dllimport
is more lax when it comes to functions rather than variables?), but when
I do it correctly, the ASN1_LINKED_LIST template breaks too.
Change-Id: I391edba1748f66c383ed55a9d23053674bbb876e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44484
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
8846533744 added a “power-on” test for the TLS KDF, but omitted to add
it to the documented list of these tests.
Change-Id: I13dbad4b9359e7dae0938d02ac53e5e011f50824
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44505
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
