aboutsummaryrefslogtreecommitdiff
path: root/sys/crypto
Commit message (Collapse)AuthorAgeFilesLines
* aesni: Avoid modifying session keys in hmac_update()Mark Johnston2021-05-262-10/+14
| | | | | | | | | | | | | | | | Otherwise aesni_process() is not thread-safe for AES+SHA-HMAC transforms, since hmac_update() updates the caller-supplied key directly to create the derived key. Use a buffer on the stack to store a copy of the key used for computing inner and outer digests. This is a direct commit to stable/12 as the bug is not present in later branches. Approved by: so Security: EN-21:11.aesni Reviewed by: kib (cherry picked from commit 62e32cf9140e6c13663dcd69ec3b3c7ca4579782)
* MFC 362123: Fix AES-CCM requests with an AAD size smaller than a single block.John Baldwin2020-09-081-1/+1
| | | | | | | | The amount to copy for the first block is the minimum of the size of the AAD region or the remaining space in the first block. Notes: svn path=/stable/12/; revision=365482
* MFC r348268 (by sef), r348293 (by cem):Alexander Motin2019-09-114-11/+512
| | | | | | | | Add an AESNI-optimized version of the CCM/CBC cryptographic and authentication code. The primary client of this is probably going to be ZFS encryption. Notes: svn path=/stable/12/; revision=352235
* MFC r342024 (by mmacy): Generalize AES iov optimizationAlexander Motin2019-09-111-21/+6
| | | | | | | | | | | | | | | | | | | Right now, aesni_cipher_alloc does a bit of special-casing for CRYPTO_F_IOV, to not do any allocation if the first uio is large enough for the requested size. While working on ZFS crypto port, I ran into horrible performance because the code uses scatter-gather, and many of the times the data to encrypt was in the second entry. This code looks through the list, and tries to see if there is a single uio that can contain the requested data, and, if so, uses that. This has a slight impact on the current consumers, in that the check is a little more complicated for the ones that use CRYPTO_F_IOV -- but none of them meet the criteria for testing more than one. Notes: svn path=/stable/12/; revision=352234
* MFC r343755:Warner Losh2019-09-051-1/+2
| | | | | | | Regularize the Netflix copyright Notes: svn path=/stable/12/; revision=351913
* Revert r351902 ... it didn't properly exclude rack.c changesWarner Losh2019-09-051-2/+1
| | | | Notes: svn path=/stable/12/; revision=351912
* MFC r343755:Warner Losh2019-09-051-1/+2
| | | | | | | Regularize the Netflix copyright Notes: svn path=/stable/12/; revision=351902
* Reapply, with minor tweaks, r338025, from the original commit:Warner Losh2018-09-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove unused and easy to misuse PNP macro parameter Inspired by r338025, just remove the element size parameter to the MODULE_PNP_INFO macro entirely. The 'table' parameter is now required to have correct pointer (or array) type. Since all invocations of the macro already had this property and the emitted PNP data continues to include the element size, there is no functional change. Mostly done with the coccinelle 'spatch' tool: $ cat modpnpsize0.cocci @normaltables@ identifier b,c; expression a,d,e; declarer MODULE_PNP_INFO; @@ MODULE_PNP_INFO(a,b,c,d, -sizeof(d[0]), e); @singletons@ identifier b,c,d; expression a; declarer MODULE_PNP_INFO; @@ MODULE_PNP_INFO(a,b,c,&d, -sizeof(d), 1); $ rg -l MODULE_PNP_INFO -- sys | \ xargs spatch --in-place --sp-file modpnpsize0.cocci (Note that coccinelle invokes diff(1) via a PATH search and expects diff to tolerate the -B flag, which BSD diff does not. So I had to link gdiff into PATH as diff to use spatch.) Tinderbox'd (-DMAKE_JUST_KERNELS). Approved by: re (glen) Notes: svn path=/head/; revision=338948
* Don't load ccp automatically with devmatchWarner Losh2018-08-311-0/+2
| | | | | | | | | | | | | | | Remove the PNP info for the moment from the driver. It's an experimental driver (as noted in r328150). It's performance is about 1/10th that of aesni. It will often panic when used with GELI (PR 2279820). It's not in our best interest to have such a driver be autoloaded by default. Approved by: re@ (rgrimes) Reviewed By: cem@ Differential Review: https://reviews.freebsd.org/D16959 Notes: svn path=/head/; revision=338402
* Update userland arc4random() with OpenBSD's Chacha20 based arc4random().Xin LI2018-08-192-7/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ObsoleteFiles.inc: Remove manual pages for arc4random_addrandom(3) and arc4random_stir(3). contrib/ntp/lib/isc/random.c: contrib/ntp/sntp/libevent/evutil_rand.c: Eliminate in-tree usage of arc4random_addrandom(). crypto/heimdal/lib/roken/rand.c: crypto/openssh/config.h: Eliminate in-tree usage of arc4random_stir(). include/stdlib.h: Remove arc4random_stir() and arc4random_addrandom() prototypes, provide temporary shims for transistion period. lib/libc/gen/Makefile.inc: Hook arc4random-compat.c to build, add hint for Chacha20 source for kernel, and remove arc4random_addrandom(3) and arc4random_stir(3) links. lib/libc/gen/arc4random.c: Adopt OpenBSD arc4random.c,v 1.54 with bare minimum changes, use the sys/crypto/chacha20 implementation of keystream. lib/libc/gen/Symbol.map: Remove arc4random_stir and arc4random_addrandom interfaces. lib/libc/gen/arc4random.h: Adopt OpenBSD arc4random.h,v 1.4 but provide _ARC4_LOCK of our own. lib/libc/gen/arc4random.3: Adopt OpenBSD arc4random.3,v 1.35 but keep FreeBSD r114444 and r118247. lib/libc/gen/arc4random-compat.c: Compatibility shims for arc4random_stir and arc4random_addrandom functions to preserve ABI. Log once when called but do nothing otherwise. lib/libc/gen/getentropy.c: lib/libc/include/libc_private.h: Fold __arc4_sysctl into getentropy.c (renamed to arnd_sysctl). Remove from libc_private.h as a result. sys/crypto/chacha20/chacha.c: sys/crypto/chacha20/chacha.h: Make it possible to use the kernel implementation in libc. PR: 182610 Reviewed by: cem, markm Obtained from: OpenBSD Relnotes: yes Differential Revision: https://reviews.freebsd.org/D16760 Notes: svn path=/head/; revision=338059
* Back out r338035 until Warner is finished churning GSoC PNP patchesConrad Meyer2018-08-191-1/+1
| | | | | | | | | | I was not aware Warner was making or planning to make forward progress in this area and have since been informed of that. It's easy to apply/reapply when churn dies down. Notes: svn path=/head/; revision=338037
* Remove unused and easy to misuse PNP macro parameterConrad Meyer2018-08-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Inspired by r338025, just remove the element size parameter to the MODULE_PNP_INFO macro entirely. The 'table' parameter is now required to have correct pointer (or array) type. Since all invocations of the macro already had this property and the emitted PNP data continues to include the element size, there is no functional change. Mostly done with the coccinelle 'spatch' tool: $ cat modpnpsize0.cocci @normaltables@ identifier b,c; expression a,d,e; declarer MODULE_PNP_INFO; @@ MODULE_PNP_INFO(a,b,c,d, -sizeof(d[0]), e); @singletons@ identifier b,c,d; expression a; declarer MODULE_PNP_INFO; @@ MODULE_PNP_INFO(a,b,c,&d, -sizeof(d), 1); $ rg -l MODULE_PNP_INFO -- sys | \ xargs spatch --in-place --sp-file modpnpsize0.cocci (Note that coccinelle invokes diff(1) via a PATH search and expects diff to tolerate the -B flag, which BSD diff does not. So I had to link gdiff into PATH as diff to use spatch.) Tinderbox'd (-DMAKE_JUST_KERNELS). Notes: svn path=/head/; revision=338035
* Bring in compatibility glue for libsodiumConrad Meyer2018-08-178-0/+42
| | | | | | | | | | | | The idea is untouched upstream sources live in sys/contrib/libsodium. sys/crypto/libsodium are support routines or compatibility headers to allow building unmodified upstream code. This is not yet integrated into the build system, so no functional change. Notes: svn path=/head/; revision=337938
* libmd: Always erase context in _Final method, and when doingXin LI2018-07-203-5/+8
| | | | | | | | | | | | | it, consistently use explicit_bzero(). Update manual pages to match the behavior. Reviewed by: pfg, allanjude, jmg MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D16316 Notes: svn path=/head/; revision=336539
* Remove unused variableConrad Meyer2018-07-181-2/+0
| | | | | | | Reported by: gcc Notes: svn path=/head/; revision=336445
* aesni(4): Add SHA2-224(-HMAC) support as wellConrad Meyer2018-07-181-0/+32
| | | | Notes: svn path=/head/; revision=336444
* aesni(4): Add sha256 plain hash supportConrad Meyer2018-07-181-0/+6
| | | | Notes: svn path=/head/; revision=336443
* aesni(4): Abstract out hash/HMAC supportConrad Meyer2018-07-181-26/+49
| | | | | | | | | No functional change. Verified with cryptocheck. Notes: svn path=/head/; revision=336442
* OpenCrypto: Convert sessions to opaque handles instead of integersConrad Meyer2018-07-189-499/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Track session objects in the framework, and pass handles between the framework (OCF), consumers, and drivers. Avoid redundancy and complexity in individual drivers by allocating session memory in the framework and providing it to drivers in ::newsession(). Session handles are no longer integers with information encoded in various high bits. Use of the CRYPTO_SESID2FOO() macros should be replaced with the appropriate crypto_ses2foo() function on the opaque session handle. Convert OCF drivers (in particular, cryptosoft, as well as myriad others) to the opaque handle interface. Discard existing session tracking as much as possible (quick pass). There may be additional code ripe for deletion. Convert OCF consumers (ipsec, geom_eli, krb5, cryptodev) to handle-style interface. The conversion is largely mechnical. The change is documented in crypto.9. Inspired by https://lists.freebsd.org/pipermail/freebsd-arch/2018-January/018835.html . No objection from: ae (ipsec portion) Reported by: jhb Notes: svn path=/head/; revision=336439
* Create an empty stdint.h for arm_neon.h to include.Andrew Turner2018-07-161-0/+5
| | | | | | | | | | | | | The armv8crypto module includes arm_neon.h for the compiler intrinsic functions. This includes the userland stdint.h file that doesn't exist in the kernel. Fix this by providing an empty stdint.h to be used when we include arm_neon.h. Sponsored by: DARPA, AFRL Differential Revision: https://reviews.freebsd.org/D16254 Notes: svn path=/head/; revision=336348
* Implement SHA2-224 submode of SHA2-256Conrad Meyer2018-07-092-0/+154
| | | | | | | | Like SHA2-384:SHA2-512, SHA2-224 is simply a truncated SHA2-256 with a different initial vector. Add to round out the complete basic SHA2 family. Notes: svn path=/head/; revision=336123
* Remove "HMAC" from <HASH>_HMAC_BLOCK_LEN macro namesConrad Meyer2018-07-093-6/+6
| | | | | | | | | | The block size is a property of the underlying hash algorithm, and has nothing to do with the HMAC construction. No functional change. Notes: svn path=/head/; revision=336122
* aesni(4): Fix {de,en}crypt operations that allocated a bufferConrad Meyer2018-06-231-0/+4
| | | | | | | | | | | | | | | | | | | | aesni(4) allocates a contiguous buffer for the data it processes if the provided input was not already virtually contiguous, and copies the input there. It performs encryption or decryption in-place. r324037 removed the logic that then copied the processed data back to the user-provided input buffer, breaking {de,enc}crypt for mbuf chains or iovecs with more than a single descriptor. PR: 228094 (probably, not confirmed) Submitted by: Sean Fagan <kithrup AT me.com> Reported by: Emeric POUPON <emeric.poupon AT stormshield.eu> X-MFC-With: 324037 Security: could result in plaintext being output by "encrypt" operation Notes: svn path=/head/; revision=335584
* aesni(4): Support CRD_F_KEY_EXPLICIT OCF modeConrad Meyer2018-06-231-11/+31
| | | | | | | | PR: 227788 Reported by: eadler@ Notes: svn path=/head/; revision=335583
* disable printing value of SKEIN_LOOP during standard out,Matt Macy2018-05-191-1/+1
| | | | | | | not useful information Notes: svn path=/head/; revision=333883
* opencrypto: Integrate Chacha20 algorithm into OCFConrad Meyer2018-03-291-0/+78
| | | | | | | | | | | Mostly this is a thin shim around existing code to integrate with enc_xform and cryptosoft (+ cryptodev). Expand the cryptodev buffer used to match that of Chacha20's native block size as a performance enhancement for chacha20_xform_crypt_multi. Notes: svn path=/head/; revision=331724
* MFV: libb2: use native calls for secure memory clearanceConrad Meyer2018-03-271-0/+2
| | | | | | | | | | | | | Drop our local patch and restore full vanilla upstream code in contrib/libb2. No functional change intended. explicit_bzero() should continue to be used. Obtained from: libb2 b4b241a34824b51956a7866606329a065d397525 Sponsored by: Dell EMC Isilon Notes: svn path=/head/; revision=331620
* The PNP info has to follow the module definition. Move it from justWarner Losh2018-03-251-2/+2
| | | | | | | | | after the array to its proper location. Otherwise, the linker.hints file has things out of order and we associated it with whatever was the previous module. Notes: svn path=/head/; revision=331532
* Import Blake2 algorithms (blake2b, blake2s) from libb2Conrad Meyer2018-03-2119-0/+772
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The upstream repository is on github BLAKE2/libb2. Files landed in sys/contrib/libb2 are the unmodified upstream files, except for one difference: secure_zero_memory's contents have been replaced with explicit_bzero() only because the previous implementation broke powerpc link. Preferential use of explicit_bzero() is in progress upstream, so it is anticipated we will be able to drop this diff in the future. sys/crypto/blake2 contains the source files needed to port libb2 to our build system, a wrapped (limited) variant of the algorithm to match the API of our auth_transform softcrypto abstraction, incorporation into the Open Crypto Framework (OCF) cryptosoft(4) driver, as well as an x86 SSE/AVX accelerated OCF driver, blake2(4). Optimized variants of blake2 are compiled for a number of x86 machines (anything from SSE2 to AVX + XOP). On those machines, FPU context will need to be explicitly saved before using blake2(4)-provided algorithms directly. Use via cryptodev / OCF saves FPU state automatically, and use via the auth_transform softcrypto abstraction does not use FPU. The intent of the OCF driver is mostly to enable testing in userspace via /dev/crypto. ATF tests are added with published KAT test vectors to validate correctness. Reviewed by: jhb, markj Obtained from: github BLAKE2/libb2 Differential Revision: https://reviews.freebsd.org/D14662 Notes: svn path=/head/; revision=331312
* Garbage collect unused chacha20 codeConrad Meyer2018-03-162-262/+0
| | | | | | | | | | | | | | | | | Two copies of chacha20 were imported into the tree on Apr 15 2017 (r316982) and Apr 16 2017 (r317015). Only the latter is actually used by anything, so just go ahead and garbage collect the unused version while it's still only in CURRENT. I'm not making any judgement on which implementation is better. If I pulled the wrong one, feel free to swap the existing implementation out and replace it with the other code (conforming to the API that actually gets used in randomdev, of course). We only need one generic implementation. Sponsored by: Dell EMC Isilon Notes: svn path=/head/; revision=331049
* aesni(4): Stylistic/comment enhancementsConrad Meyer2018-03-151-5/+7
| | | | | | | | | | | | Improve clarity of a comment and style(9) some areas. No functional change. Reported by: markj (on review of a mostly-copied driver) Sponsored by: Dell EMC Isilon Notes: svn path=/head/; revision=331007
* Remove unused error return from API that cannot failConrad Meyer2018-02-235-32/+12
| | | | | | | | | | | | | | | | | | | No implementation of fpu_kern_enter() can fail, and it was causing needless error checking boilerplate and confusion. Change the return code to void to match reality. (This trivial change took nine days to land because of the commit hook on sys/dev/random. Please consider removing the hook or otherwise lowering the bar -- secteam never seems to have free time to review patches.) Reported by: Lachlan McIlroy <Lachlan.McIlroy AT isilon.com> Reviewed by: delphij Approved by: secteam (delphij) Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D14380 Notes: svn path=/head/; revision=329878
* ccp(4): Store IV in output buffer in GCM software fallback when requestedConrad Meyer2018-01-271-0/+3
| | | | | | | | | | Apply r328361 to duplicate copy of ccr_gcm_soft in ccp(4). Properly honor the lack of the CRD_F_IV_PRESENT flag in the GCM software fallback case for encryption requests. Notes: svn path=/head/; revision=328465
* Add ccp(4): experimental driver for AMD Crypto Co-ProcessorConrad Meyer2018-01-186-0/+3907
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Registers TRNG source for random(4) * Finds available queues, LSBs; allocates static objects * Allocates a shared MSI-X for all queues. The hardware does not have separate interrupts per queue. Working interrupt mode driver. * Computes SHA hashes, HMAC. Passes cryptotest.py, cryptocheck tests. * Does AES-CBC, CTR mode, and XTS. cryptotest.py and cryptocheck pass. * Support for "authenc" (AES + HMAC). (SHA1 seems to result in "unaligned" cleartext inputs from cryptocheck -- which the engine cannot handle. SHA2 seems to work fine.) * GCM passes for block-multiple AAD, input lengths Largely based on ccr(4), part of cxgbe(4). Rough performance averages on AMD Ryzen 1950X (4kB buffer): aesni: SHA1: ~8300 Mb/s SHA256: ~8000 Mb/s ccp: ~630 Mb/s SHA256: ~660 Mb/s SHA512: ~700 Mb/s cryptosoft: ~1800 Mb/s SHA256: ~1800 Mb/s SHA512: ~2700 Mb/s As you can see, performance is poor in comparison to aesni(4) and even cryptosoft (due to high setup cost). At a larger buffer size (128kB), throughput is a little better (but still worse than aesni(4)): aesni: SHA1:~10400 Mb/s SHA256: ~9950 Mb/s ccp: ~2200 Mb/s SHA256: ~2600 Mb/s SHA512: ~3800 Mb/s cryptosoft: ~1750 Mb/s SHA256: ~1800 Mb/s SHA512: ~2700 Mb/s AES performance has a similar story: aesni: 4kB: ~11250 Mb/s 128kB: ~11250 Mb/s ccp: ~350 Mb/s 128kB: ~4600 Mb/s cryptosoft: ~1750 Mb/s 128kB: ~1700 Mb/s This driver is EXPERIMENTAL. You should verify cryptographic results on typical and corner case inputs from your application against a known- good implementation. Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D12723 Notes: svn path=/head/; revision=328150
* Revert r327340, as the workaround for rep prefixes followed by .byteDimitry Andric2018-01-171-1/+1
| | | | | | | directives is no longer needed after r328090. Notes: svn path=/head/; revision=328091
* Merge ^/head r327624 through r327885.Dimitry Andric2018-01-121-0/+5
|\ | | | | | | Notes: svn path=/projects/clang600-import/; revision=327886
| * aesni(4): Quiesce spurious GCC 6.3.0 -Wmaybe-uninitialized warningsConrad Meyer2018-01-121-0/+5
| | | | | | | | | | | | | | | | | | | | Always initialize some variables GCC warns about. They are initialized in every path where they are used, but GCC doesn't know that. Sponsored by: Dell EMC Isilon Notes: svn path=/head/; revision=327866
* | Work around a clang 6.0.0 issue with rep prefixes followed by .byteDimitry Andric2017-12-291-1/+1
|/ | | | | | | | | | | directives (as reported in https://bugs.llvm.org/show_bug.cgi?id=35749), by defining the rep prefix with yet another .byte directive. This is a temporary fix, to be reverted before merging back to head, until upstream has a proper fix for this. Notes: svn path=/projects/clang600-import/; revision=327340
* sys: further adoption of SPDX licensing ID tags.Pedro F. Giffuni2017-11-202-2/+6
| | | | | | | | | | | | | | | | | Mainly focus on files that use BSD 3-Clause license. The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts. Special thanks to Wind River for providing access to "The Duke of Highlander" tool: an older (2014) run over FreeBSD tree was useful as a starting point. Notes: svn path=/head/; revision=326023
* aesni(4): CRYPTO_AES_NIST_GCM_16 mandates MACConrad Meyer2017-10-041-2/+5
| | | | | | | | | | | | | Remove some dead conditionals and add an assertion around behavior already present in aesni_process(). Silence a few Coverity false positives. CIDs: 1381571, 1381557 Sponsored by: Dell EMC Isilon Notes: svn path=/head/; revision=324288
* aesni(4): Fix GCC buildConrad Meyer2017-09-292-4/+6
| | | | | | | | | | | | | | | | The GCC xmmintrin.h header brokenly includes mm_malloc.h unconditionally. (The Clang version of xmmintrin.h only includes mm_malloc.h if not compiling in standalone mode.) Hack around GCC's broken header by defining the include guard macro ahead of including xmmintrin.h. Reported by: lwhsu, jhb Tested by: lwhsu Sponsored by: Dell EMC Isilon Notes: svn path=/head/; revision=324106
* aesni(4): Add support for x86 SHA intrinsicsConrad Meyer2017-09-265-104/+968
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some x86 class CPUs have accelerated intrinsics for SHA1 and SHA256. Provide this functionality on CPUs that support it. This implements CRYPTO_SHA1, CRYPTO_SHA1_HMAC, and CRYPTO_SHA2_256_HMAC. Correctness: The cryptotest.py suite in tests/sys/opencrypto has been enhanced to verify SHA1 and SHA256 HMAC using standard NIST test vectors. The test passes on this driver. Additionally, jhb's cryptocheck tool has been used to compare various random inputs against OpenSSL. This test also passes. Rough performance averages on AMD Ryzen 1950X (4kB buffer): aesni: SHA1: ~8300 Mb/s SHA256: ~8000 Mb/s cryptosoft: ~1800 Mb/s SHA256: ~1800 Mb/s So ~4.4-4.6x speedup depending on algorithm choice. This is consistent with the results the Linux folks saw for 4kB buffers. The driver borrows SHA update code from sys/crypto sha1 and sha256. The intrinsic step function comes from Intel under a 3-clause BSDL.[0] The intel_sha_extensions_sha<foo>_intrinsic.c files were renamed and lightly modified (added const, resolved a warning or two; included the sha_sse header to declare the functions). [0]: https://software.intel.com/en-us/articles/intel-sha-extensions-implementations Reviewed by: jhb Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D12452 Notes: svn path=/head/; revision=324037
* opencrypto: Use C99 initializers for auth_hash instancesConrad Meyer2017-09-261-12/+18
| | | | | | | | | | | | A misordering in the Via padlock driver really strongly suggested that these should use C99 named initializers. No functional change. Sponsored by: Dell EMC Isilon Notes: svn path=/head/; revision=324019
* opencrypto: Loosen restriction on HMAC key sizesConrad Meyer2017-09-261-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Theoretically, HMACs do not actually have any limit on key sizes. Transforms should compact input keys larger than the HMAC block size by using the transform (hash) on the input key. (Short input keys are padded out with zeros to the HMAC block size.) Still, not all FreeBSD crypto drivers that provide HMAC functionality handle longer-than-blocksize keys appropriately, so enforce a "maximum" key length in the crypto API for auth_hashes that previously expressed a requirement. (The "maximum" is the size of a single HMAC block for the given transform.) Unconstrained auth_hashes are left as-is. I believe the previous hardcoded sizes were committed in the original import of opencrypto from OpenBSD and are due to specific protocol details of IPSec. Note that none of the previous sizes actually matched the appropriate HMAC block size. The previous hardcoded sizes made the SHA tests in cryptotest.py useless for testing FreeBSD crypto drivers; none of the NIST-KAT example inputs had keys sized to the previous expectations. The following drivers were audited to check that they handled keys up to the block size of the HMAC safely: Software HMAC: * padlock(4) * cesa * glxsb * safe(4) * ubsec(4) Hardware accelerated HMAC: * ccr(4) * hifn(4) * sec(4) (Only supports up to 64 byte keys despite claiming to support SHA2 HMACs, but validates input key sizes) * cryptocteon (MIPS) * nlmsec (MIPS) * rmisec (MIPS) (Amusingly, does not appear to use key material at all -- presumed broken) Reviewed by: jhb (previous version), rlibby (previous version) Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D12437 Notes: svn path=/head/; revision=324017
* aesni(4): Fix another trivial typo (aensi -> aesni)Conrad Meyer2017-09-201-2/+2
| | | | | | | Sponsored by: Dell EMC Isilon Notes: svn path=/head/; revision=323823
* aesni(4): Fix trivial typo (AQUIRE -> ACQUIRE)Conrad Meyer2017-09-201-3/+3
| | | | | | | Sponsored by: Dell EMC Isilon Notes: svn path=/head/; revision=323820
* aesni: quiet -Wcast-qualRyan Libby2017-08-162-42/+46
| | | | | | | | | | Reviewed by: delphij Approved by: markj (mentor) Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D12021 Notes: svn path=/head/; revision=322600
* Remove register keyword from sys/ and ANSIfy prototypesEd Maste2017-05-172-14/+14
| | | | | | | | | | | | | | | A long long time ago the register keyword told the compiler to store the corresponding variable in a CPU register, but it is not relevant for any compiler used in the FreeBSD world today. ANSIfy related prototypes while here. Reviewed by: cem, jhb Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D10193 Notes: svn path=/head/; revision=318389
* Fix counter increment in Salsa and ChaCha.Dag-Erling Smørgrav2017-04-221-3/+2
| | | | | | | | | | | In my eagerness to eliminate a branch which is taken once per 2^38 bytes of keystream, I forgot that the state words are in host order. Thus, the counter increment code worked fine on little-endian machines, but not on big-endian ones. Switch to a simpler (branchful) solution. Notes: svn path=/head/; revision=317277
* Replace the RC4 algorithm for generating in-kernel secure randomMark Murray2017-04-162-0/+256
| | | | | | | | | | | | | | | | | numbers with Chacha20. Keep the API, though, as that is what the other *BSD's have done. Use the boot-time entropy stash (if present) to bootstrap the in-kernel entropy source. Reviewed by: delphij,rwatson Approved by: so(delphij) MFC after: 2 months Relnotes: yes Differential Revision: https://reviews.freebsd.org/D10048 Notes: svn path=/head/; revision=317015
generated by cgit v1.3 (git 2.53.0) at 2026-04-17 22:34:24 +0000