FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=releng%2F11.0 2016-08-08T19:43:07Z 2016-08-08T19:43:07Z Bryan Drewery bdrewery@FreeBSD.org 2016-08-08T19:43:07Z urn:sha1:c81844ff3b7fae2daf780f307a2099813f18a7d1 opencrypto AES-ICM: Fix heap corruption typo PR: 204009 Approved by: re (kib) 2016-05-06T23:37:19Z Pedro F. Giffuni pfg@FreeBSD.org 2016-05-06T23:37:19Z urn:sha1:1762773d796f40252206ff4ed94c1ea776735c42 No functional change. Reviewed by: jmg 2015-12-30T22:43:07Z Allan Jude allanjude@FreeBSD.org 2015-12-30T22:43:07Z urn:sha1:2155bb238f8245c92772441f964d0e23247bb464 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 2015-12-27T17:33:59Z Allan Jude allanjude@FreeBSD.org 2015-12-27T17:33:59Z urn:sha1:7a3f5d11fb3873674a1f7e27bcc9a5f7ce279390 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 2015-11-22T02:01:01Z Mark Johnston markj@FreeBSD.org 2015-11-22T02:01:01Z urn:sha1:7672ca059a716f41cd64daef56493a75d661b166 As of r258541, KDTRACE_HOOKS is defined in opt_global.h, so opt_kdtrace.h is not needed when defining SDT(9) probes. 2015-11-16T07:10:42Z Andrey V. Elsukov ae@FreeBSD.org 2015-11-16T07:10:42Z urn:sha1:0c80e7df436b13daaa144f1228c8de445740822f Set zero ivsize for enc_xform_null and remove special handling from xform_esp.c. Reviewed by: gnn Differential Revision: https://reviews.freebsd.org/D1503 2015-08-04T17:47:11Z John-Mark Gurney jmg@FreeBSD.org 2015-08-04T17:47:11Z urn:sha1:a2bc81bf7cb660cadbbbcea20d92234e725177b7 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 2015-07-14T07:45:18Z John-Mark Gurney jmg@FreeBSD.org 2015-07-14T07:45:18Z urn:sha1:577f7474b06377494e58b6e7cdceb174938213ec Though confusing, GCM using ICM_BLOCK_LEN, but ICM does not is correct... GCM is built on ICM, but uses a function other than swcr_encdec... swcr_encdec cannot handle partial blocks which is why it must still use AES_BLOCK_LEN and is why XTS was broken by the commit... Thanks to the tests for helping sure I didn't break GCM w/ an earlier patch... I did run the tests w/o this patch, and need to figure out why they did not fail, clearly more tests are needed... Prodded by: peter 2015-07-09T18:16:35Z George V. Neville-Neil gnn@FreeBSD.org 2015-07-09T18:16:35Z urn:sha1:16de9ac1b59c2b42e955a36b058e2f342bd6bb7f mode and with hardware support on systems that have AESNI instructions. Differential Revision: D2936 Reviewed by: jmg, eri, cognet Sponsored by: Rubicon Communications (Netgate) 2015-07-07T18:45:32Z John-Mark Gurney jmg@FreeBSD.org 2015-07-07T18:45:32Z urn:sha1:748a12e2c345e87e750c99a50f252e67bc988b13 doing this memory allocation... Reviewed by: ae