boringssl

Commit Graph

Author	SHA1	Message	Date
David Benjamin	2749466282	Rework truncated SHA-2 to silence GCC 12 false positive warning. GCC 12's -Wstringop-overflow flags issues in SHA224_Final, etc., because it calls into generic code that might output a SHA-224 length or a SHA-256 length, and the function prototype declares the array is only sized for SHA-224. This is a bit messy because OpenSSL's API for the truncated SHA-2 hashes allows you to mix and match them. The output size is set by SHA224_Init and then, originally, SHA256_Final and SHA224_Final were the same thing. See how OpenSSL's own SHA224 function calls SHA224_Init + SHA256_Final: https://github.com/openssl/openssl/blob/OpenSSL_1_1_1q/crypto/sha/sha256.c#L49-L61 To get the function prototype bounds to work out, we tightened this slightly in https://boringssl-review.googlesource.com/c/boringssl/+/47807 and added an assert to SHA224_Final that ctx->md_len was the right size. SHA256_Final does not have that assert yet. The assert says that mixing SHA256_Init and SHA224_Final is a caller error. This isn't good enough for GCC 12, which checks bounds assuming there is no external invariant on ctx->md_len. This CL changes the behavior of the shorter Final functions: they will now always output the length implied by the function name. ctx->md_len only figures into an assert() call. As we don't have the assert in the untruncated functions yet, I've preserved their behavior, but the test run with cl/471617180 should tell us whether apply this to all functions is feasible. Update-Note: Truncated SHA-2 Final functions change behavior slightly, but anyone affected by this behavior change would already have tripped an assert() in debug builds. Change-Id: I80fdcbe6ad76bc8713c0f2de329b958a2b35e8ae Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54246 Auto-Submit: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>	3 years ago
Adam Langley	118a892d2d	Add a service indicator for FIPS 140-3. This is cribbed, with perimssion, from AWS-LC. The FIPS service indicator[1] signals when an approved service has been completed. [1] FIPS 140-3 IG 2.4.C Change-Id: Ib40210d69b3823f4d2a500b23a1606f8d6942f81 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52568 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: Adam Langley <agl@google.com>	3 years ago
Adam Langley	07e1b286b5	Add missing blank line between functions. Change-Id: I4bab5fe860e7bf2c2bdf11552d60a2e10c55d227 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52565 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>	3 years ago
David Benjamin	17c8c81104	Enable SHA-NI optimizations for SHA-256. While our CI machines don't have these instructions, Intel SDE covers them. Benchmarks on an AMD EPYC machine (VM on Google Compute Engine): Before: Did 13619000 SHA-256 (16 bytes) operations in 3000147us (72.6 MB/sec) Did 3728000 SHA-256 (256 bytes) operations in 3000566us (318.1 MB/sec) Did 920000 SHA-256 (1350 bytes) operations in 3002829us (413.6 MB/sec) Did 161000 SHA-256 (8192 bytes) operations in 3017473us (437.1 MB/sec) Did 81000 SHA-256 (16384 bytes) operations in 3029284us (438.1 MB/sec) After: Did 25442000 SHA-256 (16 bytes) operations in 3000010us (135.7 MB/sec) [+86.8%] Did 10706000 SHA-256 (256 bytes) operations in 3000171us (913.5 MB/sec) [+187.2%] Did 3119000 SHA-256 (1350 bytes) operations in 3000470us (1403.3 MB/sec) [+239.3%] Did 572000 SHA-256 (8192 bytes) operations in 3001226us (1561.3 MB/sec) [+257.2%] Did 289000 SHA-256 (16384 bytes) operations in 3006936us (1574.7 MB/sec) [+259.4%] Although we don't currently have unwind tests in CI, I ran the unwind tests manually on the same VM. They pass, after adding in the missing .cfi_startproc and .cfi_endproc lines. Change-Id: I45b91819e7dcc31e63813843129afa146d0c9d47 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51546 Reviewed-by: Adam Langley <agl@google.com>	3 years ago
David Benjamin	a94c267787	Don't use __ARMEL__/__ARMEB__ in aarch64 assembly GCC's __ARMEL__ and __ARMEB__ defines denote little- and big-endian arm, respectively. They are not defined on aarch64, which instead use __AARCH64EL__ and __AARCH64EB__. However, OpenSSL's assembly originally used the 32-bit defines on both platforms and even define __ARMEL__ and __ARMEB__ in arm_arch.h. This is less portable and can even interfere with other headers, which use __ARMEL__ to detect little-endian arm. (Our own base.h believes __ARMEL__ implies 32-bit arm. We just happen to check __AARCH64EL__ first. base.h is probably also always included before arm_arch.h.) Over time, the aarch64 assembly has switched to the correct defines, such as in 32bbb62ea634239e7cb91d6450ba23517082bab6. This commit finishes the job. (There is an even more official endianness detector, __ARM_BIG_ENDIAN in the Arm C Language Extensions. But I've stuck with the GCC ones here as that would be a larger change.) See also https://github.com/openssl/openssl/pull/17373 Change-Id: Ic04ff85782e6599cdeaeb33d12c2fa8edc882224 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50848 Reviewed-by: Adam Langley <agl@google.com>	3 years ago
David Benjamin	1e15682f1a	Enable SHA-512 ARM acceleration when available. This imports the changes to sha512-armv8.pl from upstream's af0fcf7b4668218b24d9250b95e0b96939ccb4d1. Tweaks needed: - Add an explicit .text because we put .LK$BITS in .rodata for XOM - .LK$bits and code are in separate sections, so use adrp/add instead of plain adr - Where glibc needs feature flags to enable pthread_rwlock, Apple interprets _XOPEN_SOURCE as a request to disable Apple extensions. Tighten the condition on the _XOPEN_SOURCE check. Added support for macOS and Linux, tested manually on an ARM Mac and a VM, respectively. Fuchsia and Windows do not currently have APIs to expose this bit, so I've left in TODOs. Benchmarks from an Apple M1 Max: Before: Did 4647000 SHA-512 (16 bytes) operations in 1000103us (74.3 MB/sec) Did 1614000 SHA-512 (256 bytes) operations in 1000379us (413.0 MB/sec) Did 439000 SHA-512 (1350 bytes) operations in 1001694us (591.6 MB/sec) Did 76000 SHA-512 (8192 bytes) operations in 1011821us (615.3 MB/sec) Did 39000 SHA-512 (16384 bytes) operations in 1024311us (623.8 MB/sec) After: Did 10369000 SHA-512 (16 bytes) operations in 1000088us (165.9 MB/sec) [+123.1%] Did 3650000 SHA-512 (256 bytes) operations in 1000079us (934.3 MB/sec) [+126.2%] Did 1029000 SHA-512 (1350 bytes) operations in 1000521us (1388.4 MB/sec) [+134.7%] Did 175000 SHA-512 (8192 bytes) operations in 1001874us (1430.9 MB/sec) [+132.5%] Did 89000 SHA-512 (16384 bytes) operations in 1010314us (1443.3 MB/sec) [+131.4%] (This doesn't seem to change the overall SHA-256 vs SHA-512 performance question on ARM, when hashing perf matters. SHA-256 on the same chip gets up to 2454.6 MB/s.) In terms of build coverage, for now, we'll have build coverage everywhere and test coverage on Chromium, which runs this code on macOS CI. We should request a macOS ARM64 bot for our standalone CI. Longer term, we need a QEMU-based builder to test various features. QEMU seems to have pretty good coverage of all this, which will at least give us Linux. I haven't added an OPENSSL_STATIC_ARMCAP_SHA512 for now. Instead, we just look at the standard __ARM_FEATURE_SHA512 define. Strangely, the corresponding -march tag is not sha512. Neither GCC and nor Clang have -march=armv8-a+sha512. Instead, -march=armv8-a+sha3 implies both __ARM_FEATURE_SHA3 and __ARM_FEATURE_SHA512! Yet everything else seems to describe the SHA512 extension as separate from SHA3. https://developer.arm.com/architectures/system-architectures/software-standards/acle Update-Note: Consumers with a different build setup may need to limit -D_XOPEN_SOURCE=700 to Linux or non-Apple platforms. Otherwise, <sys/types.h> won't define some typedef needed by <sys/sysctl.h>. If you see a build error about u_char, etc., being undefined in some system header, that is probably the cause. Change-Id: Ia213d3796b84c71b7966bb68e0aec92e5d7d26f0 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50807 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>	3 years ago
David Benjamin	af561c221d	Sync sha512-armv8.pl up to 753316232243ccbf86b96c1c51ffcb41651d9ad5. This imports 753316232243ccbf86b96c1c51ffcb41651d9ad5, 46f4e1bec51dc96fa275c168752aa34359d9ee51, and 32bbb62ea634239e7cb91d6450ba23517082bab6. The last commit fixes a detection of big-endian aarch64 in the kernel, which we do not support at all, but is imported to reduce the upstream diff. Though it points out a messy part of arm_arch.h: __ARMEL__ and __ARMEB__ are specific to 32-bit ARM. __AARCH64EB__ and __AARCH64EL__ are the 64-bit ones. But OpenSSL's arm_arch.h defines __ARME[LB]__ for aarch64 and uses it in perlasm. We should fix the files upstream to look at the aarch64 ones. (Indeed our own base.h assumes __ARMEL__ implies 32-bit ARM.) Change-Id: I6c2241e103a97e8c3599cdfa43dcc6f30d4a2581 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50806 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>	3 years ago
David Benjamin	e90cf82acc	Import sha512-armv8.pl transforms from upstream NEON code. We currently have two aarch64 SHA-256 implementations: one using general-purpose registers and one using the SHA-256 extensions. Upstream's 866e505e0d663158b0fe63a7fb7455eebacc6470 added a NEON version. This CL syncs the transforms at the bottom of the file, to avoid potential mistranslations in future imports. It doesn't change the output for our current assembly. Skips the NEON implementation itself for now. It only helps processors without SHA-256 instructions. While Android does not actually mandate the cryptography extensions on ARMv8, most devices have it. Additionally, this file does CPU dispatch in assembly, without taking advantage of static information. We'd end up shipping both fallback SHA-256 implementations. This is particularly silly because NEON is mandatory in ARMv8-A anyway. (Does anyone build us on -R or -M? Probably not?) (If we later have a reason to import it, the binary size cost isn't that significant. Moreover, the NEON fallback is actually slightly smaller than the non-NEON fallback, so if we move CPU dispatch to C, importing may even be worthwhile.) Change-Id: I3c8ca6e77e4e6d1299f975c407cbcf4c9c240523 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50805 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>	3 years ago
David Benjamin	fa6ced9512	Extract common rotl/rotr functions. We have a ton of per-file rotation functions, often with generic names that do not tell you whether they are uint32_t vs uint64_t, or rotl vs rotr. Additionally, (x >> r) \| (x << (32 - r)) is UB at r = 0. (x >> r) \| (x << ((-r) & 31)) works for 0 <= r < 32, which is what cast.c does. GCC and Clang recognize this pattern as a rotate, but MSVC doesn't. MSVC does, however, provide functions for this. We usually rotate by a non-zero constant, which makes this moot, but rotation comes up often enough that it's worth extracting out. Some particular changes to call out: - I've switched sha256.c from rotl to rotr. There was a comment explaining why it differed from the specification. Now that we have both functions, it's simpler to just match the specification. - I've dropped all the inline assembly from sha512.c. Compilers should be able to recognize rotations in 2021. Change-Id: Ia1030e8bfe94dad92514ed1c28777447c48b82f9 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/49765 Reviewed-by: Adam Langley <agl@google.com>	3 years ago
David Benjamin	549e4e7995	Align with upstream on 'close STDOUT' lines. When upstreaming `c1d8c5b0e0` as https://github.com/openssl/openssl/pull/10883 and then https://github.com/openssl/openssl/pull/10930, we ended up diverging slightly: in the upstream version, I ended up applying the same change to the xlate files. Upstream also suggested "error closing STDOUT: $!". Apply the same changes here. Change-Id: I8a8cbc3944432e94a8844f9f628a900edfe77b30 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48725 Reviewed-by: Adam Langley <agl@google.com>	4 years ago
Florin Crișan	7a3e801217	fix #415 : Perl scripts fail when building from a path with spaces Because file names are not enclosed in quotation marks in the open call. https://bugs.chromium.org/p/boringssl/issues/detail?id=415 ``` cmake --build "C:\Projects\ Extern\Visual C++ 2015\x64 Debug\Build\BoringSSL\." [9/439] Generating rdrand-x86_64.asm FAILED: crypto/fipsmodule/rdrand-x86_64.asm cmd.exe /C "cd /D "C:\Projects\ Extern\Visual C++ 2015\x64 Debug\Build\BoringSSL\crypto\fipsmodule" && "C:\Program Files\CMake\bin\cmake.exe" -E make_directory . && C:\Perl64\bin\perl.exe "C:/Projects/ Extern/Source/BoringSSL/crypto/fipsmodule/rand/asm/rdrand-x86_64.pl" nasm rdrand-x86_64.asm" Can't open perl script "C:/Projects/": No such file or directory error closing STDOUT at C:/Projects/ Extern/Source/BoringSSL/crypto/fipsmodule/rand/asm/rdrand-x86_64.pl line 87. ninja: build stopped: subcommand failed. ``` Bug: 415 Change-Id: I83c4a460689b9adeb439425ad390322ae8b2002a Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47884 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>	4 years ago
David Benjamin	597ffef971	Make md32_common.h single-included and use an unsized helper for SHA-256. Similar to https://boringssl-review.googlesource.com/c/boringssl/+/46405, SHA256_Final and SHA224_Final hit array size warnings in the new GCC. The array sizes are, strictly speaking, purely decoration, but this is a good warning so we should be clean with it on. That same change is difficult to apply to md32_common.h because md32_common.h generates the functions for us. md32_common.h is already strange in that it is multiply-included and changes behavior based on macros defined by the caller. Instead, replace it with inline functions, which are a bit more conventional and typesafe. This allows each hash function to define the function prototype. Use this to add an unsized helper for SHA-256. Bug: 402 Change-Id: I61bc30fb58c54dd40a55c9b1ebf3fb9adde5e038 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47807 Reviewed-by: Adam Langley <agl@google.com> Reviewed-by: Peter Foley <pefoley@google.com> Commit-Queue: David Benjamin <davidben@google.com>	4 years ago
David Benjamin	4320bc4761	Pull HASH_TRANSFORM out of md32_common.h. The macro isn't doing any work here. Change-Id: Id97dfa4b027407c5e4b3e7eb1586c3c2a2d977d8 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47806 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>	4 years ago
David Benjamin	ca4598781a	Move load/store helpers to crypto/internal.h. We have loads of variations of these. Align them in one set. This avoids the HOST_* macros defined by md32_common.h, so it'll be a little easier to make it a more conventional header. Change-Id: Id47fe7b51a8f961bd87839f8146d8a5aa8027aa6 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46425 Reviewed-by: Adam Langley <agl@google.com>	4 years ago
David Benjamin	a24ab549e6	Use an unsized helper for truncated SHA-512 variants. Although it is strictly fine to call SHA512_Final in SHA384_Final (array sizes in C parameters are purely decorational, according to the language), GCC 11 reportedly checks now and gets upset about the size mismatch. Use an unsized helper function so all our code matches the specified bounds. Unfortunately, the bounds in all the functions are a bit misleading because SHA512_Final really outputs based on sha->md_len (which Init function you called) rather than which Final function. I've fixed this places within a library where we mismatched and added asserts to the smaller functions. SHA512_Final is assert-less because I've seen lots of code use SHA384_Init / SHA512_Update / SHA512_Final. This doesn't fix the SHA256 variant since that is generated by a pile of macros in a multiply-included file. This is probably a good opportunity to make that code less macro-heavy. Update-Note: There is a small chance the asserts will trip something, but hopefully not since I've left SHA512_Final alone. Bug: 402 Change-Id: I4c9d579a63ee0a0dea103c19ef219c13bb9aa62c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46405 Reviewed-by: Adam Langley <agl@google.com>	4 years ago
David Benjamin	a6b6b804a0	Align armv8.pl references to OPENSSL_armcap_P. This imports d741debb320bf54e8575d35603a44d4eb40fa1f9 from upstream. We've been managing the shared libraries already because our arm-xlate.pl automatically adds .hidden to .extern lines, but nice to reduce the diff. (This does result in some duplicate .hidden lines in the generated output, but we still want the arm-xlate.pl patch to automatically hide .globl.) Removing .comm lines does change the generated output, but having each asm file define its own copy of OPENSSL_armcap_P as a common symbol always seemed odd. I recall some weird issue where the armv4.pl files subtly rely on it for iOS's strange .indirect_symbol machinery. (Not actually because iOS wants a common symbol but because arm-xlate.pl repurposes .comm to trigger .indirect_symbol.) Fortunately, aarch64 is much better about PC-relative addressing, so it should be a no-op. The .comm lines have also previously caused weird issues (https://boringssl-review.googlesource.com/c/boringssl/+/32324), so it's generally nice to get rid of them. Update-Note: If aarch64 builds get some weird error about relocations, it's this CL's fault. Change-Id: I763ffa6cda750d99694ded8a5b68d7b27b09cfc9 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44464 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>	4 years ago
Tamas Petz	a0b49d63fd	aarch64: support BTI and pointer authentication in assembly This change adds optional support for - Armv8.3-A Pointer Authentication (PAuth) and - Armv8.5-A Branch Target Identification (BTI) features to the perl scripts. Both features can be enabled with additional compiler flags. Unless any of these are enabled explicitly there is no code change at all. The extensions are briefly described below. Please read the appropriate chapters of the Arm Architecture Reference Manual for the complete specification. Scope ----- This change only affects generated assembly code. Armv8.3-A Pointer Authentication -------------------------------- Pointer Authentication extension supports the authentication of the contents of registers before they are used for indirect branching or load. PAuth provides a probabilistic method to detect corruption of register values. PAuth signing instructions generate a Pointer Authentication Code (PAC) based on the value of a register, a seed and a key. The generated PAC is inserted into the original value in the register. A PAuth authentication instruction recomputes the PAC, and if it matches the PAC in the register, restores its original value. In case of a mismatch, an architecturally unmapped address is generated instead. With PAuth, mitigation against ROP (Return-oriented Programming) attacks can be implemented. This is achieved by signing the contents of the link-register (LR) before it is pushed to stack. Once LR is popped, it is authenticated. This way a stack corruption which overwrites the LR on the stack is detectable. The PAuth extension adds several new instructions, some of which are not recognized by older hardware. To support a single codebase for both pre Armv8.3-A targets and newer ones, only NOP-space instructions are added by this patch. These instructions are treated as NOPs on hardware which does not support Armv8.3-A. Furthermore, this patch only considers cases where LR is saved to the stack and then restored before branching to its content. There are cases in the code where LR is pushed to stack but it is not used later. We do not address these cases as they are not affected by PAuth. There are two keys available to sign an instruction address: A and B. PACIASP and PACIBSP only differ in the used keys: A and B, respectively. The keys are typically managed by the operating system. To enable generating code for PAuth compile with -mbranch-protection=<mode>: - standard or pac-ret: add PACIASP and AUTIASP, also enables BTI (read below) - pac-ret+b-key: add PACIBSP and AUTIBSP Armv8.5-A Branch Target Identification -------------------------------------- Branch Target Identification features some new instructions which protect the execution of instructions on guarded pages which are not intended branch targets. If Armv8.5-A is supported by the hardware, execution of an instruction changes the value of PSTATE.BTYPE field. If an indirect branch lands on a guarded page the target instruction must be one of the BTI <jc> flavors, or in case of a direct call or jump it can be any other instruction. If the target instruction is not compatible with the value of PSTATE.BTYPE a Branch Target Exception is generated. In short, indirect jumps are compatible with BTI <j> and <jc> while indirect calls are compatible with BTI <c> and <jc>. Please refer to the specification for the details. Armv8.3-A PACIASP and PACIBSP are implicit branch target identification instructions which are equivalent with BTI c or BTI jc depending on system register configuration. BTI is used to mitigate JOP (Jump-oriented Programming) attacks by limiting the set of instructions which can be jumped to. BTI requires active linker support to mark the pages with BTI-enabled code as guarded. For ELF64 files BTI compatibility is recorded in the .note.gnu.property section. For a shared object or static binary it is required that all linked units support BTI. This means that even a single assembly file without the required note section turns-off BTI for the whole binary or shared object. The new BTI instructions are treated as NOPs on hardware which does not support Armv8.5-A or on pages which are not guarded. To insert this new and optional instruction compile with -mbranch-protection=standard (also enables PAuth) or +bti. When targeting a guarded page from a non-guarded page, weaker compatibility restrictions apply to maintain compatibility between legacy and new code. For detailed rules please refer to the Arm ARM. Compiler support ---------------- Compiler support requires understanding '-mbranch-protection=<mode>' and emitting the appropriate feature macros (__ARM_FEATURE_BTI_DEFAULT and __ARM_FEATURE_PAC_DEFAULT). The current state is the following: ------------------------------------------------------- \| Compiler \| -mbranch-protection \| Feature macros \| +----------+---------------------+--------------------+ \| clang \| 9.0.0 \| 11.0.0 \| +----------+---------------------+--------------------+ \| gcc \| 9 \| expected in 10.1+ \| ------------------------------------------------------- Available Platforms ------------------ Arm Fast Model and QEMU support both extensions. https://developer.arm.com/tools-and-software/simulation-models/fast-models https://www.qemu.org/ Implementation Notes -------------------- This change adds BTI landing pads even to assembly functions which are likely to be directly called only. In these cases, landing pads might be superfluous depending on what code the linker generates. Code size and performance impact for these cases would be negligble. Interaction with C code ----------------------- Pointer Authentication is a per-frame protection while Branch Target Identification can be turned on and off only for all code pages of a whole shared object or static binary. Because of these properties if C/C++ code is compiled without any of the above features but assembly files support any of them unconditionally there is no incompatibility between the two. Useful Links ------------ To fully understand the details of both PAuth and BTI it is advised to read the related chapters of the Arm Architecture Reference Manual (Arm ARM): https://developer.arm.com/documentation/ddi0487/latest/ Additional materials: "Providing protection for complex software" https://developer.arm.com/architectures/learn-the-architecture/providing-protection-for-complex-software Arm Compiler Reference Guide Version 6.14: -mbranch-protection https://developer.arm.com/documentation/101754/0614/armclang-Reference/armclang-Command-line-Options/-mbranch-protection?lang=en Arm C Language Extensions (ACLE) https://developer.arm.com/docs/101028/latest Change-Id: I4335f92e2ccc8e209c7d68a0a79f1acdf3aeb791 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42084 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>	5 years ago
Adam Langley	fb0c05cac2	acvp: add CMAC-AES support. Change by Dan Janni. Change-Id: I3f059e7b1a822c6f97128ca92a693499a3f7fa8f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41984 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>	5 years ago

18 Commits (da663b7ca86d70f7da979f9a48d2238ca5762bdd)