X509 objects do some deferred parsing. Make sure we cover that code with
fuzzers.
Change-Id: I618e90aaf4d8decbc3af59f36910feb9949a8cd2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55751
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
X509_policy_check returns -1 if some certificate had an unparseable
extension, in which case it sets EXFLAG_INVALID_POLICY on it. The
calling code then iterates over the certificates to find the offending
one, so the callback has a chance to undo it. But it skips i = 0, the
leaf, and instead just silentely returns success.
We really should cut down on the callback's ability to mess things up
here but, in the meantime, fix this. Also add a test covering this case.
While I'm here, I've updated make_invalid_extensions.go, which I pulled
some code from, to rename fooOrPanic to mustFoo. That seems to be the
convention in the Go standard library. (regexp.MustCompile, etc.)
Change-Id: Ib07c9f4175e66483bd7c0f7d49aea931bf36e53f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55748
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
I inadvertently removed it, but set_string(NULL, str) would validate str
without writing an object. OpenSSL's habit of dual-use functions isn't
great (this behavior masked a bug in another project), but I apparently
even documented it in the header, so restore the behavior.
Change-Id: I8b4dbe5a2b21eb59cb20e4c845b17761329b34a1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55785
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
That loop is just sk_ASN1_OBJECT_deep_copy.
Change-Id: Idc9db7f8e0ac28c853415813f49b1441b646c246
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55746
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
X509 verification currently lazily fills in some fields on a lock. Test
that it works correctly. Confirmed that TSan can catch data races
intentionally patched into v3_purp.c.
Change-Id: Ia0e8d81bb6ba4b9ade1a47edcb48404902f4ae8c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55745
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
We already tell people not to use these APIs, but some do anyway. Those
that do should be warned about the streaming implications.
Change-Id: I67a9e1bb94aec2217b7c53849ec676b1c3dddb3c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55392
Reviewed-by: Bob Beck <bbe@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
See the update to ACVP.md for documentation but this now allows running
a test to be broken down into separate commands for each step: fetching,
processing, and uploading.
Change-Id: Id86d1cd0b07fcc9bdc6c665072b511da0832bdde
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55608
Reviewed-by: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
The public API already expects them to be uint32_t. Fix the internals to
match.
Bug: 516
Change-Id: Ia683cc2fac559ebe0b3c7045e4db551224677c28
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55706
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
First, rename to x509v3_conf_name_matches and flip the result value. We
don't need to preserve the positive vs negative return of strncmp here.
The rename is because "name" can mean so many things in the context of
X.509. Here, it's specifically the name of a CONF_VALUE.
Finally, fix it to be size_t-clean.
Bug: 516
Change-Id: I1c3039d9c6ce70cde669e07f943ad1e25fb49dc1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55705
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
The buffer length is int, so the output also fits in int.
Bug: 516
Change-Id: I8e59a2109f38c81ac58f1a8f1e7d739c8b0d1c7c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55707
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Change-Id: I7fdc63786654f488b2502d6e9c3fb535a2766574
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55605
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
X509_NAME_add_entry_by_txt and friends all use int for MBSTRING_*
constants. X509V3_NAME_from_section was the odd one out in using
unsigned long.
Bug: 516
Change-Id: Ib0bca46a080a791d2fba0b515a47b047c0777260
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55456
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
They're the only two half-finished ports left, so we may as well finish
that up and trim them down a little.
Change-Id: Ic058124a44086161ab5d2d6fa24448492c3ba219
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55506
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Plan is:
1. This CL
2. Update the CI/CQ recipe to be able to run this
3. Update the CI/CQ config to enable this on ELF platforms
4. Do not land, but patch out the .note.GNU-stack annotations and
-Wa,--noexecstack and confirm CI/CQ fails. Based on manual testing
and https://crbug.com/boringssl/292#c4, I anticipate we'll only have
coverage on x86 and x86_64 Linux. Currently, our only Arm Linux
builders are Android, which use the LLVM linker. The LLVM linker
doesn't have this design flaw, so it doesn't need .note.GNU-stack in
the first place. It also sounds like GNU ld will make this moot in a
future release.
5. Remove -Wa,--noexecstack from crypto/CMakeLists.txt and confirm CI/CQ
still passes.
Other than generally wanting to test things, the immediate motivation is
https://boringssl-review.googlesource.com/c/boringssl/+/55626/1/crypto/perlasm/arm-xlate.pl#b246
Bug: 292
Change-Id: Id1c049bfc2b4e8b7e2c8c32ea6456733a588dfe1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55645
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Disable blinding for boringssl_self_test_rsa() to avoid an entropy draw like
the 'k' value for ECDSA is fixed to avoid an entropy draw in boringssl_self_test_ecc().
The boringssl_self_test_rsa() use entropy to generate the blinding factor and
the inverse of blinding factor. Running boringssl_self_test_rsa() from init stage of OS
on some devices as the kernel's entropy pool is not yet initialized, causing the process
to block for seconds.
Bug: None
Change-Id: I4c1119c9950553eec030bedf36ec22ab41088f20
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55545
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
For the C files, rather than force the caller to juggle
crypto_linux_sources, etc., we just wrap the whole file in ifdefs and
ask the callers to link everything together.
Assembly is typically built by a different tool, so we have less room
here. However, there are really only two families of tools we care
about: gas (which runs the C preprocessor) and nasm (which has its own
preprocessor). Callers should be able to limit themselves to
special-casing Windows x86(_64) for NASM and then pass all the remaining
assembly files to their gas-like tool. File-wide ifdefs can take care of
the rest.
We're almost set up to allow this, except the files condition on
architecture, but not OS. Add __ELF__, __APPLE__, and _WIN32 conditions
as appropriate.
One subtlety: the semantics of .note.GNU-stack are that *any* unmarked
object file makes the stack executable. (In current GNU ld. lld doesn't
have this issue, and GNU ld claims they'll remove it in a later
release.) Empirically, this doesn't seem to apply to empty object files
but, to be safe, we should ensure all object files have the marking.
That leads to a second subtlety: on targets where @ is a comment,
@progbits is spelled %progbits, per [0]. If we want all .S files to work
in all targets, that includes these markers. Fortunately, %progbits
appears to work universally (see [1], [2], [3], [4]), so I've just
switched us to that spelling.
I've also tightened up the __arm__ and __aarch64__ checks to __ARMEL__
and __AARCH64EL__. We don't support big-endian Arm (or any other
platform) and, even if we did, the conditions in the assembly files
should match the conditions in the C files that pull them in.
This CL doesn't change our build to take advantage of this (though I'll
give it a go later), just makes it possible for builds to do it.
[0] https://sourceware.org/binutils/docs/as/Section.html
[1] https://patchwork.kernel.org/project/linux-crypto/patch/20170119212805.18049-1-dvlasenk@redhat.com/#20050285
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92820#c11
[3] https://sourceware.org/legacy-ml/gdb-patches/2016-01/msg00319.html
[4] de990b270d
Bug: 542
Change-Id: I0a8ded24423087c0da13bd0335cbd757d4eee65a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55626
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
When BoringSSL is imported elsewhere, it would be nice for the links to
be relative, but I'm not sure if that'll work on Gerrit. This change
will try it and can be reverted if
https://boringssl.googlesource.com/boringssl breaks.
Change-Id: I17e056331677923b76fb8852ce8c00e2a4674af4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55685
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
This function reports when security-critical checks on the X.509 key
usage extension would have failed, but were skipped due to the temporary
exception in SSL_set_enforce_rsa_key_usage. This function is meant to
aid deployments as they work through enabling this.
Change-Id: Ice0359879c0a6cbe55bf0cb81a63685506883123
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55465
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Bug: 542
Change-Id: I5b19405598127a957dd3645c74b9616687c2616b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55447
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Bug: 516
Change-Id: Ifd381d1a2ed30aed6ffe84eb83d8fb4d93ec02ba
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55451
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
For unknown reasons, ACVP now tests HKDF differently. This change
updates to reflect what the demo server is currently doing.
Bug: None
Change-Id: I64eec2279765b63ab1296ab6b441d2f7c669c616
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55525
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
That test cert expires in 2099, which is a ways off but if this code is
somehow still around by then, let's save the future some pain. With this
fixed, our test all pass at least through the year 3000, so we're
hopefully clear of timebombs.
Change-Id: Ie9dcbc4f4db70c6bcc1ae9717c6e1ee89eb4195c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55625
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Less code, and internally handles overflows. (Although this one cannot
overflow.)
Bug: 516
Change-Id: I3c2718075689d2815a43534a578a323c52787223
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55452
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Bug: b:261632678, chromium:1396479
Change-Id: I82f7ce05ece8b5c145d4394dc0d4173e357ce176
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55585
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
- Adds the full set of architectures for Linux for which there are
assembly sources listed.
- Adds Android, mostly parallel to Linux.
- Adds the other Apple OSs, parallel to macOS.
Bug: 531
Change-Id: I8bb609d3563b2d151a404f8468b4c6b22c2692f9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55485
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
BIO_ctrl is one of OpenSSL's ioctl-style patterns, where they jam many
different function signatures into one type. BIO_ctrl returns long for
the sake of other operations, but many of them are only allowed to
return int.
Bug: 516
Change-Id: Ieffad1da89c60a538f142b12bdebdb950efd5c6a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55454
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
We were mixing uint64_t and unsigned, which flagged -Wshorten-64-to-32.
While I'm here, switch the iteration count to uint64_t to cut down on
uses of 'unsigned'. While we have no real risk of overflow a u32 here,
counting the number of times we perform some operation in a loop would
probably best be u64.
(I'm guessing we originally used unsigned mostly so that %u worked. But
PRIu64 exists, though it's wordy.)
Bug: 516
Change-Id: I6abc24ecb029c2c223bb940c903d497868bab9fc
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55455
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Along the way, this fixes some size_t truncations.
Bug: 516
Change-Id: Iff0cf6ced0b7deb4c48c268e051a4da433088056
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55453
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Some of them were flagging -Wshorten-64-to-32 warnings. None of these
values are long, so just remove them. (I suspect this assumes unsigned
int is at least 32-bit, but we already assume this rather than wrap all
32-bit constants in UINT32_C(x).)
Ideally the c2l and l2c macros could be replaced with the load/store
functions but, like with the ciphers in decrepit, this is probably not
worth the effort for DES.
Bug: 516
Change-Id: I19e8cd4a321c20b9a22e4c007d943185c10755bb
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55450
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
tag and utype are always accessed as int, so make the structs match.
Boolean ASN1_ITEMs put an ASN1_BOOLEAN in it->size, so add a cast. Also
fix the time set_string functions to call the underlying CBS parser
directly, so they don't need to put a strlen into an int.
Bug: 516
Change-Id: Ie10e7eaf58ec0b0dec59813a0ddcb0197fce1fd1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55449
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
We currently shift between unsigned long and int.
Bug: 516
Change-Id: I9e3fcc9393e24a352a2c08b9df0650a508d7a60b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55448
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
It should not be possible to make BoringSSL request unknown signature
algorithms, or the special SSL_SIGN_RSA_PKCS1_MD5_SHA1 value, in the
ClientHello or CertificateRequest.
Update-Note: This CL makes unknown values fail
SSL_set_verify_algorithm_prefs, etc. SSL_SIGN_RSA_PKCS1_MD5_SHA1 is
silently dropped from the list, rather than an error because, although
documented as incorrect, this hole in the abstraction seems to be
confusing. I think there's some code in Chromium which accidentally puts
it in the signing prefs (wrong but harmless) and I often need to explain
to folks that it doesn't belowing in verify prefs (puts it in the
ClientHello). This makes us tolerate the value by ignoring it.
This makes the previous pkey_supports_algorithm change moot because we'd
never get that far with SSL_SIGN_RSA_PKCS1_MD5_SHA1, but I think the
check, but I think the check belongs in that function too.
The test also reveals that some of our tests have been accidentally
passing zero into the preference list all this time.
Change-Id: I76d4eb98682515c3b819e0ed8d44f2d708a98975
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55446
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
SSL_SIGN_RSA_PKCS1_MD5_SHA1 does not really exist, but is a private use
value we allocated to internally represent the TLS 1.0/1.1 RSA signature
algorithm. (Unlike the TLS 1.0/1.1 ECDSA signature algorithm, which is
the same as SSL_SIGN_ECDSA_SHA1, the RSA one is a bespoke MD5+SHA1
concatenation which never appears in TLS 1.2 and up.)
Although documented that you're not to use it with
SSL_CTX_set_verify_algorithm_prefs and
SSL_CTX_set_signing_algorithm_prefs (it only exists for
SSL_PRIVATE_KEY_METHOD), there's nothing stopping a caller from passing
it in.
Were you to do so anyway, we'd get confused and sign or verify it at TLS
1.2. This CL is the first half of a fix: since we already have
pkey_supports_algorithm that checks a (version, sigalg, key) tuple, that
function should just know this is not a 1.2-compatible algorithm.
A subsequent CL will also fix those APIs to not accept invalid values
from the caller, since these invalid calls will still, e.g., dump
garbage values on the wire.
Change-Id: I119503f9742a17952ed08e5815fb3d1419fd4a12
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55445
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Interestingly, the Chromium version is a bit behind the default. I've
set it to match the Chromium version.
Bug: chromium:1340825
Change-Id: Ia956e42897add5849dfe09ec8e3a19f704ed9641
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55425
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Used on the Android platform.
Change-Id: I99f1f56c6a09852ec918816591371426390f1873
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55405
Commit-Queue: Pete Bentley <prb@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
It would be nice to have a single-shot EVP_CIPHER_CTX API. This function
is not it.
EVP_Cipher is absurd. It's actually just exposing the internal
EVP_CIPHER 'cipher' callback, whose calling convention is extremely
complex. We've currently documented it as a "single-shot" API, but it's
not single-shot either, as it does update cipher state. It just can't
update across block boundaries.
It is particularly bizarre for "custom ciphers", which include AEADs,
which completely changes the return value convention from
bytes_written/-1 to 1/0, but also adds a bunch of magic NULL behaviors:
- out == NULL, in != NULL: supply AAD
- out != NULL, in != NULL: bulk encrypt/decrypt
- out == NULL, in == NULL: compute/check the tag
Moreover, existing code, like OpenSSH, relies on this behavior. To
ensure we don't break it when refactoring EVP_CIPHER internals, capture
the current behavior in tests. But also, no one should be using this in
new code, so deprecate it.
Upstream hasn't quite deprecated it, they now say "Due to the
constraints of the API contract of this function it shouldn't be used in
applications, please consider using EVP_CipherUpdate() and
EVP_CipherFinal_ex() instead."
Bug: 494
Change-Id: Icfe39a8fbbc860b03c9861f4164b7ee8da340216
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55391
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
This API supports that too, so we should test it.
Bug: 494
Change-Id: If978705b3120697cc18fc91c06ca950e0e93bcf3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55390
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
See upstream's 70d8b304d01b9e0c4ec182db20c33aa0698cda51. Also import
upstream's AES-192-GCM tests, now that we support that in EVP_CIPHER
too.
Bug: 494
Change-Id: I157ebe23f32147214641aeb664ce7db2e21bf86a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55389
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
The most likely use of EVP_CIPHER_CTX copy is to work around
EVP_CIPHER_CTX's lack of separation between "key" and "pending
operation". That is, you'd probably first configure the key, save that
as the precomputed AES key schedule, and then mint copies for each
operation to avoid mutating your key-only EVP_CIPHER_CTX. Rearrange
things to test that point.
But, while I'm here, we can just sprinkle copies throughout the whole
operation and ensure it still works.
Bug: 494
Change-Id: I464aa265cee317020d6b3ae3fd2ebfa92d7e12ae
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55388
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
The main FileTest callback didn't support invalid ciphertexts, while the
Wycheproof one did but reimplemented a lot of logic to discover
variations.
Rework this a bit so we have a single TestCipher function that's
agnostic to the FileTest setup. The Operation enum gains a
kInvalidDecrypt mode to specify that the ciphertext is invalid. As part
of this, we tighten up the test
This is to make the later changes easier:
1. We don't have any negative tests for EVP_CIPHER's tag check at all!
We only test it for EVP_AEAD right now. Now TestCipher can express
this.
2. The weird EVP_Cipher API has no tests. It has a weird calling
convention that was easier to test if calling code knew whether to
expect success or failure. Previously, kInvalidDecrypt was
implemented by checking if DoCipher failed, which makes it harder to
embed success/failure-specific assertions.
Along the way, I've made each function responsible for running through
the input once, with separate TestCipherAPI and TestLowLevelAPI helpers.
Otherwise we have to reset the spans and keep track of the state of
intermediate values.
Bug: 494
Change-Id: Ieab87c0c76586aefeb596cc90edd4910ff1b962f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55387
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
EVP_CIPH_NO_PADDING is a no-op when block_size is one, yet we sized the
output expecting it to always add a byte of padding. (I don't think this
makes a difference because most call sites of DoCipher set
EVP_CIPH_NO_PADDING.)
Bug: 494
Change-Id: Ic75e48a60e669270a093416b862ec03706e1d6ef
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55386
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
It's weird to have both "in" and "input" in the same function. Also the
vector const refs can be spans. This is a bit of preparatory cleanup
along the way to a larger refactor so we can do negative tests and test
the weird EVP_Cipher API more coherently.
Bug: 494
Change-Id: I5cddf1b3ab88b3419bd88ce15bee56a2016bcd57
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55385
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Ilya Tokar
David Benjamin
Adam Langley
hehe.li
Adam Langley
Adam Langley
Bob Beck
Christopher Peterson Sauer
Pete Bentley