It shouldn't have been defined for variable-length nonces at all, but so
it goes. EVP_CIPHER rejected this by way of EVP_CTRL_GCM_SET_IVLEN
comparing <= 0, but the EVP_AEAD API did not.
I've done the test in a separate file on the assumption that aead_test
will become GTest shortly, at which point it will be easy to stick extra
tests into the same file as the FileTest ones.
Thanks to Daniel Bleichenbacher and Thanh Bui of Project Wycheproof for
the report.
Change-Id: Ic4616b39a1d7fe74a1f14fb58cccec2ce7c4f2f3
Reviewed-on: https://boringssl-review.googlesource.com/16544
Reviewed-by: Adam Langley <agl@google.com>
This introduces machinery to start embedding the test data files into
the crypto_test binary. Figuring out every CI's test data story is more
trouble than is worth it. The GTest FileTest runner is considerably
different from the old one:
- It returns void and expects failures to use the GTest EXPECT_* and
ASSERT_* macros, rather than ExpectBytesEqual. This is more monkey
work to convert, but ultimately less work to add new tests. I think
it's also valuable for our FileTest and normal test patterns to align
as much as possible. The line number is emitted via SCOPED_TRACE.
- I've intentionally omitted the Error attribute handling, since that
doesn't work very well with the new callback. This means evp_test.cc
will take a little more work to convert, but this is again to keep our
two test patterns aligned.
- The callback takes a std::function rather than a C-style void pointer.
This means we can go nuts with lambdas. It also places the path first
so clang-format doesn't go nuts.
BUG=129
Change-Id: I0d1920a342b00e64043e3ea05f5f5af57bfe77b3
Reviewed-on: https://boringssl-review.googlesource.com/16507
Reviewed-by: Adam Langley <agl@google.com>
In GTest, we'll just burn the files into the binary and not worry about
this. Apparently test files is a one of computer science's great
unsolved problems and everyone has their own special-snowflake way of
doing it. Burning them into the executable is easier.
BUG=129
Change-Id: Ib39759ed4dba6eb9ba97f0282f000739ddf931fe
Reviewed-on: https://boringssl-review.googlesource.com/16506
Reviewed-by: Adam Langley <agl@google.com>
Instead of a script which generates macros, emit static inlines in
individual header (or C files). This solves a few issues with the
original setup:
- The documentation was off. We match the documentation now.
- The stack macros did not check constness; see some of the fixes in
crypto/x509.
- Type errors did not look like usual type errors.
- Any type which participated in STACK_OF had to be made partially
public. This allows stack types to be defined an internal header or
even an individual file.
- One could not pass sk_FOO_free into something which expects a function
pointer.
Thanks to upstream's 411abf2dd37974a5baa54859c1abcd287b3c1181 for the
idea.
Change-Id: Ie5431390ccad761c17596b0e93941b0d7a68f904
Reviewed-on: https://boringssl-review.googlesource.com/16087
Reviewed-by: Adam Langley <agl@google.com>
Change-Id: I7bf485a9bfe0d7b7a3dc3081f86278fee87b8c74
Reviewed-on: https://boringssl-review.googlesource.com/16485
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Change-Id: Iab7a738a8981de7c56d1585050e78699cb876dab
Reviewed-on: https://boringssl-review.googlesource.com/16467
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This change causes FIPS mode to use RDRAND in preference to the kernel's
entropy pool. This prevents issues where the ioctl that we have to do
when getrandom isn't supported transiently reports that the pool is
“empty” and causes us to block.
Change-Id: Iad50e443d88b168bf0b85fe1e91e153d79ab3703
Reviewed-on: https://boringssl-review.googlesource.com/16466
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Rather than comparing against both endpoints, subtract the minimum and
rely on unsigned wraparound to do both comparisons at once. This seems
to be slightly faster.
In addition, constant_time_lt_8 becomes much simpler if it can assume
that |a| and |b| have the same MSB. But we can arrange that by casting
up to |crypto_word_t| (which is otherwise happening anyway).
Change-Id: I82bd676e487eb7bb079ba7286df724c1c380bbb4
Reviewed-on: https://boringssl-review.googlesource.com/16445
Reviewed-by: Adam Langley <agl@google.com>
With the constant-time base64 decode, base64_ascii_to_bin is a bit more
expensive. This check is redundant with the one in base64_decode_quad,
though it does mean syntax error reporting will be slightly deferred by
four bytes.
Change-Id: I71f23ea23feba2ee5b41df79ce09026fb56996d3
Reviewed-on: https://boringssl-review.googlesource.com/16444
Reviewed-by: Adam Langley <agl@google.com>
Saves having it in several places.
Change-Id: I329e1bf4dd4a7f51396e36e2604280fcca32b58c
Reviewed-on: https://boringssl-review.googlesource.com/16026
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
AES-GCM-SIV specifies that the counter is a 32-bit, unsigned number.
These test vectors are crafted to trigger a wrap-around and ensure that
corner of the spec is implemented correctly.
Change-Id: I911482ca0b6465a7623ee1b74a6cb1d5e54ddbea
Reviewed-on: https://boringssl-review.googlesource.com/16324
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This makes things a little easier for some of our tooling.
Change-Id: Ia7e73daf0a5150b106cf9b03b10cae194cb8fc5a
Reviewed-on: https://boringssl-review.googlesource.com/15104
Reviewed-by: Matt Braithwaite <mab@google.com>
Reviewed-by: Adam Langley <agl@google.com>
43e5a26b53 removed the .file directive
from x86asm.pl. This removes the parameter from asm_init altogether. See
also upstream's e195c8a2562baef0fdcae330556ed60b1e922b0e.
Change-Id: I65761bc962d09f9210661a38ecf6df23eae8743d
Reviewed-on: https://boringssl-review.googlesource.com/16247
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
We're not using the MASM output, so don't bother maintaining a diff on
it.
Change-Id: I7321e58c8b267be91d58849927139b74cc96eddc
Reviewed-on: https://boringssl-review.googlesource.com/16246
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Due to issues with CMake enable_language, we have to delay setting
CMAKE_ASM_FLAGS until after enable_language(ASM) has been called.
We also need to remove the '.file' macro from x86gas.pl to prevent the
filenames from being overridden from those provided by the build
system.
Change-Id: I436f57ec45e4751714af49e1211a0d7810e4e56a
Reviewed-on: https://boringssl-review.googlesource.com/16127
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This allows breaking Known Answer Tests for AES-GCM, DES, SHA-1,
SHA-256, SHA-512, RSA signing and DRBG as required by FIPS.
Change-Id: I8e59698a5048656021f296195229a09ca5cd767c
Reviewed-on: https://boringssl-review.googlesource.com/16088
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
It's about time we got rid of this. As a first step, introduce a flag,
so that some consumers may stage this change in appropriately.
BUG=chromium:534766,chromium:532048
Change-Id: Id53f0bacf5bdbf85dd71d1262d9f3a9ce3c4111f
Reviewed-on: https://boringssl-review.googlesource.com/16104
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This has since been done.
Change-Id: I498f845fa4ba3d1c04a5892831be4b07f31536d4
Reviewed-on: https://boringssl-review.googlesource.com/16124
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This is needed when unrandom.c is compiled on its own.
Change-Id: Ia46e06d267c097e5fa0296092a7270a4cd0b2044
Reviewed-on: https://boringssl-review.googlesource.com/16085
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This is required by FIPS testing.
Change-Id: Ia399a0bf3d03182499c0565278a3713cebe771e3
Reviewed-on: https://boringssl-review.googlesource.com/16044
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
SHA-512 is faster to calculate on 64-bit systems and that's what we were
using before. (Though, realistically, this doesn't show up at all.)
Change-Id: Id4f386ca0b5645a863b36405eef03bc62d0f29b3
Reviewed-on: https://boringssl-review.googlesource.com/16006
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
SHA-512 is faster to calculate on 64-bit systems and we're only
targetting 64-bit systems with FIPS.
Change-Id: I5e9b8419ad4ddc72ec682c4193ffb17975d228e5
Reviewed-on: https://boringssl-review.googlesource.com/16025
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
ASAN prevents the integrity test from running, so don't indicate FIPS
mode in that case.
Change-Id: I14c79e733e53ef16f164132bc1fded871ce3f133
Reviewed-on: https://boringssl-review.googlesource.com/16024
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Perl, multiple versions, for some reason occasionally takes issue with
letter b[?] in ox([0-9a-f]+) regex. As result some constants, such as
0xb1 came out wrong when generating code for MASM. Fixes upstream
GH#3241.
(Imported from upstream's c47aea8af1e28e46e1ad5e2e7468b49fec3f4f29.)
This does not affect of the configurations we generate and is imported
to avoid a diff against upstream.
Change-Id: Iacde0ca5220c3607681fad081fbe72d8d613518f
Reviewed-on: https://boringssl-review.googlesource.com/15985
Reviewed-by: Adam Langley <agl@google.com>
This avoids depending the FIPS module on crypto/bytestring and moves
ECDSA_SIG_{new,free} into the module.
Change-Id: I7b45ef07f1140873a0da300501141b6ae272a5d9
Reviewed-on: https://boringssl-review.googlesource.com/15984
Reviewed-by: Adam Langley <agl@google.com>
This dates to ded93581f1, but we have
since switched to building with nasm, to match upstream's supported
assemblers. Since this doesn't affect anything we generate, remove the
workaround to reduce the diff against upstream.
Change-Id: I549ae97ad6d6f28836f6c9d54dcf51c518de7521
Reviewed-on: https://boringssl-review.googlesource.com/15986
Reviewed-by: Adam Langley <agl@google.com>
EVP_AEAD_CTX is otherwise a pain to use from C++ when you need to keep
it around.
Change-Id: I1dff926b33a3246680be21b89b69dfb336d25cd5
Reviewed-on: https://boringssl-review.googlesource.com/15965
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Change-Id: Icf1d6ec9d3fb33a124a9f61c75d29248a2582680
Reviewed-on: https://boringssl-review.googlesource.com/15964
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Nearly all of the assembly code was written by Shay and is submitted
under the CLA.
Change-Id: Ia70952d4ba2713ccc5e96a0952c22e5400c90f3a
Reviewed-on: https://boringssl-review.googlesource.com/15649
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
The names in the P-224 code collided with the P-256 code and thus many
of the functions and constants in the P-224 code have been prefixed.
Change-Id: I6bcd304640c539d0483d129d5eaf1702894929a8
Reviewed-on: https://boringssl-review.googlesource.com/15847
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
FIPS 186-4 wants d = e^-1 (mod lcm(p-1, q-1)), not (p-1)*(q-1).
Note this means the size of d might reveal information about p-1 and
q-1. However, we do operations with Chinese Remainder Theorem, so we
only use d (mod p-1) and d (mod q-1) as exponents. Using a minimal
totient does not affect those two values.
This removes RSA_recover_crt_params. Using a minimal d breaks (or rather
reveals an existing bug in) the function.
While I'm here, rename those ridiculous variable names.
Change-Id: Iaf623271d49cd664ba0eca24aa25a393f5666fac
Reviewed-on: https://boringssl-review.googlesource.com/15944
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Nothing is using them. For encrypt, there's generally no need to swap
out public key operations. keygen seems especially pointless as one
could just as easily call the other function directly.
The one behavior change is RSA_encrypt now gracefully detects if called
on an empty RSA, to match the other un-RSA_METHOD-ed functions which had
similar treatments. (Conscrypt was filling in the encrypt function
purely to provide a non-crashing no-op function. They leave the public
bits blank and pass their custom keys through sufficiently many layers
of Java crypto goo that it's not obvious whether this is reachable.)
We still can't take the function pointers out, but once
96bbe03dfd
trickles back into everything, we can finally prune RSA_METHOD.
Bump BORINGSSL_API_VERSION as a convenience so I can land the
corresponding removal in Conscrypt immediately.
Change-Id: Ia2ef4780a5dfcb869b224e1ff632daab8d378b2e
Reviewed-on: https://boringssl-review.googlesource.com/15864
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
(Imported from upstream's 54538204d870b97c751d13efeefa876bd792a44b.)
Change-Id: If9967b67a74ab7dea175e97ea8bda195c3cd0478
Reviewed-on: https://boringssl-review.googlesource.com/15835
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
ASN1_GENERALIZEDTIME and ASN1_UTCTIME may be specified using offsets,
even though that's not supported within certificates. [davidben: This
commit message seems off as crypto/x509 does not reject them. It merely
has a comment telling you that it's doing it wrong.]
To convert the offset time back to GMT, the offsets are supposed to be
subtracted, not added. e.g. 1759-0500 == 2359+0100 == 2259Z.
(Imported from upstream's d2335f30970ed3edc1c7c11700ab7f34396cf086.)
Change-Id: Id0d4c5b650e77db3b04b15e66b069807f6f31266
Reviewed-on: https://boringssl-review.googlesource.com/15834
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
I forgot to scrub these files when they moved and their macros are
currently leaking into other files. This isn't a problem, but does
prevent ec/ code from being moved into the module at the moment.
Change-Id: I5433fb043e90a03ae3dc5c38cb3a69563aada007
Reviewed-on: https://boringssl-review.googlesource.com/15845
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
