#
303975 |
|
11-Aug-2016 |
gjb |
Copy stable/11@r303970 to releng/11.0 as part of the 11.0-RELEASE cycle.
Prune svn:mergeinfo from the new branch, and rename it to RC1.
Update __FreeBSD_version.
Use the quarterly branch for the default FreeBSD.conf pkg(8) repo and the dvd1.iso packages population.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation |
#
302408 |
|
08-Jul-2016 |
gjb |
Copy head@r302406 to stable/11 as part of the 11.0-RELEASE cycle. Prune svn:mergeinfo from the new branch, as nothing has been merged here.
Additional commits post-branch will follow.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation
|
#
292963 |
|
30-Dec-2015 |
allanjude |
Break up opencrypto/xform.c so it can be reused piecemeal
Keep xform.c as a meta-file including the broken out bits existing code that includes xform.c continues to work as normal
Individual algorithms can now be reused elsewhere, including outside of the kernel
Reviewed by: bapt (previous version), gnn, delphij Approved by: secteam MFC after: 1 week Sponsored by: ScaleEngine Inc. Differential Revision: https://reviews.freebsd.org/D4674
|
#
292782 |
|
27-Dec-2015 |
allanjude |
Replace sys/crypto/sha2/sha2.c with lib/libmd/sha512c.c
cperciva's libmd implementation is 5-30% faster
The same was done for SHA256 previously in r263218
cperciva's implementation was lacking SHA-384 which I implemented, validated against OpenSSL and the NIST documentation
Extend sbin/md5 to create sha384(1)
Chase dependancies on sys/crypto/sha2/sha2.{c,h} and replace them with sha512{c.c,.h}
Reviewed by: cperciva, des, delphij Approved by: secteam, bapt (mentor) MFC after: 2 weeks Sponsored by: ScaleEngine Inc. Differential Revision: https://reviews.freebsd.org/D3929
|
#
275732 |
|
12-Dec-2014 |
jmg |
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
|
#
219026 |
|
25-Feb-2011 |
vanhu |
fixed size of AH_ALEN_MAX, which is 64 bytes for SHA-512.
Obtained from: Matthias Drochner <M.Drochner@fz-juelich.de> MFC after: 3d
|
#
213068 |
|
23-Sep-2010 |
pjd |
Add support for AES-XTS.
Obtained from: OpenBSD MFC after: 1 week
|
#
169425 |
|
09-May-2007 |
gnn |
Integrate the Camellia Block Cipher. For more information see RFC 4132 and its bibliography.
Submitted by: Tomoyuki Okazaki <okazaki at kick dot gr dot jp> MFC after: 1 month
|
#
158703 |
|
17-May-2006 |
pjd |
- Fix a very old bug in HMAC/SHA{384,512}. When HMAC is using SHA384 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
|
#
139825 |
|
07-Jan-2005 |
imp |
/* -> /*- for license, minor formatting changes
|
#
104476 |
|
04-Oct-2002 |
sam |
In-kernel crypto framework derived from openbsd. This facility provides 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
|