summaryrefslogtreecommitdiffstats
path: root/sys/opencrypto/cryptosoft.c
Commit message (Collapse)AuthorAgeFilesLines
* MFC r286292:Luiz Otavio O Souza2015-10-201-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make IPsec work with AES-GCM and AES-ICM (aka CTR) in OCF... IPsec defines the keys differently than NIST does, so we have to muck with key lengths and nonce/IVs to be standard compliant... Remove the iv from secasvar as it was unused... Add a counter protected by a mutex to ensure that the counter for GCM and ICM will never be repeated.. This is a requirement for security.. I would use atomics, but we don't have a 64bit one on all platforms.. Fix a bug where IPsec was depending upon the OCF to ensure that the blocksize was always at least 4 bytes to maintain alignment... Move this logic into IPsec so changes to OCF won't break IPsec... In one place, espx was always non-NULL, so don't test that it's non-NULL before doing work.. minor style cleanups... drop setting key and klen as they were not used... Enforce that OCF won't pass invalid key lengths to AES that would panic the machine... This was has been tested by others too... I tested this against NetBSD 6.1.5 using mini-test suite in https://github.com/jmgurney/ipseccfgs and the only things that don't pass are keyed md5 and sha1, and 3des-deriv (setkey syntax error), all other modes listed in setkey's man page... The nice thing is that NetBSD uses setkey, so same config files were used on both... Reviewed by: gnn TAG: IPSEC-HEAD Issue: #4841
* MFC r285247:Luiz Otavio O Souza2015-10-201-1/+3
| | | | | | | | | | we may get here w/ non-sleepable locks held, so switch to _NOWAIT when doing this memory allocation... Reviewed by: ae TAG: IPSEC-HEAD Issue: #4841
* MFC r275732:Luiz Otavio O Souza2015-10-201-313/+405
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add some new modes to OpenCrypto. These modes are AES-ICM (can be used for counter mode), and AES-GCM. Both of these modes have been added to the aesni module. Included is a set of tests to validate that the software and aesni module calculate the correct values. These use the NIST KAT test vectors. To run the test, you will need to install a soon to be committed port, nist-kat that will install the vectors. Using a port is necessary as the test vectors are around 25MB. All the man pages were updated. I have added a new man page, crypto.7, which includes a description of how to use each mode. All the new modes and some other AES modes are present. It would be good for someone else to go through and document the other modes. A new ioctl was added to support AEAD modes which AES-GCM is one of them. Without this ioctl, it is not possible to test AEAD modes from userland. Add a timing safe bcmp for use to compare MACs. Previously we were using bcmp which could leak timing info and result in the ability to forge messages. Add a minor optimization to the aesni module so that single segment mbufs don't get copied and instead are updated in place. The aesni module needs to be updated to support blocked IO so segmented mbufs don't have to be copied. We require that the IV be specified for all calls for both GCM and ICM. This is to ensure proper use of these functions. Obtained from: p4: //depot/projects/opencrypto Relnotes: yes Sponsored by: FreeBSD Foundation Sponsored by: NetGate TAG: IPSEC-HEAD Issue: #4841
* MFC r262993:Luiz Otavio O Souza2015-10-201-1/+1
| | | | | | | | | | | | some minor clean up.. Always _ZERO memory so mtx_init won't panic... use the proper macro instead of hand rolling it... Reviewed by: jhb (only the malloc change) MFC after: 1 week TAG: IPSEC-HEAD Issue: #4841
* MFC r261251:Luiz Otavio O Souza2015-10-201-12/+55
| | | | | | | | | | | | | | | | | Prevent races in accesses of the software crypto session array. swcr_newsession can change the pointer for swcr_sessions which races with swcr_process which is looking up entries in this array. Add a rwlock that protects changes to the array pointer so that swcr_newsession and swcr_process no longer race. Original patch by: Steve O'Hara-Smith <Steve.OHaraSmith@isilon.com> Reviewed by: jmg Sponsored by: EMC / Isilon Storage Division TAG: IPSEC-HEAD Issue: #4841
* Revert AESNI patches.Luiz Otavio O Souza2015-10-201-218/+5
| | | | | | | | | Revert "Importing pfSense patch aesgcm.soft.1.patch" This reverts commit 46e99a8858f1c843c1774e472c11d422ca2163ae. TAG: IPSEC-HEAD Issue: #4841
* Importing pfSense patch aesgcm.soft.1.patchRenato Botelho2015-08-171-5/+218
|
* Let cryptosoft(4) add its pseudo-device with a specific unit number and itsmarius2010-11-141-2/+2
| | | | | | | | | | | probe method return BUS_PROBE_NOWILDCARD so it doesn't get attached to real devices hanging off of nexus(4) with no specific devclass set. Actually, the more desirable fix for this would be to get rid of the newbus interface of cryptosoft(4) altogether but apparently crypto(9) was written with support for cryptographic hardware in mind so that approach would require some KPI breaking changes which don't seem worth it. MFC after: 1 week
* Add support for AES-XTS.pjd2010-09-231-5/+59
| | | | | Obtained from: OpenBSD MFC after: 1 week
* Add comments trying to explain what bad things happen here, i.e.bz2010-01-091-1/+18
| | | | | | | | | | | how hashed MD5/SHA are implemented, abusing Final() for padding and sw_octx to transport the key from the beginning to the end. Enlightened about what was going on here by: cperciva Reviewed by: cperciva MFC After: 3 days X-MFC with: r187826 PR: kern/126468
* In case the compression result is the same size as the orignal version,bz2009-11-291-1/+1
| | | | | | | | | | | | the compression was useless as well. Make sure to not update the data and return, else we would waste resources when decompressing. This also avoids the copyback() changing data other consumers like xform_ipcomp.c would have ignored because of no win and sent out without noting that compression was used, resulting in invalid packets at the receiver. MFC after: 5 days
* Fix return type for detach routine (should be int)imp2009-02-051-2/+3
| | | | Fix first parameter for identify routine (should be driver_t *)
* While OpenBSD's crypto/ framework has sha1 and md5 implementations thatbz2009-01-281-1/+6
| | | | | | | | | can cope with a result buffer of NULL in the "Final" function, we cannot. Thus pass in a temporary buffer long enough for either md5 or sha1 results so that we do not panic. PR: bin/126468 MFC after: 1 week
* Don't hang if encrypting/decrypting using struct iovecs where one of thedfr2008-10-301-0/+4
| | | | iovecs ends on a crypto block boundary.
* Retire the MALLOC and FREE macros. They are an abomination unto style(9).des2008-10-231-7/+7
| | | | MFC after: 3 months
* Integrate the Camellia Block Cipher. For more information see RFC 4132gnn2007-05-091-0/+6
| | | | | | | and its bibliography. Submitted by: Tomoyuki Okazaki <okazaki at kick dot gr dot jp> MFC after: 1 month
* Overhaul driver/subsystem api's:sam2007-03-211-45/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | o make all crypto drivers have a device_t; pseudo drivers like the s/w crypto driver synthesize one o change the api between the crypto subsystem and drivers to use kobj; cryptodev_if.m defines this api o use the fact that all crypto drivers now have a device_t to add support for specifying which of several potential devices to use when doing crypto operations o add new ioctls that allow user apps to select a specific crypto device to use (previous ioctls maintained for compatibility) o overhaul crypto subsystem code to eliminate lots of cruft and hide implementation details from drivers o bring in numerous fixes from Michale Richardson/hifn; mostly for 795x parts o add an optional mechanism for mmap'ing the hifn 795x public key h/w to user space for use by openssl (not enabled by default) o update crypto test tools to use new ioctl's and add cmd line options to specify a device to use for tests These changes will also enable much future work on improving the core crypto subsystem; including proper load balancing and interposing code between the core and drivers to dispatch small operations to the s/w driver as appropriate. These changes were instigated by the work of Michael Richardson. Reviewed by: pjd Approved by: re
* Use newly added functions to simplify the code.pjd2006-06-041-82/+54
|
* Move COPYDATA() and COPYBACK() macros to cryptodev.h, they will be usedpjd2006-06-041-27/+0
| | | | in padlock(4) as well.
* Rename HMAC_BLOCK_MAXLEN to HMAC_MAX_BLOCK_LEN to be consistent withpjd2006-06-041-4/+4
| | | | EALG_MAX_BLOCK_LEN.
* Rename AALG_MAX_RESULT_LEN to HASH_MAX_LEN to look more constent withpjd2006-06-041-1/+1
| | | | other defines.
* Kill an unused argument.pjd2006-06-041-5/+5
|
* - Fix a very old bug in HMAC/SHA{384,512}. When HMAC is using SHA384pjd2006-05-171-89/+147
| | | | | | | | | | | | | | | | | | | | | | | | | | | | or SHA512, the blocksize is 128 bytes, not 64 bytes as anywhere else. The bug also exists in NetBSD, OpenBSD and various other independed implementations I look at. - We cannot decide which hash function to use for HMAC based on the key length, because any HMAC function can use any key length. To fix it split CRYPTO_SHA2_HMAC into three algorithm: CRYPTO_SHA2_256_HMAC, CRYPTO_SHA2_384_HMAC and CRYPTO_SHA2_512_HMAC. Those names are consistent with OpenBSD's naming. - Remove authsize field from auth_hash structure. - Allow consumer to define size of hash he wants to receive. This allows to use HMAC not only for IPsec, where 96 bits MAC is requested. The size of requested MAC is defined at newsession time in the cri_mlen field - when 0, entire MAC will be returned. - Add swcr_authprepare() function which prepares authentication key. - Allow to provide key for every authentication operation, not only at newsession time by honoring CRD_F_KEY_EXPLICIT flag. - Make giving key at newsession time optional - don't try to operate on it if its NULL. - Extend COPYBACK()/COPYDATA() macros to handle CRYPTO_BUF_CONTIG buffer type as well. - Accept CRYPTO_BUF_IOV buffer type in swcr_authcompute() as we have cuio_apply() now. - 16 bits for key length (SW_klen) is more than enough. Reviewed by: sam
* - Simplify the code by using arc4rand(9) instead of arc4random(9) in a loop.pjd2006-04-101-22/+3
| | | | | | - Correct a comment. MFC after: 2 weeks
* Fix memory leak which occurs when crypto.ko module is unloaded.pjd2006-03-281-0/+9
| | | | | Discussed with: sam MFC after 3 days
* refer opencrypto/cast.h directly.ume2005-03-111-1/+1
|
* /* -> /*- for license, minor formatting changesimp2005-01-071-1/+1
|
* Add CRD_F_KEY_EXPLICIT which allows the key to be changed perphk2004-02-021-0/+10
| | | | | | | | operation, just like it was possible to change the IV. Currently supported on Hifn and software engines only. Approved by: sam@
* style(9) pass and type fixups.bms2003-12-161-1/+1
| | | | Submitted by: bde
* Push m_apply() and m_getptr() up into the colleciton of standard mbufbms2003-12-151-8/+1
| | | | | | | | routines, and purge them from opencrypto. Reviewed by: sam Obtained from: NetBSD Sponsored by: spc.org
* Add support to eliminate a context switch per crypto op when using thesam2003-06-271-2/+2
| | | | | | | | | | | software crypto device: o record crypto device capabilities in each session id o add a capability that indicates if the crypto driver operates synchronously o tag the software crypto driver as operating synchronously This commit also introduces crypto session id macros that cleanup their construction and querying.
* Use __FBSDID().obrien2003-06-111-1/+3
|
* Change iov_base's type from `char *' to the standard `void *'. Allmike2002-10-111-1/+1
| | | | | uses of iov_base which assume its type is `char *' (in order to do pointer arithmetic) have been updated to cast iov_base to `char *'.
* In-kernel crypto framework derived from openbsd. This facility providessam2002-10-041-0/+1025
a consistent interface to h/w and s/w crypto algorithms for use by the kernel and (for h/w at least) by user-mode apps. Access for user-level code is through a /dev/crypto device that'll eventually be used by openssl to (potentially) accelerate many applications. Coming soon is an IPsec that makes use of this service to accelerate ESP, AH, and IPCOMP protocols. Included here is the "core" crypto support, /dev/crypto driver, various crypto algorithms that are not already present in the KAME crypto area, and support routines used by crypto device drivers. Obtained from: openbsd
OpenPOWER on IntegriCloud