History log of /src/sys/crypto |
Revision | Date | Author | Comments |
1.4 | 27-Oct-2006 |
christos | Merge kernel and userland rmd160 and sha2 implementation. XXX: We still install rmd160.h and sha2.h in /usr/include/crypto, unlike the other hash functions which get installed in /usr/include for compatibility.
|
1.3 | 11-Dec-2005 |
christos | branches: 1.3.18; 1.3.22; 1.3.24; merge ktrace-lwp.
|
1.2 | 24-Sep-2005 |
elad | branches: 1.2.6; Install rmd160.h to /usr/include/crypto.
|
1.1 | 20-Aug-2005 |
elad | branches: 1.1.2; Install sha2.h to /usr/include/crypto.
|
1.1.2.2 | 08-Sep-2005 |
tron | Apply patch (requested by elad in ticket #743): Introduce SHA2 hashing routines in userland, including the common helper routines.
|
1.1.2.1 | 20-Aug-2005 |
tron | file Makefile was added on branch netbsd-3 on 2005-09-08 19:15:44 +0000
|
1.2.6.2 | 10-Nov-2005 |
skrll | Sync with HEAD. Here we go again...
|
1.2.6.1 | 24-Sep-2005 |
skrll | file Makefile was added on branch ktrace-lwp on 2005-11-10 14:02:59 +0000
|
1.3.24.1 | 10-Dec-2006 |
yamt | sync with head.
|
1.3.22.1 | 18-Nov-2006 |
ad | Sync with head.
|
1.3.18.3 | 30-Dec-2006 |
yamt | sync with head.
|
1.3.18.2 | 21-Jun-2006 |
yamt | sync with head.
|
1.3.18.1 | 11-Dec-2005 |
yamt | file Makefile was added on branch yamt-lazymbuf on 2006-06-21 15:02:11 +0000
|
1.7 | 17-Oct-2021 |
jmcneill | Upgrade self-test passed messages from verbose to debug.
|
1.6 | 14-Apr-2021 |
christos | use an enum instead of constant variables so that they work in CTASSERT.
|
1.5 | 26-Jul-2020 |
riastradh | branches: 1.5.4; Simplify internal Poly1305 API in adiantum.c.
Should be slightly faster this way too.
|
1.4 | 25-Jul-2020 |
riastradh | Fix typo in comment; match the paper's notation.
No functional change.
|
1.3 | 25-Jul-2020 |
riastradh | Convert crypto/adiantum to use new ChaCha API.
|
1.2 | 25-Jul-2020 |
riastradh | Omit useless AES call.
This must have been a vestige from editing that I never got around to removing, oops. Should speed up adiantum encryption a wee bit!
|
1.1 | 29-Jun-2020 |
riastradh | New cgd cipher adiantum.
Adiantum is a wide-block cipher, built out of AES, XChaCha12, Poly1305, and NH, defined in
Paul Crowley and Eric Biggers, `Adiantum: length-preserving encryption for entry-level processors', IACR Transactions on Symmetric Cryptology 2018(4), pp. 39--61.
Adiantum provides better security than a narrow-block cipher with CBC or XTS, because every bit of each sector affects every other bit, whereas with CBC each block of plaintext only affects the following blocks of ciphertext in the disk sector, and with XTS each block of plaintext only affects its own block of ciphertext and nothing else.
Adiantum generally provides much better performance than constant-time AES-CBC or AES-XTS software do without hardware support, and performance comparable to or better than the variable-time (i.e., leaky) AES-CBC and AES-XTS software we had before. (Note: Adiantum also uses AES as a subroutine, but only once per disk sector. It takes only a small fraction of the time spent by Adiantum, so there's relatively little performance impact to using constant-time AES software over using variable-time AES software for it.)
Adiantum naturally scales to essentially arbitrary disk sector sizes; sizes >=1024-bytes take the most advantage of Adiantum's design for performance, so 4096-byte sectors would be a natural choice if we taught cgd to change the disk sector size. (However, it's a different cipher for each disk sector size, so it _must_ be a cgd parameter.)
The paper presents a similar construction HPolyC. The salient difference is that HPolyC uses Poly1305 directly, whereas Adiantum uses Poly1395(NH(...)). NH is annoying because it requires a 1072-byte key, which means the test vectors are ginormous, and changing keys is costly; HPolyC avoids these shortcomings by using Poly1305 directly, but HPolyC is measurably slower, costing about 1.5x what Adiantum costs on 4096-byte sectors.
For the purposes of cgd, we will reuse each key for many messages, and there will be very few keys in total (one per cgd volume) so -- except for the annoying verbosity of test vectors -- the tradeoff weighs in the favour of Adiantum, especially if we teach cgd to do >>512-byte sectors.
For now, everything that Adiantum needs beyond what's already in the kernel is gathered into a single file, including NH, Poly1305, and XChaCha12. We can split those out -- and reuse them, and provide MD tuned implementations, and so on -- as needed; this is just a first pass to get Adiantum implemented for experimentation.
|
1.5.4.1 | 17-Apr-2021 |
thorpej | Sync with HEAD.
|
1.1 | 29-Jun-2020 |
riastradh | New cgd cipher adiantum.
Adiantum is a wide-block cipher, built out of AES, XChaCha12, Poly1305, and NH, defined in
Paul Crowley and Eric Biggers, `Adiantum: length-preserving encryption for entry-level processors', IACR Transactions on Symmetric Cryptology 2018(4), pp. 39--61.
Adiantum provides better security than a narrow-block cipher with CBC or XTS, because every bit of each sector affects every other bit, whereas with CBC each block of plaintext only affects the following blocks of ciphertext in the disk sector, and with XTS each block of plaintext only affects its own block of ciphertext and nothing else.
Adiantum generally provides much better performance than constant-time AES-CBC or AES-XTS software do without hardware support, and performance comparable to or better than the variable-time (i.e., leaky) AES-CBC and AES-XTS software we had before. (Note: Adiantum also uses AES as a subroutine, but only once per disk sector. It takes only a small fraction of the time spent by Adiantum, so there's relatively little performance impact to using constant-time AES software over using variable-time AES software for it.)
Adiantum naturally scales to essentially arbitrary disk sector sizes; sizes >=1024-bytes take the most advantage of Adiantum's design for performance, so 4096-byte sectors would be a natural choice if we taught cgd to change the disk sector size. (However, it's a different cipher for each disk sector size, so it _must_ be a cgd parameter.)
The paper presents a similar construction HPolyC. The salient difference is that HPolyC uses Poly1305 directly, whereas Adiantum uses Poly1395(NH(...)). NH is annoying because it requires a 1072-byte key, which means the test vectors are ginormous, and changing keys is costly; HPolyC avoids these shortcomings by using Poly1305 directly, but HPolyC is measurably slower, costing about 1.5x what Adiantum costs on 4096-byte sectors.
For the purposes of cgd, we will reuse each key for many messages, and there will be very few keys in total (one per cgd volume) so -- except for the annoying verbosity of test vectors -- the tradeoff weighs in the favour of Adiantum, especially if we teach cgd to do >>512-byte sectors.
For now, everything that Adiantum needs beyond what's already in the kernel is gathered into a single file, including NH, Poly1305, and XChaCha12. We can split those out -- and reuse them, and provide MD tuned implementations, and so on -- as needed; this is just a first pass to get Adiantum implemented for experimentation.
|
1.1 | 29-Jun-2020 |
riastradh | New cgd cipher adiantum.
Adiantum is a wide-block cipher, built out of AES, XChaCha12, Poly1305, and NH, defined in
Paul Crowley and Eric Biggers, `Adiantum: length-preserving encryption for entry-level processors', IACR Transactions on Symmetric Cryptology 2018(4), pp. 39--61.
Adiantum provides better security than a narrow-block cipher with CBC or XTS, because every bit of each sector affects every other bit, whereas with CBC each block of plaintext only affects the following blocks of ciphertext in the disk sector, and with XTS each block of plaintext only affects its own block of ciphertext and nothing else.
Adiantum generally provides much better performance than constant-time AES-CBC or AES-XTS software do without hardware support, and performance comparable to or better than the variable-time (i.e., leaky) AES-CBC and AES-XTS software we had before. (Note: Adiantum also uses AES as a subroutine, but only once per disk sector. It takes only a small fraction of the time spent by Adiantum, so there's relatively little performance impact to using constant-time AES software over using variable-time AES software for it.)
Adiantum naturally scales to essentially arbitrary disk sector sizes; sizes >=1024-bytes take the most advantage of Adiantum's design for performance, so 4096-byte sectors would be a natural choice if we taught cgd to change the disk sector size. (However, it's a different cipher for each disk sector size, so it _must_ be a cgd parameter.)
The paper presents a similar construction HPolyC. The salient difference is that HPolyC uses Poly1305 directly, whereas Adiantum uses Poly1395(NH(...)). NH is annoying because it requires a 1072-byte key, which means the test vectors are ginormous, and changing keys is costly; HPolyC avoids these shortcomings by using Poly1305 directly, but HPolyC is measurably slower, costing about 1.5x what Adiantum costs on 4096-byte sectors.
For the purposes of cgd, we will reuse each key for many messages, and there will be very few keys in total (one per cgd volume) so -- except for the annoying verbosity of test vectors -- the tradeoff weighs in the favour of Adiantum, especially if we teach cgd to do >>512-byte sectors.
For now, everything that Adiantum needs beyond what's already in the kernel is gathered into a single file, including NH, Poly1305, and XChaCha12. We can split those out -- and reuse them, and provide MD tuned implementations, and so on -- as needed; this is just a first pass to get Adiantum implemented for experimentation.
|
1.3 | 25-Jul-2020 |
riastradh | Convert crypto/adiantum to use new ChaCha API.
|
1.2 | 25-Jul-2020 |
riastradh | Note dependency of adiantum on aes.
Forgot this a while back.
|
1.1 | 29-Jun-2020 |
riastradh | New cgd cipher adiantum.
Adiantum is a wide-block cipher, built out of AES, XChaCha12, Poly1305, and NH, defined in
Paul Crowley and Eric Biggers, `Adiantum: length-preserving encryption for entry-level processors', IACR Transactions on Symmetric Cryptology 2018(4), pp. 39--61.
Adiantum provides better security than a narrow-block cipher with CBC or XTS, because every bit of each sector affects every other bit, whereas with CBC each block of plaintext only affects the following blocks of ciphertext in the disk sector, and with XTS each block of plaintext only affects its own block of ciphertext and nothing else.
Adiantum generally provides much better performance than constant-time AES-CBC or AES-XTS software do without hardware support, and performance comparable to or better than the variable-time (i.e., leaky) AES-CBC and AES-XTS software we had before. (Note: Adiantum also uses AES as a subroutine, but only once per disk sector. It takes only a small fraction of the time spent by Adiantum, so there's relatively little performance impact to using constant-time AES software over using variable-time AES software for it.)
Adiantum naturally scales to essentially arbitrary disk sector sizes; sizes >=1024-bytes take the most advantage of Adiantum's design for performance, so 4096-byte sectors would be a natural choice if we taught cgd to change the disk sector size. (However, it's a different cipher for each disk sector size, so it _must_ be a cgd parameter.)
The paper presents a similar construction HPolyC. The salient difference is that HPolyC uses Poly1305 directly, whereas Adiantum uses Poly1395(NH(...)). NH is annoying because it requires a 1072-byte key, which means the test vectors are ginormous, and changing keys is costly; HPolyC avoids these shortcomings by using Poly1305 directly, but HPolyC is measurably slower, costing about 1.5x what Adiantum costs on 4096-byte sectors.
For the purposes of cgd, we will reuse each key for many messages, and there will be very few keys in total (one per cgd volume) so -- except for the annoying verbosity of test vectors -- the tradeoff weighs in the favour of Adiantum, especially if we teach cgd to do >>512-byte sectors.
For now, everything that Adiantum needs beyond what's already in the kernel is gathered into a single file, including NH, Poly1305, and XChaCha12. We can split those out -- and reuse them, and provide MD tuned implementations, and so on -- as needed; this is just a first pass to get Adiantum implemented for experimentation.
|
1.4 | 25-Jul-2020 |
riastradh | Split aes_cbc_* and aes_xts_* into their own header files.
aes.h will remain just for key setup; any particular construction using AES can have its own header file so we can have many of them without rebuilding everything AES-related whenever one of them changes.
(Planning to add AES-CCM and AES-GCM too.)
|
1.3 | 25-Jul-2020 |
riastradh | Split aes_impl declarations out into aes_impl.h.
This will make it less painful to add more operations to struct aes_impl without having to recompile everything that just uses the block cipher directly or similar.
|
1.2 | 29-Jun-2020 |
riastradh | New SSE2-based bitsliced AES implementation.
This should work on essentially all x86 CPUs of the last two decades, and may improve throughput over the portable C aes_ct implementation from BearSSL by
(a) reducing the number of vector operations in sequence, and (b) batching four rather than two blocks in parallel.
Derived from BearSSL'S aes_ct64 implementation adjusted so that where aes_ct64 uses 64-bit q[0],...,q[7], aes_sse2 uses (q[0], q[4]), ..., (q[3], q[7]), each tuple representing a pair of 64-bit quantities stacked in a single 128-bit register. This translation was done very naively, and mostly reduces the cost of ShiftRows and data movement without doing anything to address the S-box or (Inv)MixColumns, which spread all 64-bit quantities across separate registers and ignore the upper halves.
Unfortunately, SSE2 -- which is all that is guaranteed on all amd64 CPUs -- doesn't have PSHUFB, which would help out a lot more. For example, vpaes relies on that. Perhaps there are enough CPUs out there with PSHUFB but not AES-NI to make it worthwhile to import or adapt vpaes too.
Note: This includes local definitions of various Intel compiler intrinsics for gcc and clang in terms of their __builtin_* &c., because the necessary header files are not available during the kernel build. This is a kludge -- we should fix it properly; the present approach is expedient but not ideal.
|
1.1 | 29-Jun-2020 |
riastradh | Rework AES in kernel to finally address CVE-2005-1797.
1. Rip out old variable-time reference implementation. 2. Replace it by BearSSL's constant-time 32-bit logic. => Obtained from commit dda1f8a0c46e15b4a235163470ff700b2f13dcc5. => We could conditionally adopt the 64-bit logic too, which would likely give a modest performance boost on 64-bit platforms without AES-NI, but that's a bit more trouble. 3. Select the AES implementation at boot-time; allow an MD override. => Use self-tests to verify basic correctness at boot. => The implementation selection policy is rather rudimentary at the moment but it is isolated to one place so it's easy to change later on.
This (a) plugs a host of timing attacks on, e.g., cgd, and (b) paves the way to take advantage of CPU support for AES -- both things we should've done a decade ago. Downside: Computing AES takes 2-3x the CPU time. But that's what hardware support will be coming for.
Rudimentary measurement of performance impact done by:
mount -t tmpfs tmpfs /tmp dd if=/dev/zero of=/tmp/disk bs=1m count=512 vnconfig -cv vnd0 /tmp/disk cgdconfig -s cgd0 /dev/vnd0 aes-cbc 256 < /dev/zero dd if=/dev/rcgd0d of=/dev/null bs=64k dd if=/dev/zero of=/dev/rcgd0d bs=64k
The AES-CBC encryption performance impact is closer to 3x because it is inherently sequential; the AES-CBC decryption impact is closer to 2x because the bitsliced AES logic can process two blocks at once.
Discussed on tech-kern:
https://mail-index.NetBSD.org/tech-kern/2020/06/18/msg026505.html
|
1.4 | 25-Jul-2020 |
riastradh | Implement AES-CCM with BearSSL's bitsliced 32-bit aes_ct.
|
1.3 | 25-Jul-2020 |
riastradh | Split aes_impl declarations out into aes_impl.h.
This will make it less painful to add more operations to struct aes_impl without having to recompile everything that just uses the block cipher directly or similar.
|
1.2 | 30-Jun-2020 |
riastradh | New test sys/crypto/aes/t_aes.
Runs aes_selftest on all kernel AES implementations supported on the current hardware, not just the preferred one.
|
1.1 | 29-Jun-2020 |
riastradh | Rework AES in kernel to finally address CVE-2005-1797.
1. Rip out old variable-time reference implementation. 2. Replace it by BearSSL's constant-time 32-bit logic. => Obtained from commit dda1f8a0c46e15b4a235163470ff700b2f13dcc5. => We could conditionally adopt the 64-bit logic too, which would likely give a modest performance boost on 64-bit platforms without AES-NI, but that's a bit more trouble. 3. Select the AES implementation at boot-time; allow an MD override. => Use self-tests to verify basic correctness at boot. => The implementation selection policy is rather rudimentary at the moment but it is isolated to one place so it's easy to change later on.
This (a) plugs a host of timing attacks on, e.g., cgd, and (b) paves the way to take advantage of CPU support for AES -- both things we should've done a decade ago. Downside: Computing AES takes 2-3x the CPU time. But that's what hardware support will be coming for.
Rudimentary measurement of performance impact done by:
mount -t tmpfs tmpfs /tmp dd if=/dev/zero of=/tmp/disk bs=1m count=512 vnconfig -cv vnd0 /tmp/disk cgdconfig -s cgd0 /dev/vnd0 aes-cbc 256 < /dev/zero dd if=/dev/rcgd0d of=/dev/null bs=64k dd if=/dev/zero of=/dev/rcgd0d bs=64k
The AES-CBC encryption performance impact is closer to 3x because it is inherently sequential; the AES-CBC decryption impact is closer to 2x because the bitsliced AES logic can process two blocks at once.
Discussed on tech-kern:
https://mail-index.NetBSD.org/tech-kern/2020/06/18/msg026505.html
|
1.2 | 29-Jun-2020 |
riastradh | Provide the standard AES key schedule.
Different AES implementations prefer different variations on it, but some of them -- notably VIA -- require the standard key schedule to be available and don't provide hardware support for computing it themselves. So adapt BearSSL's logic to generate the standard key schedule (and decryption keys, with InvMixColumns), rather than the bitsliced key schedule that BearSSL uses natively.
|
1.1 | 29-Jun-2020 |
riastradh | Rework AES in kernel to finally address CVE-2005-1797.
1. Rip out old variable-time reference implementation. 2. Replace it by BearSSL's constant-time 32-bit logic. => Obtained from commit dda1f8a0c46e15b4a235163470ff700b2f13dcc5. => We could conditionally adopt the 64-bit logic too, which would likely give a modest performance boost on 64-bit platforms without AES-NI, but that's a bit more trouble. 3. Select the AES implementation at boot-time; allow an MD override. => Use self-tests to verify basic correctness at boot. => The implementation selection policy is rather rudimentary at the moment but it is isolated to one place so it's easy to change later on.
This (a) plugs a host of timing attacks on, e.g., cgd, and (b) paves the way to take advantage of CPU support for AES -- both things we should've done a decade ago. Downside: Computing AES takes 2-3x the CPU time. But that's what hardware support will be coming for.
Rudimentary measurement of performance impact done by:
mount -t tmpfs tmpfs /tmp dd if=/dev/zero of=/tmp/disk bs=1m count=512 vnconfig -cv vnd0 /tmp/disk cgdconfig -s cgd0 /dev/vnd0 aes-cbc 256 < /dev/zero dd if=/dev/rcgd0d of=/dev/null bs=64k dd if=/dev/zero of=/dev/rcgd0d bs=64k
The AES-CBC encryption performance impact is closer to 3x because it is inherently sequential; the AES-CBC decryption impact is closer to 2x because the bitsliced AES logic can process two blocks at once.
Discussed on tech-kern:
https://mail-index.NetBSD.org/tech-kern/2020/06/18/msg026505.html
|
1.1 | 25-Jul-2020 |
riastradh | Split aes_cbc_* and aes_xts_* into their own header files.
aes.h will remain just for key setup; any particular construction using AES can have its own header file so we can have many of them without rebuilding everything AES-related whenever one of them changes.
(Planning to add AES-CCM and AES-GCM too.)
|
1.6 | 17-Oct-2021 |
jmcneill | Upgrade self-test passed messages from verbose to debug.
|
1.5 | 10-Aug-2020 |
rin | Add hack to compile aes_ccm_tag() with -O0 for m68k for GCC8.
GCC 8 miscompiles aes_ccm_tag() for m68k with optimization level -O[12], which results in failure in aes_ccm_selftest():
| aes_ccm_selftest: tag 0: 8 bytes @ 0x4d3e38 | 03 80 5f 08 22 6f cb fe | .._."o.. | aes_ccm_selftest: verify 0 failed | ... | WARNING: module error: built-in module aes_ccm failed its MODULE_CMD_INIT, error 5
This is observed for amiga (A1200, 68060), mac68k (Quadra 840AV, 68040), and luna68k (nono, 68030 emulator). However, it is not for sun3 (TME, 68020 emulator) and sun2 (TME, 68010 emulator). At the moment, it is unclear whether this is due to differences b/w 68010-20 vs 68030-60, or something wrong with TME.
|
1.4 | 27-Jul-2020 |
riastradh | Gather auth[16] and ctr[16] into one authctr[32].
Should appease clang.
|
1.3 | 26-Jul-2020 |
riastradh | Ensure aes_ccm module init runs after aes module init.
Otherwise the AES implementation might not be selected early enough.
|
1.2 | 25-Jul-2020 |
riastradh | Push CBC-MAC and CCM block updates into the aes_impl API.
This should help reduce the setup and teardown overhead (enabling and disabling fpu, or expanding bitsliced keys) for CCM, as used in 802.11 WPA2 CCMP. But all the fiddly formatting details remain in aes_ccm.c to reduce the effort of implementing it -- at the cost of a handful additional setups and teardowns per message.
Not yet implemented by any of the aes_impls, so leave a fallback that just calls aes_enc for now. This should be removed when all of the aes_impls provide CBC-MAC and CCM block updates.
|
1.1 | 25-Jul-2020 |
riastradh | New aes_ccm API.
Intended for use in net80211 for WPA2 CCMP.
|
1.2 | 27-Jul-2020 |
riastradh | Gather auth[16] and ctr[16] into one authctr[32].
Should appease clang.
|
1.1 | 25-Jul-2020 |
riastradh | New aes_ccm API.
Intended for use in net80211 for WPA2 CCMP.
|
1.1 | 25-Jul-2020 |
riastradh | New aes_ccm API.
Intended for use in net80211 for WPA2 CCMP.
|
1.1 | 25-Jul-2020 |
riastradh | New aes_ccm API.
Intended for use in net80211 for WPA2 CCMP.
|
1.3 | 30-Jun-2020 |
riastradh | New test sys/crypto/aes/t_aes.
Runs aes_selftest on all kernel AES implementations supported on the current hardware, not just the preferred one.
|
1.2 | 29-Jun-2020 |
riastradh | Provide the standard AES key schedule.
Different AES implementations prefer different variations on it, but some of them -- notably VIA -- require the standard key schedule to be available and don't provide hardware support for computing it themselves. So adapt BearSSL's logic to generate the standard key schedule (and decryption keys, with InvMixColumns), rather than the bitsliced key schedule that BearSSL uses natively.
|
1.1 | 29-Jun-2020 |
riastradh | Rework AES in kernel to finally address CVE-2005-1797.
1. Rip out old variable-time reference implementation. 2. Replace it by BearSSL's constant-time 32-bit logic. => Obtained from commit dda1f8a0c46e15b4a235163470ff700b2f13dcc5. => We could conditionally adopt the 64-bit logic too, which would likely give a modest performance boost on 64-bit platforms without AES-NI, but that's a bit more trouble. 3. Select the AES implementation at boot-time; allow an MD override. => Use self-tests to verify basic correctness at boot. => The implementation selection policy is rather rudimentary at the moment but it is isolated to one place so it's easy to change later on.
This (a) plugs a host of timing attacks on, e.g., cgd, and (b) paves the way to take advantage of CPU support for AES -- both things we should've done a decade ago. Downside: Computing AES takes 2-3x the CPU time. But that's what hardware support will be coming for.
Rudimentary measurement of performance impact done by:
mount -t tmpfs tmpfs /tmp dd if=/dev/zero of=/tmp/disk bs=1m count=512 vnconfig -cv vnd0 /tmp/disk cgdconfig -s cgd0 /dev/vnd0 aes-cbc 256 < /dev/zero dd if=/dev/rcgd0d of=/dev/null bs=64k dd if=/dev/zero of=/dev/rcgd0d bs=64k
The AES-CBC encryption performance impact is closer to 3x because it is inherently sequential; the AES-CBC decryption impact is closer to 2x because the bitsliced AES logic can process two blocks at once.
Discussed on tech-kern:
https://mail-index.NetBSD.org/tech-kern/2020/06/18/msg026505.html
|
1.2 | 29-Jun-2020 |
riastradh | Provide the standard AES key schedule.
Different AES implementations prefer different variations on it, but some of them -- notably VIA -- require the standard key schedule to be available and don't provide hardware support for computing it themselves. So adapt BearSSL's logic to generate the standard key schedule (and decryption keys, with InvMixColumns), rather than the bitsliced key schedule that BearSSL uses natively.
|
1.1 | 29-Jun-2020 |
riastradh | Rework AES in kernel to finally address CVE-2005-1797.
1. Rip out old variable-time reference implementation. 2. Replace it by BearSSL's constant-time 32-bit logic. => Obtained from commit dda1f8a0c46e15b4a235163470ff700b2f13dcc5. => We could conditionally adopt the 64-bit logic too, which would likely give a modest performance boost on 64-bit platforms without AES-NI, but that's a bit more trouble. 3. Select the AES implementation at boot-time; allow an MD override. => Use self-tests to verify basic correctness at boot. => The implementation selection policy is rather rudimentary at the moment but it is isolated to one place so it's easy to change later on.
This (a) plugs a host of timing attacks on, e.g., cgd, and (b) paves the way to take advantage of CPU support for AES -- both things we should've done a decade ago. Downside: Computing AES takes 2-3x the CPU time. But that's what hardware support will be coming for.
Rudimentary measurement of performance impact done by:
mount -t tmpfs tmpfs /tmp dd if=/dev/zero of=/tmp/disk bs=1m count=512 vnconfig -cv vnd0 /tmp/disk cgdconfig -s cgd0 /dev/vnd0 aes-cbc 256 < /dev/zero dd if=/dev/rcgd0d of=/dev/null bs=64k dd if=/dev/zero of=/dev/rcgd0d bs=64k
The AES-CBC encryption performance impact is closer to 3x because it is inherently sequential; the AES-CBC decryption impact is closer to 2x because the bitsliced AES logic can process two blocks at once.
Discussed on tech-kern:
https://mail-index.NetBSD.org/tech-kern/2020/06/18/msg026505.html
|
1.1 | 29-Jun-2020 |
riastradh | Rework AES in kernel to finally address CVE-2005-1797.
1. Rip out old variable-time reference implementation. 2. Replace it by BearSSL's constant-time 32-bit logic. => Obtained from commit dda1f8a0c46e15b4a235163470ff700b2f13dcc5. => We could conditionally adopt the 64-bit logic too, which would likely give a modest performance boost on 64-bit platforms without AES-NI, but that's a bit more trouble. 3. Select the AES implementation at boot-time; allow an MD override. => Use self-tests to verify basic correctness at boot. => The implementation selection policy is rather rudimentary at the moment but it is isolated to one place so it's easy to change later on.
This (a) plugs a host of timing attacks on, e.g., cgd, and (b) paves the way to take advantage of CPU support for AES -- both things we should've done a decade ago. Downside: Computing AES takes 2-3x the CPU time. But that's what hardware support will be coming for.
Rudimentary measurement of performance impact done by:
mount -t tmpfs tmpfs /tmp dd if=/dev/zero of=/tmp/disk bs=1m count=512 vnconfig -cv vnd0 /tmp/disk cgdconfig -s cgd0 /dev/vnd0 aes-cbc 256 < /dev/zero dd if=/dev/rcgd0d of=/dev/null bs=64k dd if=/dev/zero of=/dev/rcgd0d bs=64k
The AES-CBC encryption performance impact is closer to 3x because it is inherently sequential; the AES-CBC decryption impact is closer to 2x because the bitsliced AES logic can process two blocks at once.
Discussed on tech-kern:
https://mail-index.NetBSD.org/tech-kern/2020/06/18/msg026505.html
|
1.10 | 05-Nov-2022 |
jmcneill | Make aes and chacha prints debug only.
|
1.9 | 27-Jul-2020 |
riastradh | New sysctl subtree kern.crypto.
kern.crypto.aes.selected (formerly hw.aes_impl) kern.crypto.chacha.selected (formerly hw.chacha_impl)
XXX Should maybe deduplicate creation of kern.crypto.
|
1.8 | 25-Jul-2020 |
riastradh | Make aes boot message verbose-only.
|
1.7 | 25-Jul-2020 |
riastradh | Remove now-needless AES-CCM fallback logic.
These paths are no longer exercised because all of the aes_impls now do the AES-CCM operations.
|
1.6 | 25-Jul-2020 |
riastradh | Push CBC-MAC and CCM block updates into the aes_impl API.
This should help reduce the setup and teardown overhead (enabling and disabling fpu, or expanding bitsliced keys) for CCM, as used in 802.11 WPA2 CCMP. But all the fiddly formatting details remain in aes_ccm.c to reduce the effort of implementing it -- at the cost of a handful additional setups and teardowns per message.
Not yet implemented by any of the aes_impls, so leave a fallback that just calls aes_enc for now. This should be removed when all of the aes_impls provide CBC-MAC and CCM block updates.
|
1.5 | 25-Jul-2020 |
riastradh | Split aes_cbc_* and aes_xts_* into their own header files.
aes.h will remain just for key setup; any particular construction using AES can have its own header file so we can have many of them without rebuilding everything AES-related whenever one of them changes.
(Planning to add AES-CCM and AES-GCM too.)
|
1.4 | 25-Jul-2020 |
riastradh | Split aes_impl declarations out into aes_impl.h.
This will make it less painful to add more operations to struct aes_impl without having to recompile everything that just uses the block cipher directly or similar.
|
1.3 | 30-Jun-2020 |
riastradh | New sysctl node hw.aes_impl for selected AES implementation.
|
1.2 | 29-Jun-2020 |
riastradh | Provide the standard AES key schedule.
Different AES implementations prefer different variations on it, but some of them -- notably VIA -- require the standard key schedule to be available and don't provide hardware support for computing it themselves. So adapt BearSSL's logic to generate the standard key schedule (and decryption keys, with InvMixColumns), rather than the bitsliced key schedule that BearSSL uses natively.
|
1.1 | 29-Jun-2020 |
riastradh | Rework AES in kernel to finally address CVE-2005-1797.
1. Rip out old variable-time reference implementation. 2. Replace it by BearSSL's constant-time 32-bit logic. => Obtained from commit dda1f8a0c46e15b4a235163470ff700b2f13dcc5. => We could conditionally adopt the 64-bit logic too, which would likely give a modest performance boost on 64-bit platforms without AES-NI, but that's a bit more trouble. 3. Select the AES implementation at boot-time; allow an MD override. => Use self-tests to verify basic correctness at boot. => The implementation selection policy is rather rudimentary at the moment but it is isolated to one place so it's easy to change later on.
This (a) plugs a host of timing attacks on, e.g., cgd, and (b) paves the way to take advantage of CPU support for AES -- both things we should've done a decade ago. Downside: Computing AES takes 2-3x the CPU time. But that's what hardware support will be coming for.
Rudimentary measurement of performance impact done by:
mount -t tmpfs tmpfs /tmp dd if=/dev/zero of=/tmp/disk bs=1m count=512 vnconfig -cv vnd0 /tmp/disk cgdconfig -s cgd0 /dev/vnd0 aes-cbc 256 < /dev/zero dd if=/dev/rcgd0d of=/dev/null bs=64k dd if=/dev/zero of=/dev/rcgd0d bs=64k
The AES-CBC encryption performance impact is closer to 3x because it is inherently sequential; the AES-CBC decryption impact is closer to 2x because the bitsliced AES logic can process two blocks at once.
Discussed on tech-kern:
https://mail-index.NetBSD.org/tech-kern/2020/06/18/msg026505.html
|
1.2 | 25-Jul-2020 |
riastradh | Push CBC-MAC and CCM block updates into the aes_impl API.
This should help reduce the setup and teardown overhead (enabling and disabling fpu, or expanding bitsliced keys) for CCM, as used in 802.11 WPA2 CCMP. But all the fiddly formatting details remain in aes_ccm.c to reduce the effort of implementing it -- at the cost of a handful additional setups and teardowns per message.
Not yet implemented by any of the aes_impls, so leave a fallback that just calls aes_enc for now. This should be removed when all of the aes_impls provide CBC-MAC and CCM block updates.
|
1.1 | 25-Jul-2020 |
riastradh | Split aes_impl declarations out into aes_impl.h.
This will make it less painful to add more operations to struct aes_impl without having to recompile everything that just uses the block cipher directly or similar.
|
1.3 | 25-Jul-2020 |
riastradh | Remove now-unused legacy rijndael API.
|
1.2 | 25-Jul-2020 |
riastradh | Split aes_cbc_* and aes_xts_* into their own header files.
aes.h will remain just for key setup; any particular construction using AES can have its own header file so we can have many of them without rebuilding everything AES-related whenever one of them changes.
(Planning to add AES-CCM and AES-GCM too.)
|
1.1 | 29-Jun-2020 |
riastradh | Rework AES in kernel to finally address CVE-2005-1797.
1. Rip out old variable-time reference implementation. 2. Replace it by BearSSL's constant-time 32-bit logic. => Obtained from commit dda1f8a0c46e15b4a235163470ff700b2f13dcc5. => We could conditionally adopt the 64-bit logic too, which would likely give a modest performance boost on 64-bit platforms without AES-NI, but that's a bit more trouble. 3. Select the AES implementation at boot-time; allow an MD override. => Use self-tests to verify basic correctness at boot. => The implementation selection policy is rather rudimentary at the moment but it is isolated to one place so it's easy to change later on.
This (a) plugs a host of timing attacks on, e.g., cgd, and (b) paves the way to take advantage of CPU support for AES -- both things we should've done a decade ago. Downside: Computing AES takes 2-3x the CPU time. But that's what hardware support will be coming for.
Rudimentary measurement of performance impact done by:
mount -t tmpfs tmpfs /tmp dd if=/dev/zero of=/tmp/disk bs=1m count=512 vnconfig -cv vnd0 /tmp/disk cgdconfig -s cgd0 /dev/vnd0 aes-cbc 256 < /dev/zero dd if=/dev/rcgd0d of=/dev/null bs=64k dd if=/dev/zero of=/dev/rcgd0d bs=64k
The AES-CBC encryption performance impact is closer to 3x because it is inherently sequential; the AES-CBC decryption impact is closer to 2x because the bitsliced AES logic can process two blocks at once.
Discussed on tech-kern:
https://mail-index.NetBSD.org/tech-kern/2020/06/18/msg026505.html
|
1.7 | 05-Dec-2021 |
msaitoh | s/folllowing/following/
|
1.6 | 08-Sep-2020 |
riastradh | aes(9): Fix edge case in bitsliced SSE2 AES-CBC decryption.
Make sure self-tests exercise this edge case.
Discovered by confusion over code inspection of jak's adaptation of aes_armv8_64.S for big-endian.
|
1.5 | 25-Jul-2020 |
riastradh | Remove now-needless AES-CCM fallback logic.
These paths are no longer exercised because all of the aes_impls now do the AES-CCM operations.
|
1.4 | 25-Jul-2020 |
riastradh | Push CBC-MAC and CCM block updates into the aes_impl API.
This should help reduce the setup and teardown overhead (enabling and disabling fpu, or expanding bitsliced keys) for CCM, as used in 802.11 WPA2 CCMP. But all the fiddly formatting details remain in aes_ccm.c to reduce the effort of implementing it -- at the cost of a handful additional setups and teardowns per message.
Not yet implemented by any of the aes_impls, so leave a fallback that just calls aes_enc for now. This should be removed when all of the aes_impls provide CBC-MAC and CCM block updates.
|
1.3 | 25-Jul-2020 |
riastradh | Split aes_impl declarations out into aes_impl.h.
This will make it less painful to add more operations to struct aes_impl without having to recompile everything that just uses the block cipher directly or similar.
|
1.2 | 30-Jun-2020 |
riastradh | New test sys/crypto/aes/t_aes.
Runs aes_selftest on all kernel AES implementations supported on the current hardware, not just the preferred one.
|
1.1 | 29-Jun-2020 |
riastradh | Rework AES in kernel to finally address CVE-2005-1797.
1. Rip out old variable-time reference implementation. 2. Replace it by BearSSL's constant-time 32-bit logic. => Obtained from commit dda1f8a0c46e15b4a235163470ff700b2f13dcc5. => We could conditionally adopt the 64-bit logic too, which would likely give a modest performance boost on 64-bit platforms without AES-NI, but that's a bit more trouble. 3. Select the AES implementation at boot-time; allow an MD override. => Use self-tests to verify basic correctness at boot. => The implementation selection policy is rather rudimentary at the moment but it is isolated to one place so it's easy to change later on.
This (a) plugs a host of timing attacks on, e.g., cgd, and (b) paves the way to take advantage of CPU support for AES -- both things we should've done a decade ago. Downside: Computing AES takes 2-3x the CPU time. But that's what hardware support will be coming for.
Rudimentary measurement of performance impact done by:
mount -t tmpfs tmpfs /tmp dd if=/dev/zero of=/tmp/disk bs=1m count=512 vnconfig -cv vnd0 /tmp/disk cgdconfig -s cgd0 /dev/vnd0 aes-cbc 256 < /dev/zero dd if=/dev/rcgd0d of=/dev/null bs=64k dd if=/dev/zero of=/dev/rcgd0d bs=64k
The AES-CBC encryption performance impact is closer to 3x because it is inherently sequential; the AES-CBC decryption impact is closer to 2x because the bitsliced AES logic can process two blocks at once.
Discussed on tech-kern:
https://mail-index.NetBSD.org/tech-kern/2020/06/18/msg026505.html
|
1.1 | 25-Jul-2020 |
riastradh | Split aes_cbc_* and aes_xts_* into their own header files.
aes.h will remain just for key setup; any particular construction using AES can have its own header file so we can have many of them without rebuilding everything AES-related whenever one of them changes.
(Planning to add AES-CCM and AES-GCM too.)
|
1.3 | 25-Jul-2020 |
riastradh | Remove now-unused legacy rijndael API.
|
1.2 | 25-Jul-2020 |
riastradh | New aes_ccm API.
Intended for use in net80211 for WPA2 CCMP.
|
1.1 | 29-Jun-2020 |
riastradh | Rework AES in kernel to finally address CVE-2005-1797.
1. Rip out old variable-time reference implementation. 2. Replace it by BearSSL's constant-time 32-bit logic. => Obtained from commit dda1f8a0c46e15b4a235163470ff700b2f13dcc5. => We could conditionally adopt the 64-bit logic too, which would likely give a modest performance boost on 64-bit platforms without AES-NI, but that's a bit more trouble. 3. Select the AES implementation at boot-time; allow an MD override. => Use self-tests to verify basic correctness at boot. => The implementation selection policy is rather rudimentary at the moment but it is isolated to one place so it's easy to change later on.
This (a) plugs a host of timing attacks on, e.g., cgd, and (b) paves the way to take advantage of CPU support for AES -- both things we should've done a decade ago. Downside: Computing AES takes 2-3x the CPU time. But that's what hardware support will be coming for.
Rudimentary measurement of performance impact done by:
mount -t tmpfs tmpfs /tmp dd if=/dev/zero of=/tmp/disk bs=1m count=512 vnconfig -cv vnd0 /tmp/disk cgdconfig -s cgd0 /dev/vnd0 aes-cbc 256 < /dev/zero dd if=/dev/rcgd0d of=/dev/null bs=64k dd if=/dev/zero of=/dev/rcgd0d bs=64k
The AES-CBC encryption performance impact is closer to 3x because it is inherently sequential; the AES-CBC decryption impact is closer to 2x because the bitsliced AES logic can process two blocks at once.
Discussed on tech-kern:
https://mail-index.NetBSD.org/tech-kern/2020/06/18/msg026505.html
|
1.5 | 25-Jul-2020 |
riastradh | Implement AES-CCM with ARMv8.5-AES.
|
1.4 | 25-Jul-2020 |
riastradh | Split aes_impl declarations out into aes_impl.h.
This will make it less painful to add more operations to struct aes_impl without having to recompile everything that just uses the block cipher directly or similar.
|
1.3 | 30-Jun-2020 |
riastradh | New test sys/crypto/aes/t_aes.
Runs aes_selftest on all kernel AES implementations supported on the current hardware, not just the preferred one.
|
1.2 | 29-Jun-2020 |
riastradh | Move aarch64/fpu.h to arm/fpu.h.
|
1.1 | 29-Jun-2020 |
riastradh | Implement AES in kernel using ARMv8.0-AES on aarch64.
|
1.3 | 25-Jul-2020 |
riastradh | Implement AES-CCM with ARMv8.5-AES.
|
1.2 | 25-Jul-2020 |
riastradh | Split aes_impl declarations out into aes_impl.h.
This will make it less painful to add more operations to struct aes_impl without having to recompile everything that just uses the block cipher directly or similar.
|
1.1 | 29-Jun-2020 |
riastradh | Implement AES in kernel using ARMv8.0-AES on aarch64.
|
1.15 | 08-Sep-2020 |
riastradh | aesarmv8: Reallocate registers to shave off unnecessary MOV.
|
1.14 | 08-Sep-2020 |
riastradh | aesarmv8: Issue two 4-register ld/st, not four 2-register ld/st.
|
1.13 | 08-Sep-2020 |
riastradh | aesarmv8: Adapt aes_armv8_64.S to big-endian.
Patch mainly from (and tested by) jakllsch@ with minor tweaks by me.
|
1.12 | 08-Aug-2020 |
riastradh | Fix ARM NEON implementations of AES and ChaCha on big-endian ARM.
New macros such as VQ_N_U32(a,b,c,d) for NEON vector initializers. Needed because GCC and Clang disagree on the ordering of lanes, depending on whether it's 64-bit big-endian, 32-bit big-endian, or little-endian -- and, bizarrely, both of them disagree with the architectural numbering of lanes.
Experimented with using
static const uint8_t x8[16] = {...};
uint8x16_t x = vld1q_u8(x8);
which doesn't require knowing anything about the ordering of lanes, but this generates considerably worse code and apparently confuses GCC into not recognizing the constant value of x8.
Fix some clang mistakes while here too.
|
1.11 | 27-Jul-2020 |
riastradh | Add RCSIDs to the AES and ChaCha .S sources.
|
1.10 | 27-Jul-2020 |
riastradh | Issue aese/aesmc and aesd/aesimc in pairs.
Advised by the aarch64 optimization guide; increases cgd throughput by about 10%.
|
1.9 | 27-Jul-2020 |
riastradh | Align critical-path loops in AES and ChaCha.
|
1.8 | 25-Jul-2020 |
riastradh | Implement AES-CCM with ARMv8.5-AES.
|
1.7 | 25-Jul-2020 |
riastradh | Invert some loops to save a branch instruction on every iteration.
|
1.6 | 22-Jul-2020 |
riastradh | Fix register name in comment.
Some time ago I reallocated the registers to avoid inadvertently clobbering the callee-saves v9, but neglected to update the comment.
|
1.5 | 19-Jul-2020 |
ryo | fix build with clang/llvm.
clang aarch64 assembler doesn't accept optional number of lanes of vector register. (but ARMARM says that an assembler must accept it)
|
1.4 | 30-Jun-2020 |
riastradh | Reallocate registers to avoid abusing callee-saves registers, v8-v15.
Forgot to consult the AAPCS before committing this before -- oops!
While here, take advantage of the 32 aarch64 simd registers to avoid all stack spills.
|
1.3 | 30-Jun-2020 |
riastradh | Use `.arch_extension aes' for aese/aesmc/aesd/aesimc.
Unlike `.arch_extension crypto', this works with clang; both work with gas, so we'll go with this.
Clang still can't handle aes_armv8_64.S yet -- it gets confused by dup and mov on lanes, but this makes progress.
|
1.2 | 30-Jun-2020 |
riastradh | Use .p2align rather than .align.
Apparently on arm, .align is actually an alias for .p2align, taking a power of two rather than a number of bytes, so aes_armv8_64.o was bloated to 32KB with obscene alignment when it only needed to be barely past 4KB.
Do the same for the x86 aes_ni_64.S -- even though .align takes a number of bytes rather than a power of two on x86, let's just stay away from the temptations of the evil .align directive.
|
1.1 | 29-Jun-2020 |
riastradh | Implement AES in kernel using ARMv8.0-AES on aarch64.
|
1.6 | 21-Nov-2020 |
rin | Fix build with clang for earmv7hf; loadroundkey() is used only for __aarch64__.
|
1.5 | 08-Aug-2020 |
riastradh | branches: 1.5.2; Fix ARM NEON implementations of AES and ChaCha on big-endian ARM.
New macros such as VQ_N_U32(a,b,c,d) for NEON vector initializers. Needed because GCC and Clang disagree on the ordering of lanes, depending on whether it's 64-bit big-endian, 32-bit big-endian, or little-endian -- and, bizarrely, both of them disagree with the architectural numbering of lanes.
Experimented with using
static const uint8_t x8[16] = {...};
uint8x16_t x = vld1q_u8(x8);
which doesn't require knowing anything about the ordering of lanes, but this generates considerably worse code and apparently confuses GCC into not recognizing the constant value of x8.
Fix some clang mistakes while here too.
|
1.4 | 28-Jul-2020 |
riastradh | Draft 2x vectorized neon vpaes for aarch64.
Gives a modest speed boost on rk3399 (Cortex-A53/A72), around 20% in cgd tests, for parallelizable operations like CBC decryption; same improvement should probably carry over to rpi4 CPU which lacks ARMv8.0-AES.
|
1.3 | 30-Jun-2020 |
riastradh | New test sys/crypto/aes/t_aes.
Runs aes_selftest on all kernel AES implementations supported on the current hardware, not just the preferred one.
|
1.2 | 29-Jun-2020 |
riastradh | Provide hand-written AES NEON assembly for arm32.
gcc does a lousy job at compiling 128-bit NEON intrinsics on arm32; hand-writing it made it about 12x faster, by avoiding a zillion loads and stores to spill everything and the kitchen sink onto the stack. (But gcc does fine on aarch64, presumably because it has twice as many registers and doesn't have to deal with q2=d4/d5 overlapping.)
|
1.1 | 29-Jun-2020 |
riastradh | New permutation-based AES implementation using ARM NEON.
Also derived from Mike Hamburg's public-domain vpaes code.
|
1.5.2.1 | 14-Dec-2020 |
thorpej | Sync w/ HEAD.
|
1.3 | 25-Jul-2020 |
riastradh | Implement AES-CCM with NEON.
|
1.2 | 25-Jul-2020 |
riastradh | Split aes_impl declarations out into aes_impl.h.
This will make it less painful to add more operations to struct aes_impl without having to recompile everything that just uses the block cipher directly or similar.
|
1.1 | 29-Jun-2020 |
riastradh | New permutation-based AES implementation using ARM NEON.
Also derived from Mike Hamburg's public-domain vpaes code.
|
1.11 | 10-Sep-2020 |
riastradh | aes neon: Gather mc_forward/backward so we can load 256 bits at once.
|
1.10 | 10-Sep-2020 |
riastradh | aes neon: Hoist dsbd/dsbe address calculation out of loop.
|
1.9 | 10-Sep-2020 |
riastradh | aes neon: Tweak register usage.
- Call r12 by its usual name, ip. - No need for r7 or r11=fp at the moment.
|
1.8 | 10-Sep-2020 |
riastradh | aes neon: Write vtbl with {qN} rather than {d(2N)-d(2N+1)}.
Cosmetic; no functional change.
|
1.7 | 10-Sep-2020 |
riastradh | aes neon: Issue 256-bit loads rather than pairs of 128-bit loads.
Not sure why I didn't realize you could do this before!
Saves some temporary registers that can now be allocated to shave off a few cycles.
|
1.6 | 16-Aug-2020 |
riastradh | Fix AES NEON code for big-endian softfp ARM.
...which is how the kernel runs. Switch to using __SOFTFP__ for consistency with how it gets exposed to C, although I'm not sure how to get it defined automagically in the toolchain for .S files so that's set manually in files.aesneon for now.
|
1.5 | 08-Aug-2020 |
riastradh | Fix ARM NEON implementations of AES and ChaCha on big-endian ARM.
New macros such as VQ_N_U32(a,b,c,d) for NEON vector initializers. Needed because GCC and Clang disagree on the ordering of lanes, depending on whether it's 64-bit big-endian, 32-bit big-endian, or little-endian -- and, bizarrely, both of them disagree with the architectural numbering of lanes.
Experimented with using
static const uint8_t x8[16] = {...};
uint8x16_t x = vld1q_u8(x8);
which doesn't require knowing anything about the ordering of lanes, but this generates considerably worse code and apparently confuses GCC into not recognizing the constant value of x8.
Fix some clang mistakes while here too.
|
1.4 | 27-Jul-2020 |
riastradh | Add RCSIDs to the AES and ChaCha .S sources.
|
1.3 | 27-Jul-2020 |
riastradh | Align critical-path loops in AES and ChaCha.
|
1.2 | 27-Jul-2020 |
riastradh | PIC for aes_neon_32.S.
Without this, tests/sys/crypto/aes/t_aes fails to start on armv7 because of R_ARM_ABS32 relocations in a nonwritable text segment for a PIE -- which atf quietly ignores in the final report! Yikes.
|
1.1 | 29-Jun-2020 |
riastradh | Provide hand-written AES NEON assembly for arm32.
gcc does a lousy job at compiling 128-bit NEON intrinsics on arm32; hand-writing it made it about 12x faster, by avoiding a zillion loads and stores to spill everything and the kitchen sink onto the stack. (But gcc does fine on aarch64, presumably because it has twice as many registers and doesn't have to deal with q2=d4/d5 overlapping.)
|
1.5 | 10-Oct-2020 |
jmcneill | Fix detection of NEON features. ID_AA64PFR0_EL1_ADV_SIMD_NONE means SIMD is not available, and any other value means it is.
|
1.4 | 25-Jul-2020 |
riastradh | Implement AES-CCM with NEON.
|
1.3 | 25-Jul-2020 |
riastradh | Split aes_impl declarations out into aes_impl.h.
This will make it less painful to add more operations to struct aes_impl without having to recompile everything that just uses the block cipher directly or similar.
|
1.2 | 30-Jun-2020 |
riastradh | New test sys/crypto/aes/t_aes.
Runs aes_selftest on all kernel AES implementations supported on the current hardware, not just the preferred one.
|
1.1 | 29-Jun-2020 |
riastradh | New permutation-based AES implementation using ARM NEON.
Also derived from Mike Hamburg's public-domain vpaes code.
|
1.4 | 07-Aug-2023 |
rin | sys/crypto: Introduce arch/{arm,x86} to share common MD headers
Dedup between aes and chacha. No binary changes.
|
1.3 | 08-Aug-2020 |
riastradh | Fix ARM NEON implementations of AES and ChaCha on big-endian ARM.
New macros such as VQ_N_U32(a,b,c,d) for NEON vector initializers. Needed because GCC and Clang disagree on the ordering of lanes, depending on whether it's 64-bit big-endian, 32-bit big-endian, or little-endian -- and, bizarrely, both of them disagree with the architectural numbering of lanes.
Experimented with using
static const uint8_t x8[16] = {...};
uint8x16_t x = vld1q_u8(x8);
which doesn't require knowing anything about the ordering of lanes, but this generates considerably worse code and apparently confuses GCC into not recognizing the constant value of x8.
Fix some clang mistakes while here too.
|
1.2 | 28-Jul-2020 |
riastradh | Draft 2x vectorized neon vpaes for aarch64.
Gives a modest speed boost on rk3399 (Cortex-A53/A72), around 20% in cgd tests, for parallelizable operations like CBC decryption; same improvement should probably carry over to rpi4 CPU which lacks ARMv8.0-AES.
|
1.1 | 29-Jun-2020 |
riastradh | New permutation-based AES implementation using ARM NEON.
Also derived from Mike Hamburg's public-domain vpaes code.
|
1.8 | 26-Jun-2022 |
riastradh | arm/aes_neon: Fix formatting of self-test failure message.
Discovered by code inspection. Remarkably, a combination of errors made this fail to be a stack buffer overrun. Verified by booting with ARMv8.0-AES disabled and with the self-test artificially made to fail.
|
1.7 | 09-Aug-2020 |
riastradh | Use vshlq_n_s32 rather than vsliq_n_s32 with zero destination.
Not sure why I reached for vsliq_n_s32 at first -- probably so I wouldn't have to deal with a new intrinsic in arm_neon.h!
|
1.6 | 09-Aug-2020 |
riastradh | Nix outdated comment.
I implemented this parallelism a couple weeks ago.
|
1.5 | 08-Aug-2020 |
riastradh | Fix ARM NEON implementations of AES and ChaCha on big-endian ARM.
New macros such as VQ_N_U32(a,b,c,d) for NEON vector initializers. Needed because GCC and Clang disagree on the ordering of lanes, depending on whether it's 64-bit big-endian, 32-bit big-endian, or little-endian -- and, bizarrely, both of them disagree with the architectural numbering of lanes.
Experimented with using
static const uint8_t x8[16] = {...};
uint8x16_t x = vld1q_u8(x8);
which doesn't require knowing anything about the ordering of lanes, but this generates considerably worse code and apparently confuses GCC into not recognizing the constant value of x8.
Fix some clang mistakes while here too.
|
1.4 | 28-Jul-2020 |
riastradh | Draft 2x vectorized neon vpaes for aarch64.
Gives a modest speed boost on rk3399 (Cortex-A53/A72), around 20% in cgd tests, for parallelizable operations like CBC decryption; same improvement should probably carry over to rpi4 CPU which lacks ARMv8.0-AES.
|
1.3 | 25-Jul-2020 |
riastradh | Implement AES-CCM with NEON.
|
1.2 | 30-Jun-2020 |
riastradh | New test sys/crypto/aes/t_aes.
Runs aes_selftest on all kernel AES implementations supported on the current hardware, not just the preferred one.
|
1.1 | 29-Jun-2020 |
riastradh | New permutation-based AES implementation using ARM NEON.
Also derived from Mike Hamburg's public-domain vpaes code.
|
1.13 | 07-Aug-2023 |
rin | sys/crypto: Introduce arch/{arm,x86} to share common MD headers
Dedup between aes and chacha. No binary changes.
|
1.12 | 07-Aug-2023 |
rin | sys/crypto/{aes,chacha}/arch/arm/arm_neon.h: Sync (whitespace fix)
No binary changes.
|
1.11 | 07-Sep-2020 |
jakllsch | Fix vgetq_lane_u32 for aarch64eb with GCC
Fixes NEON AES on aarch64eb
|
1.10 | 09-Aug-2020 |
riastradh | Fix some clang neon intrinsics.
Compile-tested only, with -Wno-nonportable-vector-initializers. Need to address -- and test -- this stuff properly but this is progress.
|
1.9 | 09-Aug-2020 |
riastradh | Use vshlq_n_s32 rather than vsliq_n_s32 with zero destination.
Not sure why I reached for vsliq_n_s32 at first -- probably so I wouldn't have to deal with a new intrinsic in arm_neon.h!
|
1.8 | 08-Aug-2020 |
riastradh | Fix ARM NEON implementations of AES and ChaCha on big-endian ARM.
New macros such as VQ_N_U32(a,b,c,d) for NEON vector initializers. Needed because GCC and Clang disagree on the ordering of lanes, depending on whether it's 64-bit big-endian, 32-bit big-endian, or little-endian -- and, bizarrely, both of them disagree with the architectural numbering of lanes.
Experimented with using
static const uint8_t x8[16] = {...};
uint8x16_t x = vld1q_u8(x8);
which doesn't require knowing anything about the ordering of lanes, but this generates considerably worse code and apparently confuses GCC into not recognizing the constant value of x8.
Fix some clang mistakes while here too.
|
1.7 | 28-Jul-2020 |
riastradh | Draft 2x vectorized neon vpaes for aarch64.
Gives a modest speed boost on rk3399 (Cortex-A53/A72), around 20% in cgd tests, for parallelizable operations like CBC decryption; same improvement should probably carry over to rpi4 CPU which lacks ARMv8.0-AES.
|
1.6 | 25-Jul-2020 |
riastradh | Add 32-bit load, store, and shift intrinsics.
vld1q_u32 vst1q_u32 vshlq_n_u32 vshrq_n_u32
|
1.5 | 25-Jul-2020 |
riastradh | Fix missing clang big-endian case.
|
1.4 | 25-Jul-2020 |
riastradh | Implement AES-CCM with NEON.
|
1.3 | 23-Jul-2020 |
ryo | fix build with llvm/clang.
|
1.2 | 30-Jun-2020 |
riastradh | Tweak clang neon intrinsics so they build.
(this file is still a kludge)
|
1.1 | 29-Jun-2020 |
riastradh | New permutation-based AES implementation using ARM NEON.
Also derived from Mike Hamburg's public-domain vpaes code.
|
1.3 | 07-Aug-2023 |
rin | sys/crypto: Introduce arch/{arm,x86} to share common MD headers
Dedup between aes and chacha. No binary changes.
|
1.2 | 09-Aug-2020 |
riastradh | Fix mistake in big-endian arm clang.
Swapped the two halves (only gcc does that, I think) and wrote j,i backwards, oops.
(I don't have a big-endian arm clang build handy to test; hoping this works.)
|
1.1 | 08-Aug-2020 |
riastradh | Fix ARM NEON implementations of AES and ChaCha on big-endian ARM.
New macros such as VQ_N_U32(a,b,c,d) for NEON vector initializers. Needed because GCC and Clang disagree on the ordering of lanes, depending on whether it's 64-bit big-endian, 32-bit big-endian, or little-endian -- and, bizarrely, both of them disagree with the architectural numbering of lanes.
Experimented with using
static const uint8_t x8[16] = {...};
uint8x16_t x = vld1q_u8(x8);
which doesn't require knowing anything about the ordering of lanes, but this generates considerably worse code and apparently confuses GCC into not recognizing the constant value of x8.
Fix some clang mistakes while here too.
|
1.1 | 29-Jun-2020 |
riastradh | Implement AES in kernel using ARMv8.0-AES on aarch64.
|
1.5 | 08-Sep-2020 |
jakllsch | Acknowledge clang warning for NEON cipher code on aarch64eb
We've already made the nonportable vector initializations portable; the code works on aarch64eb.
|
1.4 | 16-Aug-2020 |
riastradh | Fix AES NEON code for big-endian softfp ARM.
...which is how the kernel runs. Switch to using __SOFTFP__ for consistency with how it gets exposed to C, although I'm not sure how to get it defined automagically in the toolchain for .S files so that's set manually in files.aesneon for now.
|
1.3 | 30-Jun-2020 |
riastradh | Limit aes_neon to cpu_cortex | aarch64.
We won't use it on any other systems, and it doesn't build without NEON anyway. Verified earmv7hf GENERIC, aarch64 GENERIC64, and earmv6 RPI2 all build with this.
|
1.2 | 29-Jun-2020 |
riastradh | Provide hand-written AES NEON assembly for arm32.
gcc does a lousy job at compiling 128-bit NEON intrinsics on arm32; hand-writing it made it about 12x faster, by avoiding a zillion loads and stores to spill everything and the kitchen sink onto the stack. (But gcc does fine on aarch64, presumably because it has twice as many registers and doesn't have to deal with q2=d4/d5 overlapping.)
|
1.1 | 29-Jun-2020 |
riastradh | New permutation-based AES implementation using ARM NEON.
Also derived from Mike Hamburg's public-domain vpaes code.
|
1.5 | 05-Sep-2020 |
maxv | x86: fix several CPUID flags
- Rename: CPUID_PN -> CPUID_PSN CPUID_CFLUSH -> CPUID_CLFSH CPUID_SBF -> CPUID_PBE CPUID_LZCNT -> CPUID_ABM CPUID_P1GB -> CPUID_PAGE1GB CPUID2_PCLMUL -> CPUID2_PCLMULQDQ CPUID2_CID -> CPUID2_CNXTID CPUID2_xTPR -> CPUID2_XTPR CPUID2_AES -> CPUID2_AESNI To match the x86 specification and the other OSes.
- Remove: CPUID_B10, CPUID_B20, CPUID_IA64. They do not exist.
|
1.4 | 25-Jul-2020 |
riastradh | Implement AES-CCM with x86 AES-NI.
|
1.3 | 25-Jul-2020 |
riastradh | Split aes_impl declarations out into aes_impl.h.
This will make it less painful to add more operations to struct aes_impl without having to recompile everything that just uses the block cipher directly or similar.
|
1.2 | 30-Jun-2020 |
riastradh | New test sys/crypto/aes/t_aes.
Runs aes_selftest on all kernel AES implementations supported on the current hardware, not just the preferred one.
|
1.1 | 29-Jun-2020 |
riastradh | Add x86 AES-NI support.
Limited to amd64 for now. In principle, AES-NI should work in 32-bit mode, and there may even be some 32-bit-only CPUs that support AES-NI, but that requires work to adapt the assembly.
|
1.3 | 25-Jul-2020 |
riastradh | Implement AES-CCM with x86 AES-NI.
|
1.2 | 25-Jul-2020 |
riastradh | Split aes_impl declarations out into aes_impl.h.
This will make it less painful to add more operations to struct aes_impl without having to recompile everything that just uses the block cipher directly or similar.
|
1.1 | 29-Jun-2020 |
riastradh | Add x86 AES-NI support.
Limited to amd64 for now. In principle, AES-NI should work in 32-bit mode, and there may even be some 32-bit-only CPUs that support AES-NI, but that requires work to adapt the assembly.
|
1.6 | 27-Jul-2020 |
riastradh | Add RCSIDs to the AES and ChaCha .S sources.
|
1.5 | 27-Jul-2020 |
riastradh | Align critical-path loops in AES and ChaCha.
|
1.4 | 25-Jul-2020 |
riastradh | Implement AES-CCM with x86 AES-NI.
|
1.3 | 25-Jul-2020 |
riastradh | Invert some loops to save a jmp instruction on each iteration.
No semantic change intended.
|
1.2 | 30-Jun-2020 |
riastradh | Use .p2align rather than .align.
Apparently on arm, .align is actually an alias for .p2align, taking a power of two rather than a number of bytes, so aes_armv8_64.o was bloated to 32KB with obscene alignment when it only needed to be barely past 4KB.
Do the same for the x86 aes_ni_64.S -- even though .align takes a number of bytes rather than a power of two on x86, let's just stay away from the temptations of the evil .align directive.
|
1.1 | 29-Jun-2020 |
riastradh | Add x86 AES-NI support.
Limited to amd64 for now. In principle, AES-NI should work in 32-bit mode, and there may even be some 32-bit-only CPUs that support AES-NI, but that requires work to adapt the assembly.
|
1.2 | 30-Jun-2020 |
riastradh | New test sys/crypto/aes/t_aes.
Runs aes_selftest on all kernel AES implementations supported on the current hardware, not just the preferred one.
|
1.1 | 29-Jun-2020 |
riastradh | New SSE2-based bitsliced AES implementation.
This should work on essentially all x86 CPUs of the last two decades, and may improve throughput over the portable C aes_ct implementation from BearSSL by
(a) reducing the number of vector operations in sequence, and (b) batching four rather than two blocks in parallel.
Derived from BearSSL'S aes_ct64 implementation adjusted so that where aes_ct64 uses 64-bit q[0],...,q[7], aes_sse2 uses (q[0], q[4]), ..., (q[3], q[7]), each tuple representing a pair of 64-bit quantities stacked in a single 128-bit register. This translation was done very naively, and mostly reduces the cost of ShiftRows and data movement without doing anything to address the S-box or (Inv)MixColumns, which spread all 64-bit quantities across separate registers and ignore the upper halves.
Unfortunately, SSE2 -- which is all that is guaranteed on all amd64 CPUs -- doesn't have PSHUFB, which would help out a lot more. For example, vpaes relies on that. Perhaps there are enough CPUs out there with PSHUFB but not AES-NI to make it worthwhile to import or adapt vpaes too.
Note: This includes local definitions of various Intel compiler intrinsics for gcc and clang in terms of their __builtin_* &c., because the necessary header files are not available during the kernel build. This is a kludge -- we should fix it properly; the present approach is expedient but not ideal.
|
1.4 | 25-Jul-2020 |
riastradh | Implement AES-CCM with SSE2.
|
1.3 | 25-Jul-2020 |
riastradh | Split aes_impl declarations out into aes_impl.h.
This will make it less painful to add more operations to struct aes_impl without having to recompile everything that just uses the block cipher directly or similar.
|
1.2 | 29-Jun-2020 |
riastradh | Split SSE2 logic into separate units.
Ensure that there are no paths into files compiled with -msse -msse2 at all except via fpu_kern_enter.
I didn't run into a practical problem with this, but let's not leave a ticking time bomb for subsequent toolchain changes in case the mere declaration of local __m128i variables causes trouble.
|
1.1 | 29-Jun-2020 |
riastradh | New SSE2-based bitsliced AES implementation.
This should work on essentially all x86 CPUs of the last two decades, and may improve throughput over the portable C aes_ct implementation from BearSSL by
(a) reducing the number of vector operations in sequence, and (b) batching four rather than two blocks in parallel.
Derived from BearSSL'S aes_ct64 implementation adjusted so that where aes_ct64 uses 64-bit q[0],...,q[7], aes_sse2 uses (q[0], q[4]), ..., (q[3], q[7]), each tuple representing a pair of 64-bit quantities stacked in a single 128-bit register. This translation was done very naively, and mostly reduces the cost of ShiftRows and data movement without doing anything to address the S-box or (Inv)MixColumns, which spread all 64-bit quantities across separate registers and ignore the upper halves.
Unfortunately, SSE2 -- which is all that is guaranteed on all amd64 CPUs -- doesn't have PSHUFB, which would help out a lot more. For example, vpaes relies on that. Perhaps there are enough CPUs out there with PSHUFB but not AES-NI to make it worthwhile to import or adapt vpaes too.
Note: This includes local definitions of various Intel compiler intrinsics for gcc and clang in terms of their __builtin_* &c., because the necessary header files are not available during the kernel build. This is a kludge -- we should fix it properly; the present approach is expedient but not ideal.
|
1.1 | 29-Jun-2020 |
riastradh | New SSE2-based bitsliced AES implementation.
This should work on essentially all x86 CPUs of the last two decades, and may improve throughput over the portable C aes_ct implementation from BearSSL by
(a) reducing the number of vector operations in sequence, and (b) batching four rather than two blocks in parallel.
Derived from BearSSL'S aes_ct64 implementation adjusted so that where aes_ct64 uses 64-bit q[0],...,q[7], aes_sse2 uses (q[0], q[4]), ..., (q[3], q[7]), each tuple representing a pair of 64-bit quantities stacked in a single 128-bit register. This translation was done very naively, and mostly reduces the cost of ShiftRows and data movement without doing anything to address the S-box or (Inv)MixColumns, which spread all 64-bit quantities across separate registers and ignore the upper halves.
Unfortunately, SSE2 -- which is all that is guaranteed on all amd64 CPUs -- doesn't have PSHUFB, which would help out a lot more. For example, vpaes relies on that. Perhaps there are enough CPUs out there with PSHUFB but not AES-NI to make it worthwhile to import or adapt vpaes too.
Note: This includes local definitions of various Intel compiler intrinsics for gcc and clang in terms of their __builtin_* &c., because the necessary header files are not available during the kernel build. This is a kludge -- we should fix it properly; the present approach is expedient but not ideal.
|
1.1 | 29-Jun-2020 |
riastradh | New SSE2-based bitsliced AES implementation.
This should work on essentially all x86 CPUs of the last two decades, and may improve throughput over the portable C aes_ct implementation from BearSSL by
(a) reducing the number of vector operations in sequence, and (b) batching four rather than two blocks in parallel.
Derived from BearSSL'S aes_ct64 implementation adjusted so that where aes_ct64 uses 64-bit q[0],...,q[7], aes_sse2 uses (q[0], q[4]), ..., (q[3], q[7]), each tuple representing a pair of 64-bit quantities stacked in a single 128-bit register. This translation was done very naively, and mostly reduces the cost of ShiftRows and data movement without doing anything to address the S-box or (Inv)MixColumns, which spread all 64-bit quantities across separate registers and ignore the upper halves.
Unfortunately, SSE2 -- which is all that is guaranteed on all amd64 CPUs -- doesn't have PSHUFB, which would help out a lot more. For example, vpaes relies on that. Perhaps there are enough CPUs out there with PSHUFB but not AES-NI to make it worthwhile to import or adapt vpaes too.
Note: This includes local definitions of various Intel compiler intrinsics for gcc and clang in terms of their __builtin_* &c., because the necessary header files are not available during the kernel build. This is a kludge -- we should fix it properly; the present approach is expedient but not ideal.
|
1.5 | 25-Jul-2020 |
riastradh | Implement AES-CCM with SSE2.
|
1.4 | 25-Jul-2020 |
riastradh | Split aes_impl declarations out into aes_impl.h.
This will make it less painful to add more operations to struct aes_impl without having to recompile everything that just uses the block cipher directly or similar.
|
1.3 | 30-Jun-2020 |
riastradh | New test sys/crypto/aes/t_aes.
Runs aes_selftest on all kernel AES implementations supported on the current hardware, not just the preferred one.
|
1.2 | 29-Jun-2020 |
riastradh | Split SSE2 logic into separate units.
Ensure that there are no paths into files compiled with -msse -msse2 at all except via fpu_kern_enter.
I didn't run into a practical problem with this, but let's not leave a ticking time bomb for subsequent toolchain changes in case the mere declaration of local __m128i variables causes trouble.
|
1.1 | 29-Jun-2020 |
riastradh | New SSE2-based bitsliced AES implementation.
This should work on essentially all x86 CPUs of the last two decades, and may improve throughput over the portable C aes_ct implementation from BearSSL by
(a) reducing the number of vector operations in sequence, and (b) batching four rather than two blocks in parallel.
Derived from BearSSL'S aes_ct64 implementation adjusted so that where aes_ct64 uses 64-bit q[0],...,q[7], aes_sse2 uses (q[0], q[4]), ..., (q[3], q[7]), each tuple representing a pair of 64-bit quantities stacked in a single 128-bit register. This translation was done very naively, and mostly reduces the cost of ShiftRows and data movement without doing anything to address the S-box or (Inv)MixColumns, which spread all 64-bit quantities across separate registers and ignore the upper halves.
Unfortunately, SSE2 -- which is all that is guaranteed on all amd64 CPUs -- doesn't have PSHUFB, which would help out a lot more. For example, vpaes relies on that. Perhaps there are enough CPUs out there with PSHUFB but not AES-NI to make it worthwhile to import or adapt vpaes too.
Note: This includes local definitions of various Intel compiler intrinsics for gcc and clang in terms of their __builtin_* &c., because the necessary header files are not available during the kernel build. This is a kludge -- we should fix it properly; the present approach is expedient but not ideal.
|
1.3 | 07-Aug-2023 |
rin | sys/crypto: Introduce arch/{arm,x86} to share common MD headers
Dedup between aes and chacha. No binary changes.
|
1.2 | 29-Jun-2020 |
riastradh | Split SSE2 logic into separate units.
Ensure that there are no paths into files compiled with -msse -msse2 at all except via fpu_kern_enter.
I didn't run into a practical problem with this, but let's not leave a ticking time bomb for subsequent toolchain changes in case the mere declaration of local __m128i variables causes trouble.
|
1.1 | 29-Jun-2020 |
riastradh | New SSE2-based bitsliced AES implementation.
This should work on essentially all x86 CPUs of the last two decades, and may improve throughput over the portable C aes_ct implementation from BearSSL by
(a) reducing the number of vector operations in sequence, and (b) batching four rather than two blocks in parallel.
Derived from BearSSL'S aes_ct64 implementation adjusted so that where aes_ct64 uses 64-bit q[0],...,q[7], aes_sse2 uses (q[0], q[4]), ..., (q[3], q[7]), each tuple representing a pair of 64-bit quantities stacked in a single 128-bit register. This translation was done very naively, and mostly reduces the cost of ShiftRows and data movement without doing anything to address the S-box or (Inv)MixColumns, which spread all 64-bit quantities across separate registers and ignore the upper halves.
Unfortunately, SSE2 -- which is all that is guaranteed on all amd64 CPUs -- doesn't have PSHUFB, which would help out a lot more. For example, vpaes relies on that. Perhaps there are enough CPUs out there with PSHUFB but not AES-NI to make it worthwhile to import or adapt vpaes too.
Note: This includes local definitions of various Intel compiler intrinsics for gcc and clang in terms of their __builtin_* &c., because the necessary header files are not available during the kernel build. This is a kludge -- we should fix it properly; the present approach is expedient but not ideal.
|
1.4 | 08-Sep-2020 |
riastradh | aes(9): Fix edge case in bitsliced SSE2 AES-CBC decryption.
Make sure self-tests exercise this edge case.
Discovered by confusion over code inspection of jak's adaptation of aes_armv8_64.S for big-endian.
|
1.3 | 25-Jul-2020 |
riastradh | Implement AES-CCM with SSE2.
|
1.2 | 30-Jun-2020 |
riastradh | New test sys/crypto/aes/t_aes.
Runs aes_selftest on all kernel AES implementations supported on the current hardware, not just the preferred one.
|
1.1 | 29-Jun-2020 |
riastradh | Split SSE2 logic into separate units.
Ensure that there are no paths into files compiled with -msse -msse2 at all except via fpu_kern_enter.
I didn't run into a practical problem with this, but let's not leave a ticking time bomb for subsequent toolchain changes in case the mere declaration of local __m128i variables causes trouble.
|
1.2 | 30-Jun-2020 |
riastradh | New test sys/crypto/aes/t_aes.
Runs aes_selftest on all kernel AES implementations supported on the current hardware, not just the preferred one.
|
1.1 | 29-Jun-2020 |
riastradh | New permutation-based AES implementation using SSSE3.
This covers a lot of CPUs -- particularly lower-end CPUs over the past decade which lack AES-NI.
Derived from Mike Hamburg's public domain vpaes software; see <https://crypto.stanford.edu/vpaes/> for details.
|
1.3 | 25-Jul-2020 |
riastradh | Implement AES-CCM with SSSE3.
|
1.2 | 25-Jul-2020 |
riastradh | Split aes_impl declarations out into aes_impl.h.
This will make it less painful to add more operations to struct aes_impl without having to recompile everything that just uses the block cipher directly or similar.
|
1.1 | 29-Jun-2020 |
riastradh | New permutation-based AES implementation using SSSE3.
This covers a lot of CPUs -- particularly lower-end CPUs over the past decade which lack AES-NI.
Derived from Mike Hamburg's public domain vpaes software; see <https://crypto.stanford.edu/vpaes/> for details.
|
1.4 | 25-Jul-2020 |
riastradh | Implement AES-CCM with SSSE3.
|
1.3 | 25-Jul-2020 |
riastradh | Split aes_impl declarations out into aes_impl.h.
This will make it less painful to add more operations to struct aes_impl without having to recompile everything that just uses the block cipher directly or similar.
|
1.2 | 30-Jun-2020 |
riastradh | New test sys/crypto/aes/t_aes.
Runs aes_selftest on all kernel AES implementations supported on the current hardware, not just the preferred one.
|
1.1 | 29-Jun-2020 |
riastradh | New permutation-based AES implementation using SSSE3.
This covers a lot of CPUs -- particularly lower-end CPUs over the past decade which lack AES-NI.
Derived from Mike Hamburg's public domain vpaes software; see <https://crypto.stanford.edu/vpaes/> for details.
|
1.2 | 07-Aug-2023 |
rin | sys/crypto: Introduce arch/{arm,x86} to share common MD headers
Dedup between aes and chacha. No binary changes.
|
1.1 | 29-Jun-2020 |
riastradh | New permutation-based AES implementation using SSSE3.
This covers a lot of CPUs -- particularly lower-end CPUs over the past decade which lack AES-NI.
Derived from Mike Hamburg's public domain vpaes software; see <https://crypto.stanford.edu/vpaes/> for details.
|
1.3 | 25-Jul-2020 |
riastradh | Implement AES-CCM with SSSE3.
|
1.2 | 30-Jun-2020 |
riastradh | New test sys/crypto/aes/t_aes.
Runs aes_selftest on all kernel AES implementations supported on the current hardware, not just the preferred one.
|
1.1 | 29-Jun-2020 |
riastradh | New permutation-based AES implementation using SSSE3.
This covers a lot of CPUs -- particularly lower-end CPUs over the past decade which lack AES-NI.
Derived from Mike Hamburg's public domain vpaes software; see <https://crypto.stanford.edu/vpaes/> for details.
|
1.9 | 16-Jun-2024 |
rillig | sys/aes_via: fix broken link in comment
|
1.8 | 16-Jun-2024 |
christos | revert previous, probably a gcc bug?
|
1.7 | 16-Jun-2024 |
christos | try to fix the overflow gcc pointed out.
|
1.6 | 28-Jul-2020 |
riastradh | Initialize authctr in both branches.
I guess I didn't test the unaligned case, weird.
|
1.5 | 25-Jul-2020 |
riastradh | Implement AES-CCM with VIA ACE.
|
1.4 | 25-Jul-2020 |
riastradh | Split aes_impl declarations out into aes_impl.h.
This will make it less painful to add more operations to struct aes_impl without having to recompile everything that just uses the block cipher directly or similar.
|
1.3 | 30-Jun-2020 |
riastradh | New test sys/crypto/aes/t_aes.
Runs aes_selftest on all kernel AES implementations supported on the current hardware, not just the preferred one.
|
1.2 | 29-Jun-2020 |
riastradh | VIA AES: Batch AES-XTS computation into eight blocks at a time.
Experimental -- performance improvement is not clearly worth the complexity.
|
1.1 | 29-Jun-2020 |
riastradh | Add AES implementation with VIA ACE.
|
1.2 | 25-Jul-2020 |
riastradh | Split aes_impl declarations out into aes_impl.h.
This will make it less painful to add more operations to struct aes_impl without having to recompile everything that just uses the block cipher directly or similar.
|
1.1 | 29-Jun-2020 |
riastradh | Add AES implementation with VIA ACE.
|
1.1 | 29-Jun-2020 |
riastradh | Add x86 AES-NI support.
Limited to amd64 for now. In principle, AES-NI should work in 32-bit mode, and there may even be some 32-bit-only CPUs that support AES-NI, but that requires work to adapt the assembly.
|
1.2 | 29-Jun-2020 |
riastradh | Split SSE2 logic into separate units.
Ensure that there are no paths into files compiled with -msse -msse2 at all except via fpu_kern_enter.
I didn't run into a practical problem with this, but let's not leave a ticking time bomb for subsequent toolchain changes in case the mere declaration of local __m128i variables causes trouble.
|
1.1 | 29-Jun-2020 |
riastradh | New SSE2-based bitsliced AES implementation.
This should work on essentially all x86 CPUs of the last two decades, and may improve throughput over the portable C aes_ct implementation from BearSSL by
(a) reducing the number of vector operations in sequence, and (b) batching four rather than two blocks in parallel.
Derived from BearSSL'S aes_ct64 implementation adjusted so that where aes_ct64 uses 64-bit q[0],...,q[7], aes_sse2 uses (q[0], q[4]), ..., (q[3], q[7]), each tuple representing a pair of 64-bit quantities stacked in a single 128-bit register. This translation was done very naively, and mostly reduces the cost of ShiftRows and data movement without doing anything to address the S-box or (Inv)MixColumns, which spread all 64-bit quantities across separate registers and ignore the upper halves.
Unfortunately, SSE2 -- which is all that is guaranteed on all amd64 CPUs -- doesn't have PSHUFB, which would help out a lot more. For example, vpaes relies on that. Perhaps there are enough CPUs out there with PSHUFB but not AES-NI to make it worthwhile to import or adapt vpaes too.
Note: This includes local definitions of various Intel compiler intrinsics for gcc and clang in terms of their __builtin_* &c., because the necessary header files are not available during the kernel build. This is a kludge -- we should fix it properly; the present approach is expedient but not ideal.
|
1.1 | 29-Jun-2020 |
riastradh | New permutation-based AES implementation using SSSE3.
This covers a lot of CPUs -- particularly lower-end CPUs over the past decade which lack AES-NI.
Derived from Mike Hamburg's public domain vpaes software; see <https://crypto.stanford.edu/vpaes/> for details.
|
1.1 | 29-Jun-2020 |
riastradh | Add AES implementation with VIA ACE.
|
1.6 | 07-Aug-2023 |
rin | sys/crypto: Introduce arch/{arm,x86} to share common MD headers
Dedup between aes and chacha. No binary changes.
|
1.5 | 25-Jul-2020 |
riastradh | Add some Intel intrinsics for ChaCha.
_mm_load1_ps _mm_loadu_si128 _mm_movelh_ps _mm_slli_epi32 _mm_storeu_si128 _mm_unpackhi_epi32 _mm_unpacklo_epi32
|
1.4 | 25-Jul-2020 |
riastradh | Fix target attribute on _mm_movehl_ps, fix clang _mm_unpacklo_epi64.
- _mm_movehl_ps is available in SSE2, no need for SSSE3. - _mm_unpacklo_epi64 operates on v2di, not v4si; fix.
|
1.3 | 25-Jul-2020 |
riastradh | Implement AES-CCM with SSSE3.
|
1.2 | 29-Jun-2020 |
riastradh | New permutation-based AES implementation using SSSE3.
This covers a lot of CPUs -- particularly lower-end CPUs over the past decade which lack AES-NI.
Derived from Mike Hamburg's public domain vpaes software; see <https://crypto.stanford.edu/vpaes/> for details.
|
1.1 | 29-Jun-2020 |
riastradh | New SSE2-based bitsliced AES implementation.
This should work on essentially all x86 CPUs of the last two decades, and may improve throughput over the portable C aes_ct implementation from BearSSL by
(a) reducing the number of vector operations in sequence, and (b) batching four rather than two blocks in parallel.
Derived from BearSSL'S aes_ct64 implementation adjusted so that where aes_ct64 uses 64-bit q[0],...,q[7], aes_sse2 uses (q[0], q[4]), ..., (q[3], q[7]), each tuple representing a pair of 64-bit quantities stacked in a single 128-bit register. This translation was done very naively, and mostly reduces the cost of ShiftRows and data movement without doing anything to address the S-box or (Inv)MixColumns, which spread all 64-bit quantities across separate registers and ignore the upper halves.
Unfortunately, SSE2 -- which is all that is guaranteed on all amd64 CPUs -- doesn't have PSHUFB, which would help out a lot more. For example, vpaes relies on that. Perhaps there are enough CPUs out there with PSHUFB but not AES-NI to make it worthwhile to import or adapt vpaes too.
Note: This includes local definitions of various Intel compiler intrinsics for gcc and clang in terms of their __builtin_* &c., because the necessary header files are not available during the kernel build. This is a kludge -- we should fix it properly; the present approach is expedient but not ideal.
|
1.2 | 07-Aug-2023 |
rin | sys/crypto: Introduce arch/{arm,x86} to share common MD headers
Dedup between aes and chacha. No binary changes.
|
1.1 | 29-Jun-2020 |
riastradh | New SSE2-based bitsliced AES implementation.
This should work on essentially all x86 CPUs of the last two decades, and may improve throughput over the portable C aes_ct implementation from BearSSL by
(a) reducing the number of vector operations in sequence, and (b) batching four rather than two blocks in parallel.
Derived from BearSSL'S aes_ct64 implementation adjusted so that where aes_ct64 uses 64-bit q[0],...,q[7], aes_sse2 uses (q[0], q[4]), ..., (q[3], q[7]), each tuple representing a pair of 64-bit quantities stacked in a single 128-bit register. This translation was done very naively, and mostly reduces the cost of ShiftRows and data movement without doing anything to address the S-box or (Inv)MixColumns, which spread all 64-bit quantities across separate registers and ignore the upper halves.
Unfortunately, SSE2 -- which is all that is guaranteed on all amd64 CPUs -- doesn't have PSHUFB, which would help out a lot more. For example, vpaes relies on that. Perhaps there are enough CPUs out there with PSHUFB but not AES-NI to make it worthwhile to import or adapt vpaes too.
Note: This includes local definitions of various Intel compiler intrinsics for gcc and clang in terms of their __builtin_* &c., because the necessary header files are not available during the kernel build. This is a kludge -- we should fix it properly; the present approach is expedient but not ideal.
|
1.2 | 07-Aug-2023 |
rin | sys/crypto: aarch64: Catch up with builtin rename for GCC12
Kernel self tests successfully pass for aarch64{,eb}.
Same binary generated by GCC10 and GCC12 for: --- #include <sys/types.h> #include "arm_neon.h"
uint32x4_t my_vshrq_n_u32(uint32x4_t v, uint8_t bits) { return vshrq_n_u32(v, bits); }
uint8x16_t my_vshrq_n_u8(uint8x16_t v, uint8_t bits) { return vshrq_n_u8(v, bits); } ---
|
1.1 | 07-Aug-2023 |
rin | sys/crypto: Introduce arch/{arm,x86} to share common MD headers
Dedup between aes and chacha. No binary changes.
|
1.1 | 07-Aug-2023 |
rin | sys/crypto: Introduce arch/{arm,x86} to share common MD headers
Dedup between aes and chacha. No binary changes.
|
1.4 | 16-Jul-2024 |
riastradh | sys/crypto: Two more issues in GCC Intel intrinsics.
With this, the AES tests should pass again.
|
1.3 | 15-Jul-2024 |
riastradh | sys/crypto: Fix mistakes in previous gcc12 immintrin fixes.
Compile-tested the ChaCha code, not the whole kernel, and it turns out the AES code trips over the mistakes.
PR toolchain/58350
|
1.2 | 15-Jul-2024 |
riastradh | sys/crypto: Fix gcc x86 load/store-unaligned intrinsics.
(Sure would be nice if someone wired up the kernel build to use gcc/clang's own immintrin.h &c. so we don't have to maintain a copy!)
PR toolchain/58350
|
1.1 | 07-Aug-2023 |
rin | branches: 1.1.6; sys/crypto: Introduce arch/{arm,x86} to share common MD headers
Dedup between aes and chacha. No binary changes.
|
1.1.6.1 | 02-Aug-2025 |
perseant | Sync with HEAD
|
1.2 | 15-Jul-2024 |
riastradh | sys/crypto: Fix mistakes in previous gcc12 immintrin fixes.
Compile-tested the ChaCha code, not the whole kernel, and it turns out the AES code trips over the mistakes.
PR toolchain/58350
|
1.1 | 07-Aug-2023 |
rin | branches: 1.1.6; sys/crypto: Introduce arch/{arm,x86} to share common MD headers
Dedup between aes and chacha. No binary changes.
|
1.1.6.1 | 02-Aug-2025 |
perseant | Sync with HEAD
|
1.2 | 17-Oct-2021 |
jmcneill | Upgrade self-test passed messages from verbose to debug.
|
1.1 | 20-Aug-2020 |
riastradh | Import small BLAKE2s implementation.
|
1.1 | 20-Aug-2020 |
riastradh | Import small BLAKE2s implementation.
|
1.2 | 26-Aug-2020 |
christos | Instead of returning 0 when sysctl kern.expose_address=0, return a random hashed value of the data. This allows sockstat to work without exposing kernel addresses or being setgid kmem.
|
1.1 | 20-Aug-2020 |
riastradh | Import small BLAKE2s implementation.
|
1.12 | 11-Dec-2005 |
christos | merge ktrace-lwp.
|
1.11 | 30-May-2005 |
christos | sprinkle const
|
1.10 | 26-Feb-2005 |
perry | nuke trailing whitespace
|
1.9 | 26-Aug-2003 |
thorpej | branches: 1.9.8; 1.9.10; * Const poison, ANSI'ify, like newer OpenSSL Blowfish code. * Add a BF_ecb_encrypt(), which makes for a prettier interface than using BF_encrypt()/BF_decrypt() directly.
|
1.8 | 08-Sep-2002 |
elric | branches: 1.8.6; Modified to avoid compiler warnings. The specific warning related to const BF_KEY * vars, and I chose to ``fix'' it in this file rather than elsewhere in the framework because, although the other fix was more appropriate, nothing seems to use the code in this file and hence the risk of disrupting other people was lower. In the future, the more appropriate change would be to change blowfish.h and bf_enc.c to have functions with signatures:
BF_encrypt(BF_LONG *, const BF_KEY *); BF_decrypt(BF_LONG *, const BF_KEY *);
|
1.7 | 07-Sep-2002 |
elric | Include <sys/types.h> to allow compilation to occur.
|
1.6 | 07-Sep-2002 |
elric | repoint include file for kernel use.
|
1.5 | 13-Nov-2001 |
lukem | branches: 1.5.10; add RCSIDs
|
1.4 | 09-Sep-2001 |
tls | Add asm versions of blowfish and des transforms for i386.
This also involved updating the in-kernel DES functions to correspond to the versions in our in-tree OpenSSL, because the des_SPtrans table has changed; the asm code will not work with the old permutation table!
C and i386 asm code for the DES, 3DES, and Blowfish CBC modes is also included; it is not currently built as the ESP processing in esp_core.c splits the CBC operation and the cipher transform apart. Hopefully that will be fixed as there is a substantial performance improvement to be had from doing so. It will remain necessary to use the C version of the Blowfish CBC function on some i386 machines, however, as the asm version uses bswapl, which ony 486 and later processors have. The DES CBC code doesn't have this problem.
Finally, change esp_core.c to use the ecb3_encrypt function instead of calling ecb_encrypt three times; this improves performance a bit, in particular in the asm case.
|
1.3 | 27-May-2001 |
itojun | branches: 1.3.2; 1.3.4; remove files we no longer need/maintain. sync with kame
|
1.2 | 31-Aug-2000 |
itojun | branches: 1.2.2; 1.2.4; make the code friendly with LP64 machines. - use u_int32_t for 32bit quantity unsigned integer type. - s/unsigned long/BF_LONG/ (BF_LONG = u_int32_t) where appropriate. - prototype cleanup - due to *BSD code sharing, we still are using __P(). part of PR 10918. sync with kame.
|
1.1 | 14-Jun-2000 |
thorpej | branches: 1.1.1; Initial revision
|
1.1.1.1 | 14-Jun-2000 |
thorpej | branches: 1.1.1.1.2; 1.1.1.1.4; Import the IPsec crypto code from netbsd-cryptosrc-intl.
|
1.1.1.1.4.2 | 22-Jun-2000 |
minoura | Sync w/ netbsd-1-5-base.
|
1.1.1.1.4.1 | 14-Jun-2000 |
minoura | file bf_cbc.c was added on branch minoura-xpg4dl on 2000-06-22 17:05:58 +0000
|
1.1.1.1.2.1 | 31-Aug-2000 |
itojun | pullup 1.1 -> 1.2 (for all files) - approved by releng-1-5
without the fix, blowfish encryption function panics the kernel, on LP64 arch.
>make the code friendly with LP64 machines. >- use u_int32_t for 32bit quantity unsigned integer type. >- s/unsigned long/BF_LONG/ (BF_LONG = u_int32_t) where appropriate. >- prototype cleanup - due to *BSD code sharing, we still are using __P(). >part of PR 10918. sync with kame.
|
1.2.4.3 | 17-Sep-2002 |
nathanw | Catch up to -current.
|
1.2.4.2 | 14-Nov-2001 |
nathanw | Catch up to -current.
|
1.2.4.1 | 21-Sep-2001 |
nathanw | Catch up to -current.
|
1.2.2.2 | 20-Nov-2000 |
bouyer | Update thorpej_scsipi to -current as of a month ago
|
1.2.2.1 | 31-Aug-2000 |
bouyer | file bf_cbc.c was added on branch thorpej_scsipi on 2000-11-20 22:21:42 +0000
|
1.3.4.1 | 01-Oct-2001 |
fvdl | Catch up with -current.
|
1.3.2.3 | 10-Oct-2002 |
jdolecek | sync kqueue with -current; this includes merge of gehenna-devsw branch, merge of i386 MP branch, and part of autoconf rototil work
|
1.3.2.2 | 10-Jan-2002 |
thorpej | Sync kqueue branch with -current.
|
1.3.2.1 | 13-Sep-2001 |
thorpej | Update the kqueue branch to HEAD.
|
1.5.10.3 | 12-Sep-2003 |
tron | Pull up revision 1.8 (requested by tv in ticket #1455): Modified to avoid compiler warnings. The specific warning related to const BF_KEY * vars, and I chose to ``fix'' it in this file rather than elsewhere in the framework because, although the other fix was more appropriate, nothing seems to use the code in this file and hence the risk of disrupting other people was lower. In the future, the more appropriate change would be to change blowfish.h and bf_enc.c to have functions with signatures: BF_encrypt(BF_LONG *, const BF_KEY *); BF_decrypt(BF_LONG *, const BF_KEY *);
|
1.5.10.2 | 12-Sep-2003 |
tron | Pull up revision 1.7 (requested by tv in ticket #1455): Include <sys/types.h> to allow compilation to occur.
|
1.5.10.1 | 12-Sep-2003 |
tron | Pull up revision 1.6 (requested by tv in ticket #1455): repoint include file for kernel use.
|
1.8.6.5 | 10-Nov-2005 |
skrll | Sync with HEAD. Here we go again...
|
1.8.6.4 | 04-Mar-2005 |
skrll | Sync with HEAD.
Hi Perry!
|
1.8.6.3 | 21-Sep-2004 |
skrll | Fix the sync with head I botched.
|
1.8.6.2 | 18-Sep-2004 |
skrll | Sync with HEAD.
|
1.8.6.1 | 03-Aug-2004 |
skrll | Sync with HEAD
|
1.9.10.1 | 19-Mar-2005 |
yamt | sync with head. xen and whitespace. xen part is not finished.
|
1.9.8.1 | 29-Apr-2005 |
kent | sync with -current
|
1.3 | 27-May-2001 |
itojun | remove files we no longer need/maintain. sync with kame
|
1.2 | 31-Aug-2000 |
itojun | branches: 1.2.2; 1.2.4; make the code friendly with LP64 machines. - use u_int32_t for 32bit quantity unsigned integer type. - s/unsigned long/BF_LONG/ (BF_LONG = u_int32_t) where appropriate. - prototype cleanup - due to *BSD code sharing, we still are using __P(). part of PR 10918. sync with kame.
|
1.1 | 14-Jun-2000 |
thorpej | branches: 1.1.1; Initial revision
|
1.1.1.1 | 14-Jun-2000 |
thorpej | branches: 1.1.1.1.2; 1.1.1.1.4; Import the IPsec crypto code from netbsd-cryptosrc-intl.
|
1.1.1.1.4.2 | 22-Jun-2000 |
minoura | Sync w/ netbsd-1-5-base.
|
1.1.1.1.4.1 | 14-Jun-2000 |
minoura | file bf_cbc_m.c was added on branch minoura-xpg4dl on 2000-06-22 17:05:58 +0000
|
1.1.1.1.2.1 | 31-Aug-2000 |
itojun | pullup 1.1 -> 1.2 (for all files) - approved by releng-1-5
without the fix, blowfish encryption function panics the kernel, on LP64 arch.
>make the code friendly with LP64 machines. >- use u_int32_t for 32bit quantity unsigned integer type. >- s/unsigned long/BF_LONG/ (BF_LONG = u_int32_t) where appropriate. >- prototype cleanup - due to *BSD code sharing, we still are using __P(). >part of PR 10918. sync with kame.
|
1.2.4.1 | 28-Feb-2002 |
nathanw | Catch up to -current.
|
1.2.2.2 | 20-Nov-2000 |
bouyer | Update thorpej_scsipi to -current as of a month ago
|
1.2.2.1 | 31-Aug-2000 |
bouyer | file bf_cbc_m.c was added on branch thorpej_scsipi on 2000-11-20 22:21:42 +0000
|
1.3 | 11-Dec-2005 |
christos | merge ktrace-lwp.
|
1.2 | 26-Feb-2005 |
perry | nuke trailing whitespace
|
1.1 | 26-Aug-2003 |
thorpej | branches: 1.1.4; 1.1.10; 1.1.12; * Const poison, ANSI'ify, like newer OpenSSL Blowfish code. * Add a BF_ecb_encrypt(), which makes for a prettier interface than using BF_encrypt()/BF_decrypt() directly.
|
1.1.12.1 | 19-Mar-2005 |
yamt | sync with head. xen and whitespace. xen part is not finished.
|
1.1.10.1 | 29-Apr-2005 |
kent | sync with -current
|
1.1.4.5 | 04-Mar-2005 |
skrll | Sync with HEAD.
Hi Perry!
|
1.1.4.4 | 21-Sep-2004 |
skrll | Fix the sync with head I botched.
|
1.1.4.3 | 18-Sep-2004 |
skrll | Sync with HEAD.
|
1.1.4.2 | 03-Aug-2004 |
skrll | Sync with HEAD
|
1.1.4.1 | 26-Aug-2003 |
skrll | file bf_ecb.c was added on branch ktrace-lwp on 2004-08-03 10:44:45 +0000
|
1.11 | 05-Feb-2024 |
andvar | fix various typos in comments.
|
1.10 | 11-Dec-2005 |
christos | merge ktrace-lwp.
|
1.9 | 27-Aug-2003 |
thorpej | Add missing RCS ID.
|
1.8 | 27-Aug-2003 |
tron | Fix build problem caused by adding "const", remove "register" usage.
|
1.7 | 26-Aug-2003 |
thorpej | * Const poison, ANSI'ify, like newer OpenSSL Blowfish code. * Add a BF_ecb_encrypt(), which makes for a prettier interface than using BF_encrypt()/BF_decrypt() directly.
|
1.6 | 27-Feb-2002 |
itojun | branches: 1.6.16; sync blowfish function prototype between i386 assembly and C. From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
|
1.5 | 13-Nov-2001 |
lukem | add RCSIDs
|
1.4 | 09-Sep-2001 |
tls | Add asm versions of blowfish and des transforms for i386.
This also involved updating the in-kernel DES functions to correspond to the versions in our in-tree OpenSSL, because the des_SPtrans table has changed; the asm code will not work with the old permutation table!
C and i386 asm code for the DES, 3DES, and Blowfish CBC modes is also included; it is not currently built as the ESP processing in esp_core.c splits the CBC operation and the cipher transform apart. Hopefully that will be fixed as there is a substantial performance improvement to be had from doing so. It will remain necessary to use the C version of the Blowfish CBC function on some i386 machines, however, as the asm version uses bswapl, which ony 486 and later processors have. The DES CBC code doesn't have this problem.
Finally, change esp_core.c to use the ecb3_encrypt function instead of calling ecb_encrypt three times; this improves performance a bit, in particular in the asm case.
|
1.3 | 06-Nov-2000 |
itojun | branches: 1.3.2; 1.3.4; 1.3.6; 1.3.8; sync with kame. - include string.h (instead of sys/systm.h) on userland compilation. make compilation under src/regress/sys/crypto happier. from minoura - (blowfish) KNF.
|
1.2 | 31-Aug-2000 |
itojun | make the code friendly with LP64 machines. - use u_int32_t for 32bit quantity unsigned integer type. - s/unsigned long/BF_LONG/ (BF_LONG = u_int32_t) where appropriate. - prototype cleanup - due to *BSD code sharing, we still are using __P(). part of PR 10918. sync with kame.
|
1.1 | 14-Jun-2000 |
thorpej | branches: 1.1.1; Initial revision
|
1.1.1.1 | 14-Jun-2000 |
thorpej | branches: 1.1.1.1.2; 1.1.1.1.4; Import the IPsec crypto code from netbsd-cryptosrc-intl.
|
1.1.1.1.4.2 | 22-Jun-2000 |
minoura | Sync w/ netbsd-1-5-base.
|
1.1.1.1.4.1 | 14-Jun-2000 |
minoura | file bf_enc.c was added on branch minoura-xpg4dl on 2000-06-22 17:06:01 +0000
|
1.1.1.1.2.1 | 31-Aug-2000 |
itojun | pullup 1.1 -> 1.2 (for all files) - approved by releng-1-5
without the fix, blowfish encryption function panics the kernel, on LP64 arch.
>make the code friendly with LP64 machines. >- use u_int32_t for 32bit quantity unsigned integer type. >- s/unsigned long/BF_LONG/ (BF_LONG = u_int32_t) where appropriate. >- prototype cleanup - due to *BSD code sharing, we still are using __P(). >part of PR 10918. sync with kame.
|
1.3.8.1 | 01-Oct-2001 |
fvdl | Catch up with -current.
|
1.3.6.3 | 16-Mar-2002 |
jdolecek | Catch up with -current.
|
1.3.6.2 | 10-Jan-2002 |
thorpej | Sync kqueue branch with -current.
|
1.3.6.1 | 13-Sep-2001 |
thorpej | Update the kqueue branch to HEAD.
|
1.3.4.3 | 28-Feb-2002 |
nathanw | Catch up to -current.
|
1.3.4.2 | 14-Nov-2001 |
nathanw | Catch up to -current.
|
1.3.4.1 | 21-Sep-2001 |
nathanw | Catch up to -current.
|
1.3.2.3 | 22-Nov-2000 |
bouyer | Sync with HEAD.
|
1.3.2.2 | 20-Nov-2000 |
bouyer | Update thorpej_scsipi to -current as of a month ago
|
1.3.2.1 | 06-Nov-2000 |
bouyer | file bf_enc.c was added on branch thorpej_scsipi on 2000-11-20 22:21:42 +0000
|
1.6.16.3 | 21-Sep-2004 |
skrll | Fix the sync with head I botched.
|
1.6.16.2 | 18-Sep-2004 |
skrll | Sync with HEAD.
|
1.6.16.1 | 03-Aug-2004 |
skrll | Sync with HEAD
|
1.8 | 16-Apr-2022 |
andvar | fix various typos in comments and log messages.
|
1.7 | 15-Oct-2021 |
andvar | fix typos in comments.
|
1.6 | 04-Feb-2019 |
mrg | add fallthru comments. i considered patching makefiles to ignore these problems, but this code is dead upstream and likely will be removed here rather than ever updated.
|
1.5 | 30-Jun-2009 |
pooka | branches: 1.5.64; Apply const where necessary (XXX: where is bf_locl.org?)
|
1.4 | 11-Dec-2005 |
christos | branches: 1.4.74; 1.4.90; merge ktrace-lwp.
|
1.3 | 03-Jun-2005 |
martin | Constify, to make it compile (at least).
XXX - I'm not sure with what args this is called, but my bet is that there is no chance this code will work on alignment requiring archs.
|
1.2 | 31-Aug-2000 |
itojun | branches: 1.2.2; 1.2.26; make the code friendly with LP64 machines. - use u_int32_t for 32bit quantity unsigned integer type. - s/unsigned long/BF_LONG/ (BF_LONG = u_int32_t) where appropriate. - prototype cleanup - due to *BSD code sharing, we still are using __P(). part of PR 10918. sync with kame.
|
1.1 | 14-Jun-2000 |
thorpej | branches: 1.1.1; Initial revision
|
1.1.1.1 | 14-Jun-2000 |
thorpej | branches: 1.1.1.1.2; 1.1.1.1.4; Import the IPsec crypto code from netbsd-cryptosrc-intl.
|
1.1.1.1.4.2 | 22-Jun-2000 |
minoura | Sync w/ netbsd-1-5-base.
|
1.1.1.1.4.1 | 14-Jun-2000 |
minoura | file bf_locl.h was added on branch minoura-xpg4dl on 2000-06-22 17:06:02 +0000
|
1.1.1.1.2.1 | 31-Aug-2000 |
itojun | pullup 1.1 -> 1.2 (for all files) - approved by releng-1-5
without the fix, blowfish encryption function panics the kernel, on LP64 arch.
>make the code friendly with LP64 machines. >- use u_int32_t for 32bit quantity unsigned integer type. >- s/unsigned long/BF_LONG/ (BF_LONG = u_int32_t) where appropriate. >- prototype cleanup - due to *BSD code sharing, we still are using __P(). >part of PR 10918. sync with kame.
|
1.2.26.1 | 10-Nov-2005 |
skrll | Sync with HEAD. Here we go again...
|
1.2.2.2 | 20-Nov-2000 |
bouyer | Update thorpej_scsipi to -current as of a month ago
|
1.2.2.1 | 31-Aug-2000 |
bouyer | file bf_locl.h was added on branch thorpej_scsipi on 2000-11-20 22:21:42 +0000
|
1.4.90.1 | 23-Jul-2009 |
jym | Sync with HEAD.
|
1.4.74.1 | 18-Jul-2009 |
yamt | sync with head.
|
1.5.64.1 | 10-Jun-2019 |
christos | Sync with HEAD
|
1.1 | 01-Jan-2014 |
pgoyette | branches: 1.1.4; 1.1.6; 1.1.10; Create modules for software crypto components.
|
1.1.10.2 | 20-Aug-2014 |
tls | Rebase to HEAD as of a few days ago.
|
1.1.10.1 | 01-Jan-2014 |
tls | file bf_module.c was added on branch tls-maxphys on 2014-08-20 00:03:34 +0000
|
1.1.6.2 | 22-May-2014 |
yamt | sync with head.
for a reference, the tree before this commit was tagged as yamt-pagecache-tag8.
this commit was splitted into small chunks to avoid a limitation of cvs. ("Protocol error: too many arguments")
|
1.1.6.1 | 01-Jan-2014 |
yamt | file bf_module.c was added on branch yamt-pagecache on 2014-05-22 11:40:18 +0000
|
1.1.4.2 | 18-May-2014 |
rmind | sync with head
|
1.1.4.1 | 01-Jan-2014 |
rmind | file bf_module.c was added on branch rmind-smpnet on 2014-05-18 17:45:34 +0000
|
1.2 | 21-Feb-2001 |
jdolecek | make some more constant arrays 'const'
|
1.1 | 14-Jun-2000 |
thorpej | branches: 1.1.1; Initial revision
|
1.1.1.1 | 14-Jun-2000 |
thorpej | branches: 1.1.1.1.4; 1.1.1.1.6; Import the IPsec crypto code from netbsd-cryptosrc-intl.
|
1.1.1.1.6.3 | 12-Mar-2001 |
bouyer | Sync with HEAD.
|
1.1.1.1.6.2 | 20-Nov-2000 |
bouyer | Update thorpej_scsipi to -current as of a month ago
|
1.1.1.1.6.1 | 14-Jun-2000 |
bouyer | file bf_pi.h was added on branch thorpej_scsipi on 2000-11-20 22:21:42 +0000
|
1.1.1.1.4.2 | 22-Jun-2000 |
minoura | Sync w/ netbsd-1-5-base.
|
1.1.1.1.4.1 | 14-Jun-2000 |
minoura | file bf_pi.h was added on branch minoura-xpg4dl on 2000-06-22 17:06:02 +0000
|
1.6 | 11-Dec-2005 |
christos | merge ktrace-lwp.
|
1.5 | 26-Aug-2003 |
thorpej | * Const poison, ANSI'ify, like newer OpenSSL Blowfish code. * Add a BF_ecb_encrypt(), which makes for a prettier interface than using BF_encrypt()/BF_decrypt() directly.
|
1.4 | 27-Feb-2002 |
itojun | branches: 1.4.16; sync blowfish function prototype between i386 assembly and C. From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
|
1.3 | 13-Nov-2001 |
lukem | add RCSIDs
|
1.2 | 06-Nov-2000 |
itojun | branches: 1.2.2; 1.2.4; 1.2.6; sync with kame. - include string.h (instead of sys/systm.h) on userland compilation. make compilation under src/regress/sys/crypto happier. from minoura - (blowfish) KNF.
|
1.1 | 14-Jun-2000 |
thorpej | branches: 1.1.1; Initial revision
|
1.1.1.1 | 14-Jun-2000 |
thorpej | branches: 1.1.1.1.4; Import the IPsec crypto code from netbsd-cryptosrc-intl.
|
1.1.1.1.4.2 | 22-Jun-2000 |
minoura | Sync w/ netbsd-1-5-base.
|
1.1.1.1.4.1 | 14-Jun-2000 |
minoura | file bf_skey.c was added on branch minoura-xpg4dl on 2000-06-22 17:06:03 +0000
|
1.2.6.2 | 16-Mar-2002 |
jdolecek | Catch up with -current.
|
1.2.6.1 | 10-Jan-2002 |
thorpej | Sync kqueue branch with -current.
|
1.2.4.2 | 28-Feb-2002 |
nathanw | Catch up to -current.
|
1.2.4.1 | 14-Nov-2001 |
nathanw | Catch up to -current.
|
1.2.2.3 | 22-Nov-2000 |
bouyer | Sync with HEAD.
|
1.2.2.2 | 20-Nov-2000 |
bouyer | Update thorpej_scsipi to -current as of a month ago
|
1.2.2.1 | 06-Nov-2000 |
bouyer | file bf_skey.c was added on branch thorpej_scsipi on 2000-11-20 22:21:42 +0000
|
1.4.16.3 | 21-Sep-2004 |
skrll | Fix the sync with head I botched.
|
1.4.16.2 | 18-Sep-2004 |
skrll | Sync with HEAD.
|
1.4.16.1 | 03-Aug-2004 |
skrll | Sync with HEAD
|
1.8 | 14-Mar-2009 |
dsl | Remove all the __P() from sys (excluding sys/dist) Diff checked with grep and MK1 eyeball. i386 and amd64 GENERIC and sys still build.
|
1.7 | 11-Dec-2005 |
christos | branches: 1.7.74; 1.7.84; 1.7.90; merge ktrace-lwp.
|
1.6 | 26-Aug-2003 |
thorpej | * Const poison, ANSI'ify, like newer OpenSSL Blowfish code. * Add a BF_ecb_encrypt(), which makes for a prettier interface than using BF_encrypt()/BF_decrypt() directly.
|
1.5 | 27-Feb-2002 |
itojun | branches: 1.5.16; sync blowfish function prototype between i386 assembly and C. From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
|
1.4 | 09-Sep-2001 |
tls | Add asm versions of blowfish and des transforms for i386.
This also involved updating the in-kernel DES functions to correspond to the versions in our in-tree OpenSSL, because the des_SPtrans table has changed; the asm code will not work with the old permutation table!
C and i386 asm code for the DES, 3DES, and Blowfish CBC modes is also included; it is not currently built as the ESP processing in esp_core.c splits the CBC operation and the cipher transform apart. Hopefully that will be fixed as there is a substantial performance improvement to be had from doing so. It will remain necessary to use the C version of the Blowfish CBC function on some i386 machines, however, as the asm version uses bswapl, which ony 486 and later processors have. The DES CBC code doesn't have this problem.
Finally, change esp_core.c to use the ecb3_encrypt function instead of calling ecb_encrypt three times; this improves performance a bit, in particular in the asm case.
|
1.3 | 06-Nov-2000 |
itojun | branches: 1.3.2; 1.3.4; 1.3.6; 1.3.8; sync with kame. - include string.h (instead of sys/systm.h) on userland compilation. make compilation under src/regress/sys/crypto happier. from minoura - (blowfish) KNF.
|
1.2 | 31-Aug-2000 |
itojun | make the code friendly with LP64 machines. - use u_int32_t for 32bit quantity unsigned integer type. - s/unsigned long/BF_LONG/ (BF_LONG = u_int32_t) where appropriate. - prototype cleanup - due to *BSD code sharing, we still are using __P(). part of PR 10918. sync with kame.
|
1.1 | 14-Jun-2000 |
thorpej | branches: 1.1.1; Initial revision
|
1.1.1.1 | 14-Jun-2000 |
thorpej | branches: 1.1.1.1.2; 1.1.1.1.4; Import the IPsec crypto code from netbsd-cryptosrc-intl.
|
1.1.1.1.4.2 | 22-Jun-2000 |
minoura | Sync w/ netbsd-1-5-base.
|
1.1.1.1.4.1 | 14-Jun-2000 |
minoura | file blowfish.h was added on branch minoura-xpg4dl on 2000-06-22 17:06:04 +0000
|
1.1.1.1.2.1 | 31-Aug-2000 |
itojun | pullup 1.1 -> 1.2 (for all files) - approved by releng-1-5
without the fix, blowfish encryption function panics the kernel, on LP64 arch.
>make the code friendly with LP64 machines. >- use u_int32_t for 32bit quantity unsigned integer type. >- s/unsigned long/BF_LONG/ (BF_LONG = u_int32_t) where appropriate. >- prototype cleanup - due to *BSD code sharing, we still are using __P(). >part of PR 10918. sync with kame.
|
1.3.8.1 | 01-Oct-2001 |
fvdl | Catch up with -current.
|
1.3.6.2 | 16-Mar-2002 |
jdolecek | Catch up with -current.
|
1.3.6.1 | 13-Sep-2001 |
thorpej | Update the kqueue branch to HEAD.
|
1.3.4.2 | 28-Feb-2002 |
nathanw | Catch up to -current.
|
1.3.4.1 | 21-Sep-2001 |
nathanw | Catch up to -current.
|
1.3.2.3 | 22-Nov-2000 |
bouyer | Sync with HEAD.
|
1.3.2.2 | 20-Nov-2000 |
bouyer | Update thorpej_scsipi to -current as of a month ago
|
1.3.2.1 | 06-Nov-2000 |
bouyer | file blowfish.h was added on branch thorpej_scsipi on 2000-11-20 22:21:43 +0000
|
1.5.16.3 | 21-Sep-2004 |
skrll | Fix the sync with head I botched.
|
1.5.16.2 | 18-Sep-2004 |
skrll | Sync with HEAD.
|
1.5.16.1 | 03-Aug-2004 |
skrll | Sync with HEAD
|
1.7.90.1 | 13-May-2009 |
jym | Sync with HEAD.
Commit is split, to avoid a "too many arguments" protocol error.
|
1.7.84.1 | 28-Apr-2009 |
skrll | Sync with HEAD.
|
1.7.74.1 | 04-May-2009 |
yamt | sync with head.
|
1.4 | 01-Jan-2014 |
pgoyette | Create modules for software crypto components.
|
1.3 | 11-Dec-2005 |
christos | branches: 1.3.110; 1.3.120; 1.3.126; merge ktrace-lwp.
|
1.2 | 26-Aug-2003 |
thorpej | * Const poison, ANSI'ify, like newer OpenSSL Blowfish code. * Add a BF_ecb_encrypt(), which makes for a prettier interface than using BF_encrypt()/BF_decrypt() directly.
|
1.1 | 11-Oct-2002 |
thorpej | branches: 1.1.2; 1.1.8; * Move config defns for the crypto algorithms into their own files. Define an attribute for each crypto algorithm, and use that attribute to select the files that implement the algorithm. * Give the "wlan" attribute a dependency on the "arc4" attribute. * Give the "cgd" pseudo-device the "des", "blowfish", "cast128", and "rijndael" attributes. * Use the new attribute-as-option-dependencies feature of config(8) to give the IPSEC_ESP option dependencies on the "des", "blowfish", "cast128", and "rijndael" attributes.
|
1.1.8.3 | 21-Sep-2004 |
skrll | Fix the sync with head I botched.
|
1.1.8.2 | 18-Sep-2004 |
skrll | Sync with HEAD.
|
1.1.8.1 | 03-Aug-2004 |
skrll | Sync with HEAD
|
1.1.2.2 | 18-Oct-2002 |
nathanw | Catch up to -current.
|
1.1.2.1 | 11-Oct-2002 |
nathanw | file files.blowfish was added on branch nathanw_sa on 2002-10-18 02:41:21 +0000
|
1.3.126.1 | 18-May-2014 |
rmind | sync with head
|
1.3.120.1 | 20-Aug-2014 |
tls | Rebase to HEAD as of a few days ago.
|
1.3.110.1 | 22-May-2014 |
yamt | sync with head.
for a reference, the tree before this commit was tagged as yamt-pagecache-tag8.
this commit was splitted into small chunks to avoid a limitation of cvs. ("Protocol error: too many arguments")
|
1.6 | 11-Dec-2007 |
lukem | use __KERNEL_RCSID()
|
1.5 | 11-Dec-2005 |
christos | branches: 1.5.46; 1.5.56; 1.5.58; 1.5.60; merge ktrace-lwp.
|
1.4 | 26-Feb-2005 |
perry | branches: 1.4.4; nuke trailing whitespace
|
1.3 | 28-Nov-2003 |
keihan | branches: 1.3.8; 1.3.10; s/netbsd.org/NetBSD.org/g
|
1.2 | 12-Nov-2002 |
itohy | branches: 1.2.6; add non-ELF .align
|
1.1 | 09-Sep-2001 |
tls | branches: 1.1.2; 1.1.6; 1.1.14; Add asm versions of blowfish and des transforms for i386.
This also involved updating the in-kernel DES functions to correspond to the versions in our in-tree OpenSSL, because the des_SPtrans table has changed; the asm code will not work with the old permutation table!
C and i386 asm code for the DES, 3DES, and Blowfish CBC modes is also included; it is not currently built as the ESP processing in esp_core.c splits the CBC operation and the cipher transform apart. Hopefully that will be fixed as there is a substantial performance improvement to be had from doing so. It will remain necessary to use the C version of the Blowfish CBC function on some i386 machines, however, as the asm version uses bswapl, which ony 486 and later processors have. The DES CBC code doesn't have this problem.
Finally, change esp_core.c to use the ecb3_encrypt function instead of calling ecb_encrypt three times; this improves performance a bit, in particular in the asm case.
|
1.1.14.3 | 11-Dec-2002 |
thorpej | Sync with HEAD.
|
1.1.14.2 | 01-Apr-2002 |
nathanw | Add a few files missed in the merge.
|
1.1.14.1 | 09-Sep-2001 |
nathanw | file bf_cbc.S was added on branch nathanw_sa on 2002-04-01 18:48:04 +0000
|
1.1.6.2 | 07-Feb-2002 |
jdolecek | add manually to the branch - these were somehow missed on merge
|
1.1.6.1 | 09-Sep-2001 |
jdolecek | file bf_cbc.S was added on branch kqueue on 2002-02-07 07:09:48 +0000
|
1.1.2.2 | 01-Oct-2001 |
fvdl | Catch up with -current.
|
1.1.2.1 | 09-Sep-2001 |
fvdl | file bf_cbc.S was added on branch thorpej-devvp on 2001-10-01 12:44:02 +0000
|
1.2.6.4 | 04-Mar-2005 |
skrll | Sync with HEAD.
Hi Perry!
|
1.2.6.3 | 21-Sep-2004 |
skrll | Fix the sync with head I botched.
|
1.2.6.2 | 18-Sep-2004 |
skrll | Sync with HEAD.
|
1.2.6.1 | 03-Aug-2004 |
skrll | Sync with HEAD
|
1.3.10.1 | 19-Mar-2005 |
yamt | sync with head. xen and whitespace. xen part is not finished.
|
1.3.8.1 | 29-Apr-2005 |
kent | sync with -current
|
1.4.4.1 | 21-Jan-2008 |
yamt | sync with head
|
1.5.60.1 | 13-Dec-2007 |
bouyer | Sync with HEAD
|
1.5.58.1 | 13-Dec-2007 |
yamt | sync with head.
|
1.5.56.1 | 26-Dec-2007 |
ad | Sync with head.
|
1.5.46.1 | 09-Jan-2008 |
matt | sync with HEAD
|
1.4 | 11-Dec-2007 |
lukem | use __KERNEL_RCSID()
|
1.3 | 11-Dec-2005 |
christos | branches: 1.3.46; 1.3.56; 1.3.58; 1.3.60; merge ktrace-lwp.
|
1.2 | 28-Nov-2003 |
keihan | branches: 1.2.16; s/netbsd.org/NetBSD.org/g
|
1.1 | 09-Sep-2001 |
tls | branches: 1.1.2; 1.1.6; 1.1.14; 1.1.24; Add asm versions of blowfish and des transforms for i386.
This also involved updating the in-kernel DES functions to correspond to the versions in our in-tree OpenSSL, because the des_SPtrans table has changed; the asm code will not work with the old permutation table!
C and i386 asm code for the DES, 3DES, and Blowfish CBC modes is also included; it is not currently built as the ESP processing in esp_core.c splits the CBC operation and the cipher transform apart. Hopefully that will be fixed as there is a substantial performance improvement to be had from doing so. It will remain necessary to use the C version of the Blowfish CBC function on some i386 machines, however, as the asm version uses bswapl, which ony 486 and later processors have. The DES CBC code doesn't have this problem.
Finally, change esp_core.c to use the ecb3_encrypt function instead of calling ecb_encrypt three times; this improves performance a bit, in particular in the asm case.
|
1.1.24.3 | 21-Sep-2004 |
skrll | Fix the sync with head I botched.
|
1.1.24.2 | 18-Sep-2004 |
skrll | Sync with HEAD.
|
1.1.24.1 | 03-Aug-2004 |
skrll | Sync with HEAD
|
1.1.14.2 | 01-Apr-2002 |
nathanw | Add a few files missed in the merge.
|
1.1.14.1 | 09-Sep-2001 |
nathanw | file bf_enc.S was added on branch nathanw_sa on 2002-04-01 18:48:05 +0000
|
1.1.6.2 | 07-Feb-2002 |
jdolecek | add manually to the branch - these were somehow missed on merge
|
1.1.6.1 | 09-Sep-2001 |
jdolecek | file bf_enc.S was added on branch kqueue on 2002-02-07 07:09:49 +0000
|
1.1.2.2 | 01-Oct-2001 |
fvdl | Catch up with -current.
|
1.1.2.1 | 09-Sep-2001 |
fvdl | file bf_enc.S was added on branch thorpej-devvp on 2001-10-01 12:44:02 +0000
|
1.2.16.1 | 21-Jan-2008 |
yamt | sync with head
|
1.3.60.1 | 13-Dec-2007 |
bouyer | Sync with HEAD
|
1.3.58.1 | 13-Dec-2007 |
yamt | sync with head.
|
1.3.56.1 | 26-Dec-2007 |
ad | Sync with head.
|
1.3.46.1 | 09-Jan-2008 |
matt | sync with HEAD
|
1.5 | 11-Dec-2007 |
lukem | use __KERNEL_RCSID()
|
1.4 | 11-Dec-2005 |
christos | branches: 1.4.46; 1.4.56; 1.4.58; 1.4.60; merge ktrace-lwp.
|
1.3 | 26-Feb-2005 |
perry | branches: 1.3.4; nuke trailing whitespace
|
1.2 | 28-Nov-2003 |
keihan | branches: 1.2.8; 1.2.10; s/netbsd.org/NetBSD.org/g
|
1.1 | 09-Sep-2001 |
tls | branches: 1.1.2; 1.1.6; 1.1.14; 1.1.24; Add asm versions of blowfish and des transforms for i386.
This also involved updating the in-kernel DES functions to correspond to the versions in our in-tree OpenSSL, because the des_SPtrans table has changed; the asm code will not work with the old permutation table!
C and i386 asm code for the DES, 3DES, and Blowfish CBC modes is also included; it is not currently built as the ESP processing in esp_core.c splits the CBC operation and the cipher transform apart. Hopefully that will be fixed as there is a substantial performance improvement to be had from doing so. It will remain necessary to use the C version of the Blowfish CBC function on some i386 machines, however, as the asm version uses bswapl, which ony 486 and later processors have. The DES CBC code doesn't have this problem.
Finally, change esp_core.c to use the ecb3_encrypt function instead of calling ecb_encrypt three times; this improves performance a bit, in particular in the asm case.
|
1.1.24.4 | 04-Mar-2005 |
skrll | Sync with HEAD.
Hi Perry!
|
1.1.24.3 | 21-Sep-2004 |
skrll | Fix the sync with head I botched.
|
1.1.24.2 | 18-Sep-2004 |
skrll | Sync with HEAD.
|
1.1.24.1 | 03-Aug-2004 |
skrll | Sync with HEAD
|
1.1.14.2 | 01-Apr-2002 |
nathanw | Add a few files missed in the merge.
|
1.1.14.1 | 09-Sep-2001 |
nathanw | file bf_enc_586.S was added on branch nathanw_sa on 2002-04-01 18:48:05 +0000
|
1.1.6.2 | 07-Feb-2002 |
jdolecek | add manually to the branch - these were somehow missed on merge
|
1.1.6.1 | 09-Sep-2001 |
jdolecek | file bf_enc_586.S was added on branch kqueue on 2002-02-07 07:09:49 +0000
|
1.1.2.2 | 01-Oct-2001 |
fvdl | Catch up with -current.
|
1.1.2.1 | 09-Sep-2001 |
fvdl | file bf_enc_586.S was added on branch thorpej-devvp on 2001-10-01 12:44:02 +0000
|
1.2.10.1 | 19-Mar-2005 |
yamt | sync with head. xen and whitespace. xen part is not finished.
|
1.2.8.1 | 29-Apr-2005 |
kent | sync with -current
|
1.3.4.1 | 21-Jan-2008 |
yamt | sync with head
|
1.4.60.1 | 13-Dec-2007 |
bouyer | Sync with HEAD
|
1.4.58.1 | 13-Dec-2007 |
yamt | sync with head.
|
1.4.56.1 | 26-Dec-2007 |
ad | Sync with head.
|
1.4.46.1 | 09-Jan-2008 |
matt | sync with HEAD
|
1.5 | 11-Dec-2007 |
lukem | use __KERNEL_RCSID()
|
1.4 | 11-Dec-2005 |
christos | branches: 1.4.46; 1.4.56; 1.4.58; 1.4.60; merge ktrace-lwp.
|
1.3 | 26-Feb-2005 |
perry | branches: 1.3.4; nuke trailing whitespace
|
1.2 | 28-Nov-2003 |
keihan | branches: 1.2.8; 1.2.10; s/netbsd.org/NetBSD.org/g
|
1.1 | 09-Sep-2001 |
tls | branches: 1.1.2; 1.1.6; 1.1.14; 1.1.24; Add asm versions of blowfish and des transforms for i386.
This also involved updating the in-kernel DES functions to correspond to the versions in our in-tree OpenSSL, because the des_SPtrans table has changed; the asm code will not work with the old permutation table!
C and i386 asm code for the DES, 3DES, and Blowfish CBC modes is also included; it is not currently built as the ESP processing in esp_core.c splits the CBC operation and the cipher transform apart. Hopefully that will be fixed as there is a substantial performance improvement to be had from doing so. It will remain necessary to use the C version of the Blowfish CBC function on some i386 machines, however, as the asm version uses bswapl, which ony 486 and later processors have. The DES CBC code doesn't have this problem.
Finally, change esp_core.c to use the ecb3_encrypt function instead of calling ecb_encrypt three times; this improves performance a bit, in particular in the asm case.
|
1.1.24.4 | 04-Mar-2005 |
skrll | Sync with HEAD.
Hi Perry!
|
1.1.24.3 | 21-Sep-2004 |
skrll | Fix the sync with head I botched.
|
1.1.24.2 | 18-Sep-2004 |
skrll | Sync with HEAD.
|
1.1.24.1 | 03-Aug-2004 |
skrll | Sync with HEAD
|
1.1.14.2 | 01-Apr-2002 |
nathanw | Add a few files missed in the merge.
|
1.1.14.1 | 09-Sep-2001 |
nathanw | file bf_enc_686.S was added on branch nathanw_sa on 2002-04-01 18:48:05 +0000
|
1.1.6.2 | 07-Feb-2002 |
jdolecek | add manually to the branch - these were somehow missed on merge
|
1.1.6.1 | 09-Sep-2001 |
jdolecek | file bf_enc_686.S was added on branch kqueue on 2002-02-07 07:09:49 +0000
|
1.1.2.2 | 01-Oct-2001 |
fvdl | Catch up with -current.
|
1.1.2.1 | 09-Sep-2001 |
fvdl | file bf_enc_686.S was added on branch thorpej-devvp on 2001-10-01 12:44:03 +0000
|
1.2.10.1 | 19-Mar-2005 |
yamt | sync with head. xen and whitespace. xen part is not finished.
|
1.2.8.1 | 29-Apr-2005 |
kent | sync with -current
|
1.3.4.1 | 21-Jan-2008 |
yamt | sync with head
|
1.4.60.1 | 13-Dec-2007 |
bouyer | Sync with HEAD
|
1.4.58.1 | 13-Dec-2007 |
yamt | sync with head.
|
1.4.56.1 | 26-Dec-2007 |
ad | Sync with head.
|
1.4.46.1 | 09-Jan-2008 |
matt | sync with HEAD
|
1.2 | 04-Sep-2021 |
gutteridge | Fix typos in comments and add missing KERNEL_RCSID
|
1.1 | 05-May-2011 |
drochner | branches: 1.1.2; 1.1.6; add "camellia" crypto code, copied from FreeBSD
|
1.1.6.2 | 06-Jun-2011 |
jruoho | Sync with HEAD.
|
1.1.6.1 | 05-May-2011 |
jruoho | file camellia-api.c was added on branch jruoho-x86intr on 2011-06-06 09:07:36 +0000
|
1.1.2.2 | 31-May-2011 |
rmind | sync with head
|
1.1.2.1 | 05-May-2011 |
rmind | file camellia-api.c was added on branch rmind-uvmplock on 2011-05-31 03:04:33 +0000
|
1.3 | 04-Sep-2021 |
gutteridge | Fix typos in comments and add missing KERNEL_RCSID
|
1.2 | 01-Jan-2014 |
pgoyette | Create modules for software crypto components.
|
1.1 | 05-May-2011 |
drochner | branches: 1.1.2; 1.1.6; 1.1.8; 1.1.18; 1.1.22; add "camellia" crypto code, copied from FreeBSD
|
1.1.22.1 | 18-May-2014 |
rmind | sync with head
|
1.1.18.1 | 20-Aug-2014 |
tls | Rebase to HEAD as of a few days ago.
|
1.1.8.1 | 22-May-2014 |
yamt | sync with head.
for a reference, the tree before this commit was tagged as yamt-pagecache-tag8.
this commit was splitted into small chunks to avoid a limitation of cvs. ("Protocol error: too many arguments")
|
1.1.6.2 | 06-Jun-2011 |
jruoho | Sync with HEAD.
|
1.1.6.1 | 05-May-2011 |
jruoho | file camellia.c was added on branch jruoho-x86intr on 2011-06-06 09:07:36 +0000
|
1.1.2.2 | 31-May-2011 |
rmind | sync with head
|
1.1.2.1 | 05-May-2011 |
rmind | file camellia.c was added on branch rmind-uvmplock on 2011-05-31 03:04:33 +0000
|
1.1 | 05-May-2011 |
drochner | branches: 1.1.2; 1.1.6; add "camellia" crypto code, copied from FreeBSD
|
1.1.6.2 | 06-Jun-2011 |
jruoho | Sync with HEAD.
|
1.1.6.1 | 05-May-2011 |
jruoho | file camellia.h was added on branch jruoho-x86intr on 2011-06-06 09:07:36 +0000
|
1.1.2.2 | 31-May-2011 |
rmind | sync with head
|
1.1.2.1 | 05-May-2011 |
rmind | file camellia.h was added on branch rmind-uvmplock on 2011-05-31 03:04:33 +0000
|
1.1 | 05-May-2011 |
drochner | branches: 1.1.2; 1.1.6; add "camellia" crypto code, copied from FreeBSD
|
1.1.6.2 | 06-Jun-2011 |
jruoho | Sync with HEAD.
|
1.1.6.1 | 05-May-2011 |
jruoho | file files.camellia was added on branch jruoho-x86intr on 2011-06-06 09:07:36 +0000
|
1.1.2.2 | 31-May-2011 |
rmind | sync with head
|
1.1.2.1 | 05-May-2011 |
rmind | file files.camellia was added on branch rmind-uvmplock on 2011-05-31 03:04:33 +0000
|
1.10 | 01-Jan-2014 |
pgoyette | Create modules for software crypto components.
|
1.9 | 10-May-2006 |
mrg | branches: 1.9.98; 1.9.108; 1.9.114; quell GCC 4.1 uninitialised variable warnings.
XXX: we should audit the tree for which old ones are no longer needed after getting the older compilers out of the tree..
|
1.8 | 11-Dec-2005 |
christos | branches: 1.8.4; 1.8.6; 1.8.8; 1.8.10; 1.8.12; merge ktrace-lwp.
|
1.7 | 26-Aug-2003 |
thorpej | branches: 1.7.16; Const poison.
|
1.6 | 26-Aug-2003 |
thorpej | Move the opencrypto CAST-128 implementation to crypto/cast128, removing the old one. Rename the functions/structures from cast_* to cast128_*. Adapt the KAME IPsec to use the new CAST-128 code, which has a simpler API and smaller footprint.
|
1.5 | 27-Nov-2001 |
itojun | branches: 1.5.16; fix cast128 with shorter key length. sync with kame
|
1.4 | 13-Nov-2001 |
lukem | add RCSIDs
|
1.3 | 21-Feb-2001 |
jdolecek | branches: 1.3.2; 1.3.4; make some more constant arrays 'const'
|
1.2 | 06-Nov-2000 |
itojun | branches: 1.2.2; sync with kame. - include string.h (instead of sys/systm.h) on userland compilation. make compilation under src/regress/sys/crypto happier. from minoura - (blowfish) KNF.
|
1.1 | 14-Jun-2000 |
thorpej | branches: 1.1.1; Initial revision
|
1.1.1.1 | 14-Jun-2000 |
thorpej | branches: 1.1.1.1.2; 1.1.1.1.4; Import the IPsec crypto code from netbsd-cryptosrc-intl.
|
1.1.1.1.4.2 | 22-Jun-2000 |
minoura | Sync w/ netbsd-1-5-base.
|
1.1.1.1.4.1 | 14-Jun-2000 |
minoura | file cast128.c was added on branch minoura-xpg4dl on 2000-06-22 17:06:05 +0000
|
1.1.1.1.2.1 | 09-Dec-2001 |
he | Pull up revision 1.5 (requested by itojun): Fix cast128 with short keys.
|
1.2.2.4 | 12-Mar-2001 |
bouyer | Sync with HEAD.
|
1.2.2.3 | 22-Nov-2000 |
bouyer | Sync with HEAD.
|
1.2.2.2 | 20-Nov-2000 |
bouyer | Update thorpej_scsipi to -current as of a month ago
|
1.2.2.1 | 06-Nov-2000 |
bouyer | file cast128.c was added on branch thorpej_scsipi on 2000-11-20 22:21:43 +0000
|
1.3.4.1 | 10-Jan-2002 |
thorpej | Sync kqueue branch with -current.
|
1.3.2.2 | 08-Jan-2002 |
nathanw | Catch up to -current.
|
1.3.2.1 | 14-Nov-2001 |
nathanw | Catch up to -current.
|
1.5.16.3 | 21-Sep-2004 |
skrll | Fix the sync with head I botched.
|
1.5.16.2 | 18-Sep-2004 |
skrll | Sync with HEAD.
|
1.5.16.1 | 03-Aug-2004 |
skrll | Sync with HEAD
|
1.7.16.1 | 21-Jun-2006 |
yamt | sync with head.
|
1.8.12.1 | 24-May-2006 |
tron | Merge 2006-05-24 NetBSD-current into the "peter-altq" branch.
|
1.8.10.1 | 11-May-2006 |
elad | sync with head
|
1.8.8.1 | 24-May-2006 |
yamt | sync with head.
|
1.8.6.1 | 01-Jun-2006 |
kardel | Sync with head.
|
1.8.4.1 | 09-Sep-2006 |
rpaulo | sync with head
|
1.9.114.1 | 18-May-2014 |
rmind | sync with head
|
1.9.108.1 | 20-Aug-2014 |
tls | Rebase to HEAD as of a few days ago.
|
1.9.98.1 | 22-May-2014 |
yamt | sync with head.
for a reference, the tree before this commit was tagged as yamt-pagecache-tag8.
this commit was splitted into small chunks to avoid a limitation of cvs. ("Protocol error: too many arguments")
|
1.7 | 11-Dec-2005 |
christos | merge ktrace-lwp.
|
1.6 | 26-Aug-2003 |
thorpej | Const poison.
|
1.5 | 26-Aug-2003 |
thorpej | Move the opencrypto CAST-128 implementation to crypto/cast128, removing the old one. Rename the functions/structures from cast_* to cast128_*. Adapt the KAME IPsec to use the new CAST-128 code, which has a simpler API and smaller footprint.
|
1.4 | 27-Nov-2001 |
itojun | branches: 1.4.16; fix cast128 with shorter key length. sync with kame
|
1.3 | 06-Nov-2000 |
itojun | branches: 1.3.2; 1.3.4; 1.3.6; sync with kame. - include string.h (instead of sys/systm.h) on userland compilation. make compilation under src/regress/sys/crypto happier. from minoura - (blowfish) KNF.
|
1.2 | 31-Aug-2000 |
itojun | avoid unnecessary #include <sys/mbuf.h>
|
1.1 | 14-Jun-2000 |
thorpej | branches: 1.1.1; Initial revision
|
1.1.1.1 | 14-Jun-2000 |
thorpej | branches: 1.1.1.1.2; 1.1.1.1.4; Import the IPsec crypto code from netbsd-cryptosrc-intl.
|
1.1.1.1.4.2 | 22-Jun-2000 |
minoura | Sync w/ netbsd-1-5-base.
|
1.1.1.1.4.1 | 14-Jun-2000 |
minoura | file cast128.h was added on branch minoura-xpg4dl on 2000-06-22 17:06:05 +0000
|
1.1.1.1.2.1 | 09-Dec-2001 |
he | Pull up revision 1.4 (requested by itojun): Fix cast128 with short keys.
|
1.3.6.1 | 10-Jan-2002 |
thorpej | Sync kqueue branch with -current.
|
1.3.4.1 | 08-Jan-2002 |
nathanw | Catch up to -current.
|
1.3.2.3 | 22-Nov-2000 |
bouyer | Sync with HEAD.
|
1.3.2.2 | 20-Nov-2000 |
bouyer | Update thorpej_scsipi to -current as of a month ago
|
1.3.2.1 | 06-Nov-2000 |
bouyer | file cast128.h was added on branch thorpej_scsipi on 2000-11-20 22:21:43 +0000
|
1.4.16.3 | 21-Sep-2004 |
skrll | Fix the sync with head I botched.
|
1.4.16.2 | 18-Sep-2004 |
skrll | Sync with HEAD.
|
1.4.16.1 | 03-Aug-2004 |
skrll | Sync with HEAD
|
1.2 | 27-May-2001 |
itojun | remove files we no longer need/maintain. sync with kame
|
1.1 | 14-Jun-2000 |
thorpej | branches: 1.1.1; Initial revision
|
1.1.1.1 | 14-Jun-2000 |
thorpej | branches: 1.1.1.1.4; 1.1.1.1.6; 1.1.1.1.8; Import the IPsec crypto code from netbsd-cryptosrc-intl.
|
1.1.1.1.8.1 | 28-Feb-2002 |
nathanw | Catch up to -current.
|
1.1.1.1.6.2 | 20-Nov-2000 |
bouyer | Update thorpej_scsipi to -current as of a month ago
|
1.1.1.1.6.1 | 14-Jun-2000 |
bouyer | file cast128_cbc.c was added on branch thorpej_scsipi on 2000-11-20 22:21:43 +0000
|
1.1.1.1.4.2 | 22-Jun-2000 |
minoura | Sync w/ netbsd-1-5-base.
|
1.1.1.1.4.1 | 14-Jun-2000 |
minoura | file cast128_cbc.c was added on branch minoura-xpg4dl on 2000-06-22 17:06:05 +0000
|
1.2 | 26-Aug-2003 |
thorpej | Move the opencrypto CAST-128 implementation to crypto/cast128, removing the old one. Rename the functions/structures from cast_* to cast128_*. Adapt the KAME IPsec to use the new CAST-128 code, which has a simpler API and smaller footprint.
|
1.1 | 14-Jun-2000 |
thorpej | branches: 1.1.1; Initial revision
|
1.1.1.1 | 14-Jun-2000 |
thorpej | branches: 1.1.1.1.4; 1.1.1.1.6; 1.1.1.1.28; Import the IPsec crypto code from netbsd-cryptosrc-intl.
|
1.1.1.1.28.1 | 03-Aug-2004 |
skrll | Sync with HEAD
|
1.1.1.1.6.2 | 20-Nov-2000 |
bouyer | Update thorpej_scsipi to -current as of a month ago
|
1.1.1.1.6.1 | 14-Jun-2000 |
bouyer | file cast128_subkey.h was added on branch thorpej_scsipi on 2000-11-20 22:21:43 +0000
|
1.1.1.1.4.2 | 22-Jun-2000 |
minoura | Sync w/ netbsd-1-5-base.
|
1.1.1.1.4.1 | 14-Jun-2000 |
minoura | file cast128_subkey.h was added on branch minoura-xpg4dl on 2000-06-22 17:06:06 +0000
|
1.2 | 11-Dec-2005 |
christos | merge ktrace-lwp.
|
1.1 | 26-Aug-2003 |
thorpej | branches: 1.1.4; Move the opencrypto CAST-128 implementation to crypto/cast128, removing the old one. Rename the functions/structures from cast_* to cast128_*. Adapt the KAME IPsec to use the new CAST-128 code, which has a simpler API and smaller footprint.
|
1.1.4.4 | 21-Sep-2004 |
skrll | Fix the sync with head I botched.
|
1.1.4.3 | 18-Sep-2004 |
skrll | Sync with HEAD.
|
1.1.4.2 | 03-Aug-2004 |
skrll | Sync with HEAD
|
1.1.4.1 | 26-Aug-2003 |
skrll | file cast128sb.h was added on branch ktrace-lwp on 2004-08-03 10:44:46 +0000
|
1.1 | 11-Oct-2002 |
thorpej | branches: 1.1.2; * Move config defns for the crypto algorithms into their own files. Define an attribute for each crypto algorithm, and use that attribute to select the files that implement the algorithm. * Give the "wlan" attribute a dependency on the "arc4" attribute. * Give the "cgd" pseudo-device the "des", "blowfish", "cast128", and "rijndael" attributes. * Use the new attribute-as-option-dependencies feature of config(8) to give the IPSEC_ESP option dependencies on the "des", "blowfish", "cast128", and "rijndael" attributes.
|
1.1.2.2 | 18-Oct-2002 |
nathanw | Catch up to -current.
|
1.1.2.1 | 11-Oct-2002 |
nathanw | file files.cast128 was added on branch nathanw_sa on 2002-10-18 02:41:21 +0000
|
1.1 | 25-Jul-2020 |
riastradh | New ChaCha API in kernel.
This will enable us to adopt MD vectorized implementations of ChaCha.
|
1.4 | 05-Nov-2022 |
jmcneill | Make aes and chacha prints debug only.
|
1.3 | 27-Jul-2020 |
riastradh | Simplify ChaCha selection and allow it to be used much earlier.
This way we can use it for cprng_fast early on. ChaCha is easy because there's no data formats that must be preserved from call to call but vary from implementation to implementation -- we could even make it a sysctl knob to dynamically select it with negligible cost.
(In contrast, different AES implementations use different expanded key formats which must be preserved from aes_setenckey to aes_enc, for example, which means a considerably greater burden on dynamic selection that's not really worth it.)
|
1.2 | 27-Jul-2020 |
riastradh | New sysctl subtree kern.crypto.
kern.crypto.aes.selected (formerly hw.aes_impl) kern.crypto.chacha.selected (formerly hw.chacha_impl)
XXX Should maybe deduplicate creation of kern.crypto.
|
1.1 | 25-Jul-2020 |
riastradh | New ChaCha API in kernel.
This will enable us to adopt MD vectorized implementations of ChaCha.
|
1.1 | 25-Jul-2020 |
riastradh | New ChaCha API in kernel.
This will enable us to adopt MD vectorized implementations of ChaCha.
|
1.1 | 25-Jul-2020 |
riastradh | New ChaCha API in kernel.
This will enable us to adopt MD vectorized implementations of ChaCha.
|
1.1 | 25-Jul-2020 |
riastradh | New ChaCha API in kernel.
This will enable us to adopt MD vectorized implementations of ChaCha.
|
1.1 | 25-Jul-2020 |
riastradh | New ChaCha API in kernel.
This will enable us to adopt MD vectorized implementations of ChaCha.
|
1.1 | 25-Jul-2020 |
riastradh | New ChaCha API in kernel.
This will enable us to adopt MD vectorized implementations of ChaCha.
|
1.8 | 07-Aug-2023 |
rin | sys/crypto: Introduce arch/{arm,x86} to share common MD headers
Dedup between aes and chacha. No binary changes.
|
1.7 | 07-Sep-2020 |
jakllsch | Fix vgetq_lane_u32 for aarch64eb with GCC
Fixes NEON AES on aarch64eb
|
1.6 | 09-Aug-2020 |
riastradh | Fix some clang neon intrinsics.
Compile-tested only, with -Wno-nonportable-vector-initializers. Need to address -- and test -- this stuff properly but this is progress.
|
1.5 | 09-Aug-2020 |
riastradh | Use vshlq_n_s32 rather than vsliq_n_s32 with zero destination.
Not sure why I reached for vsliq_n_s32 at first -- probably so I wouldn't have to deal with a new intrinsic in arm_neon.h!
|
1.4 | 08-Aug-2020 |
riastradh | Fix ARM NEON implementations of AES and ChaCha on big-endian ARM.
New macros such as VQ_N_U32(a,b,c,d) for NEON vector initializers. Needed because GCC and Clang disagree on the ordering of lanes, depending on whether it's 64-bit big-endian, 32-bit big-endian, or little-endian -- and, bizarrely, both of them disagree with the architectural numbering of lanes.
Experimented with using
static const uint8_t x8[16] = {...};
uint8x16_t x = vld1q_u8(x8);
which doesn't require knowing anything about the ordering of lanes, but this generates considerably worse code and apparently confuses GCC into not recognizing the constant value of x8.
Fix some clang mistakes while here too.
|
1.3 | 27-Jul-2020 |
riastradh | Note that VSRI seems to hurt here.
|
1.2 | 27-Jul-2020 |
riastradh | Take advantage of REV32 and TBL for 16-bit and 8-bit rotations.
However, disable use of (V)TBL on armv7/aarch32 for now, because for some reason GCC spills things to the stack despite having plenty of free registers, which hurts performance more than it helps at least on ARM Cortex-A8.
|
1.1 | 25-Jul-2020 |
riastradh | Implement ChaCha with NEON on ARM.
XXX Needs performance measurement. XXX Needs adaptation to arm32 neon which has half the registers.
|
1.3 | 07-Aug-2023 |
rin | sys/crypto: Introduce arch/{arm,x86} to share common MD headers
Dedup between aes and chacha. No binary changes.
|
1.2 | 09-Aug-2020 |
riastradh | Fix mistake in big-endian arm clang.
Swapped the two halves (only gcc does that, I think) and wrote j,i backwards, oops.
(I don't have a big-endian arm clang build handy to test; hoping this works.)
|
1.1 | 08-Aug-2020 |
riastradh | Fix ARM NEON implementations of AES and ChaCha on big-endian ARM.
New macros such as VQ_N_U32(a,b,c,d) for NEON vector initializers. Needed because GCC and Clang disagree on the ordering of lanes, depending on whether it's 64-bit big-endian, 32-bit big-endian, or little-endian -- and, bizarrely, both of them disagree with the architectural numbering of lanes.
Experimented with using
static const uint8_t x8[16] = {...};
uint8x16_t x = vld1q_u8(x8);
which doesn't require knowing anything about the ordering of lanes, but this generates considerably worse code and apparently confuses GCC into not recognizing the constant value of x8.
Fix some clang mistakes while here too.
|
1.9 | 07-Aug-2023 |
rin | sys/crypto: Introduce arch/{arm,x86} to share common MD headers
Dedup between aes and chacha. No binary changes.
|
1.8 | 08-Aug-2020 |
riastradh | Fix ARM NEON implementations of AES and ChaCha on big-endian ARM.
New macros such as VQ_N_U32(a,b,c,d) for NEON vector initializers. Needed because GCC and Clang disagree on the ordering of lanes, depending on whether it's 64-bit big-endian, 32-bit big-endian, or little-endian -- and, bizarrely, both of them disagree with the architectural numbering of lanes.
Experimented with using
static const uint8_t x8[16] = {...};
uint8x16_t x = vld1q_u8(x8);
which doesn't require knowing anything about the ordering of lanes, but this generates considerably worse code and apparently confuses GCC into not recognizing the constant value of x8.
Fix some clang mistakes while here too.
|
1.7 | 28-Jul-2020 |
riastradh | Implement 4-way vectorization of ChaCha for armv7 NEON.
cgd performance is not as good as I was hoping (~4% improvement over chacha_ref.c) but it should improve substantially more if we let the cgd worker thread keep fpu state so we don't have to pay the cost of isb and zero-the-fpu on every 512-byte cgd block.
|
1.6 | 28-Jul-2020 |
riastradh | Fix big-endian build with appropriate casts around vrev32q_u8.
|
1.5 | 27-Jul-2020 |
riastradh | Note that VSRI seems to hurt here.
|
1.4 | 27-Jul-2020 |
riastradh | Take advantage of REV32 and TBL for 16-bit and 8-bit rotations.
However, disable use of (V)TBL on armv7/aarch32 for now, because for some reason GCC spills things to the stack despite having plenty of free registers, which hurts performance more than it helps at least on ARM Cortex-A8.
|
1.3 | 27-Jul-2020 |
riastradh | Enable ChaCha NEON code on armv7 too.
The 4-blocks-at-a-time assembly helper is disabled for now; adapting it to armv7 is going to be a little annoying with only 16 128-bit vector registers.
(Should also do a fifth block in the integer registers for 320 bytes at a time.)
|
1.2 | 27-Jul-2020 |
riastradh | Reduce some duplication.
Shouldn't substantively hurt performance -- the comparison that has been moved into the loop was essentially the former loop condition -- and may improve performance by reducing code size since there's only one inline call to chacha_permute instead of two.
|
1.1 | 25-Jul-2020 |
riastradh | Implement ChaCha with NEON on ARM.
XXX Needs performance measurement. XXX Needs adaptation to arm32 neon which has half the registers.
|
1.3 | 28-Jul-2020 |
riastradh | Implement 4-way vectorization of ChaCha for armv7 NEON.
cgd performance is not as good as I was hoping (~4% improvement over chacha_ref.c) but it should improve substantially more if we let the cgd worker thread keep fpu state so we don't have to pay the cost of isb and zero-the-fpu on every 512-byte cgd block.
|
1.2 | 27-Jul-2020 |
riastradh | Enable ChaCha NEON code on armv7 too.
The 4-blocks-at-a-time assembly helper is disabled for now; adapting it to armv7 is going to be a little annoying with only 16 128-bit vector registers.
(Should also do a fifth block in the integer registers for 320 bytes at a time.)
|
1.1 | 25-Jul-2020 |
riastradh | Implement ChaCha with NEON on ARM.
XXX Needs performance measurement. XXX Needs adaptation to arm32 neon which has half the registers.
|
1.4 | 23-Aug-2020 |
riastradh | Adjust sp, not fp, to allocate a 32-byte temporary.
Costs another couple MOV instructions, but we can't skimp on this -- there's no red zone below sp for interrupts on arm, so we can't touch anything there. So just use fp to save sp and then adjust sp itself, rather than using fp as a temporary register to point just below sp.
Should fix PR port-arm/55598 -- previously the ChaCha self-test failed 33/10000 trials triggered by sysctl during running system; with the patch it has failed 0/10000 trials.
(Presumably it happened more often at boot time, leading to 5/26 failures in the test bed, because we just enabled interrupts and some devices are starting to deliver interrupts.)
|
1.3 | 08-Aug-2020 |
riastradh | Fix ARM NEON implementations of AES and ChaCha on big-endian ARM.
New macros such as VQ_N_U32(a,b,c,d) for NEON vector initializers. Needed because GCC and Clang disagree on the ordering of lanes, depending on whether it's 64-bit big-endian, 32-bit big-endian, or little-endian -- and, bizarrely, both of them disagree with the architectural numbering of lanes.
Experimented with using
static const uint8_t x8[16] = {...};
uint8x16_t x = vld1q_u8(x8);
which doesn't require knowing anything about the ordering of lanes, but this generates considerably worse code and apparently confuses GCC into not recognizing the constant value of x8.
Fix some clang mistakes while here too.
|
1.2 | 29-Jul-2020 |
riastradh | Issue three more swaps to save eight stores.
Reduces code size and yields a small (~2%) cgd throughput boost.
Remove duplicate comment while here.
|
1.1 | 28-Jul-2020 |
riastradh | Implement 4-way vectorization of ChaCha for armv7 NEON.
cgd performance is not as good as I was hoping (~4% improvement over chacha_ref.c) but it should improve substantially more if we let the cgd worker thread keep fpu state so we don't have to pay the cost of isb and zero-the-fpu on every 512-byte cgd block.
|
1.7 | 07-Sep-2020 |
jakllsch | Use a working macro to detect big endian aarch64.
Fixes aarch64eb NEON ChaCha.
|
1.6 | 08-Aug-2020 |
riastradh | Fix ARM NEON implementations of AES and ChaCha on big-endian ARM.
New macros such as VQ_N_U32(a,b,c,d) for NEON vector initializers. Needed because GCC and Clang disagree on the ordering of lanes, depending on whether it's 64-bit big-endian, 32-bit big-endian, or little-endian -- and, bizarrely, both of them disagree with the architectural numbering of lanes.
Experimented with using
static const uint8_t x8[16] = {...};
uint8x16_t x = vld1q_u8(x8);
which doesn't require knowing anything about the ordering of lanes, but this generates considerably worse code and apparently confuses GCC into not recognizing the constant value of x8.
Fix some clang mistakes while here too.
|
1.5 | 28-Jul-2020 |
riastradh | Fix typo in comment.
|
1.4 | 27-Jul-2020 |
riastradh | Add RCSIDs to the AES and ChaCha .S sources.
|
1.3 | 27-Jul-2020 |
riastradh | Align critical-path loops in AES and ChaCha.
|
1.2 | 27-Jul-2020 |
riastradh | Use <aarch64/asm.h> rather than copying things from it here.
Vestige from userland build on netbsd-9 during development.
|
1.1 | 25-Jul-2020 |
riastradh | Implement ChaCha with NEON on ARM.
XXX Needs performance measurement. XXX Needs adaptation to arm32 neon which has half the registers.
|
1.2 | 10-Oct-2020 |
jmcneill | Fix detection of NEON features. ID_AA64PFR0_EL1_ADV_SIMD_NONE means SIMD is not available, and any other value means it is.
|
1.1 | 25-Jul-2020 |
riastradh | Implement ChaCha with NEON on ARM.
XXX Needs performance measurement. XXX Needs adaptation to arm32 neon which has half the registers.
|
1.5 | 08-Sep-2020 |
jakllsch | Acknowledge clang warning for NEON cipher code on aarch64eb
We've already made the nonportable vector initializations portable; the code works on aarch64eb.
|
1.4 | 08-Sep-2020 |
jakllsch | use correct condition
|
1.3 | 28-Jul-2020 |
riastradh | Implement 4-way vectorization of ChaCha for armv7 NEON.
cgd performance is not as good as I was hoping (~4% improvement over chacha_ref.c) but it should improve substantially more if we let the cgd worker thread keep fpu state so we don't have to pay the cost of isb and zero-the-fpu on every 512-byte cgd block.
|
1.2 | 27-Jul-2020 |
riastradh | Enable ChaCha NEON code on armv7 too.
The 4-blocks-at-a-time assembly helper is disabled for now; adapting it to armv7 is going to be a little annoying with only 16 128-bit vector registers.
(Should also do a fifth block in the integer registers for 320 bytes at a time.)
|
1.1 | 25-Jul-2020 |
riastradh | Implement ChaCha with NEON on ARM.
XXX Needs performance measurement. XXX Needs adaptation to arm32 neon which has half the registers.
|
1.3 | 07-Aug-2023 |
rin | sys/crypto: Introduce arch/{arm,x86} to share common MD headers
Dedup between aes and chacha. No binary changes.
|
1.2 | 27-Jul-2020 |
riastradh | Reduce some duplication.
Shouldn't substantively hurt performance -- the comparison that has been moved into the loop was essentially the former loop condition -- and may improve performance by reducing code size since there's only one inline call to chacha_permute instead of two.
|
1.1 | 25-Jul-2020 |
riastradh | Implement ChaCha with SSE2 on x86 machines.
Slightly disappointed that it only doubles, rather than quadruples, throughput on my Ivy Bridge laptop. Worth investigating.
|
1.1 | 25-Jul-2020 |
riastradh | Implement ChaCha with SSE2 on x86 machines.
Slightly disappointed that it only doubles, rather than quadruples, throughput on my Ivy Bridge laptop. Worth investigating.
|
1.1 | 25-Jul-2020 |
riastradh | Implement ChaCha with SSE2 on x86 machines.
Slightly disappointed that it only doubles, rather than quadruples, throughput on my Ivy Bridge laptop. Worth investigating.
|
1.1 | 25-Jul-2020 |
riastradh | Implement ChaCha with SSE2 on x86 machines.
Slightly disappointed that it only doubles, rather than quadruples, throughput on my Ivy Bridge laptop. Worth investigating.
|
1.2 | 07-Aug-2023 |
rin | sys/crypto: Introduce arch/{arm,x86} to share common MD headers
Dedup between aes and chacha. No binary changes.
|
1.1 | 25-Jul-2020 |
riastradh | Implement ChaCha with SSE2 on x86 machines.
Slightly disappointed that it only doubles, rather than quadruples, throughput on my Ivy Bridge laptop. Worth investigating.
|
1.20 | 15-Oct-2024 |
riastradh | Revert cprng_fast(9) to seed and reseed asynchronously in softint.
This reverts sys/crypto/cprng_fast/cprng_fast.c revisions 1.17-1.19.
I thought we had eliminated all paths into cprng_fast(9) from hard interrupt context, which would allow us to call into cprng_strong(9) and entropy(9) to synchronously reseed whenever needed -- this would improve security over netbsd-9 for the first query to cprng_intr(9) on each CPU.
Unfortunately, I missed the calls under spin locks (which are effectively also hard interrupt context, in that they hold up interrupts on this CPU or interrupt handlers trying to take the lock on other CPUs). And one such spin lock is struct ifnet::ifq_lock at IPL_NET, which is held by if_transmit when it calls IFQ_ENQUEUE which calls into altq(4) which sometimes does, e.g., red_addq which calls cprng_fast32.
Until we migrate ifq_lock to IPL_SOFTNET (which is potentially feasible, because most of the network stack runs in softint now, but it requires a lot of auditing and maybe changes to lots of drivers), we'll have to make sure cprng_fast(9) doesn't try to take an adaptive lock.
And the simplest way to ensure that is to just revert back to the netbsd-9 semantics of asynchronously reseeding in softint, at the cost of a potential security weakness. I don't expect this regression to be permanent -- we just can't restore the change as is until we deal with ifq_lock.
1.19 cprng_fast(9): Drop and retake percpu reference across cprng_strong. 1.18 cprng_fast(9): Assert not in pserialize read section. 1.17 cprng(9): cprng_fast is no longer used from interrupt context.
PR kern/58575: altq(4) takes adaptive lock while holding spin lock
|
1.19 | 05-Aug-2023 |
riastradh | branches: 1.19.6; cprng_fast(9): Drop and retake percpu reference across cprng_strong.
cprng_strong may sleep on an adaptive lock (via entropy_extract), which invalidates percpu(9) references.
Discovered by stumbling upon this panic in a test run:
panic: kernel diagnostic assertion "(cprng == percpu_getref(cprng_fast_percpu)) && (percpu_putref(cprng_fast_percpu), true)" failed: file "/home/riastradh/netbsd/current/src/sys/rump/librump/rumpkern/../../../crypto/cprng_fast/cprng_fast.c", line 117
XXX pullup-10
|
1.18 | 01-Sep-2022 |
riastradh | branches: 1.18.4; cprng_fast(9): Assert not in pserialize read section.
This may sleep to take the global entropy lock in case it needs to be reseeded. If that happens we can't be in a pserialize read section.
|
1.17 | 01-Jun-2022 |
riastradh | cprng(9): cprng_fast is no longer used from interrupt context.
Rip out logic to defer reseeding to softint.
|
1.16 | 28-Jul-2020 |
riastradh | Rewrite cprng_fast in terms of new ChaCha API.
|
1.15 | 30-Apr-2020 |
riastradh | Count cprng_fast reseed events.
|
1.14 | 30-Apr-2020 |
riastradh | Adapt cprng_fast to use entropy_epoch(), not rnd_initial_entropy.
This way it has an opportunity to be reseeded after boot.
|
1.13 | 13-Apr-2015 |
riastradh | More rnd.h user cleanup.
|
1.12 | 13-Apr-2015 |
riastradh | cprng_strong(kern_cprng, ...) never blocks, pass 0 for flags.
FASYNC was wrong anyway! It's FNONBLOCK.
|
1.11 | 11-Aug-2014 |
justin | branches: 1.11.2; 1.11.4; Fix inconsistent use of inline in prototype and definition
|
1.10 | 11-Aug-2014 |
riastradh | Tweak cprng_fast_buf to use 32-bit unaligned writes if possible.
|
1.9 | 11-Aug-2014 |
riastradh | Move initial entropy bookkeeping out of the fast path.
|
1.8 | 11-Aug-2014 |
riastradh | Use percpu_foreach instead of manual iteration.
|
1.7 | 11-Aug-2014 |
riastradh | Access to struct cprng_fast must be consistently at IPL_VM.
|
1.6 | 11-Aug-2014 |
riastradh | branches: 1.6.2; No need for cprng_fast_seed to be inline.
|
1.5 | 11-Aug-2014 |
riastradh | Include <sys/rnd.h>, don't copypasta declare rnd_initial_entropy.
|
1.4 | 11-Aug-2014 |
riastradh | Sort #includes.
|
1.3 | 10-Aug-2014 |
justin | define function consistently as inline
|
1.2 | 10-Aug-2014 |
tls | Merge tls-earlyentropy branch into HEAD.
|
1.1 | 09-Aug-2014 |
tls | branches: 1.1.2; file cprng_fast.c was initially added on branch tls-earlyentropy.
|
1.1.2.1 | 09-Aug-2014 |
tls | Replace "ccrand" ChaCha implementation of cprng_fast with Taylor's smaller and somewhat simpler one. Fix rump builds so we can build a distribution.
|
1.6.2.1 | 15-Aug-2014 |
martin | Pull up following revision(s) (requested by riastradh in ticket #16): sys/crypto/cprng_fast/cprng_fast.c: revision 1.7 sys/crypto/cprng_fast/cprng_fast.c: revision 1.8 sys/crypto/cprng_fast/cprng_fast.c: revision 1.9 sys/crypto/cprng_fast/cprng_fast.c: revision 1.10 Access to struct cprng_fast must be consistently at IPL_VM. Use percpu_foreach instead of manual iteration. Move initial entropy bookkeeping out of the fast path. Tweak cprng_fast_buf to use 32-bit unaligned writes if possible.
|
1.11.4.1 | 06-Jun-2015 |
skrll | Sync with HEAD
|
1.11.2.3 | 03-Dec-2017 |
jdolecek | update from HEAD
|
1.11.2.2 | 20-Aug-2014 |
tls | Rebase to HEAD as of a few days ago.
|
1.11.2.1 | 11-Aug-2014 |
tls | file cprng_fast.c was added on branch tls-maxphys on 2014-08-20 00:03:34 +0000
|
1.18.4.2 | 26-Oct-2024 |
martin | Pull up following revision(s) (requested by riastradh in ticket #990):
sys/crypto/cprng_fast/cprng_fast.c: revision 1.20
Revert cprng_fast(9) to seed and reseed asynchronously in softint.
This reverts sys/crypto/cprng_fast/cprng_fast.c revisions 1.17-1.19.
I thought we had eliminated all paths into cprng_fast(9) from hard interrupt context, which would allow us to call into cprng_strong(9) and entropy(9) to synchronously reseed whenever needed -- this would improve security over netbsd-9 for the first query to cprng_intr(9) on each CPU.
Unfortunately, I missed the calls under spin locks (which are effectively also hard interrupt context, in that they hold up interrupts on this CPU or interrupt handlers trying to take the lock on other CPUs). And one such spin lock is struct ifnet::ifq_lock at IPL_NET, which is held by if_transmit when it calls IFQ_ENQUEUE which calls into altq(4) which sometimes does, e.g., red_addq which calls cprng_fast32.
Until we migrate ifq_lock to IPL_SOFTNET (which is potentially feasible, because most of the network stack runs in softint now, but it requires a lot of auditing and maybe changes to lots of drivers), we'll have to make sure cprng_fast(9) doesn't try to take an adaptive lock.
And the simplest way to ensure that is to just revert back to the netbsd-9 semantics of asynchronously reseeding in softint, at the cost of a potential security weakness. I don't expect this regression to be permanent -- we just can't restore the change as is until we deal with ifq_lock.
1.19 cprng_fast(9): Drop and retake percpu reference across cprng_strong. 1.18 cprng_fast(9): Assert not in pserialize read section. 1.17 cprng(9): cprng_fast is no longer used from interrupt context.
PR kern/58575: altq(4) takes adaptive lock while holding spin lock
|
1.18.4.1 | 11-Aug-2023 |
martin | Pull up following revision(s) (requested by riastradh in ticket #319):
sys/dev/pci/ubsec.c: revision 1.64 sys/dev/pci/hifn7751.c: revision 1.82 lib/libc/gen/getentropy.3: revision 1.5 lib/libc/gen/getentropy.3: revision 1.6 share/man/man4/rnd.4: revision 1.41 lib/libc/sys/getrandom.2: revision 1.2 lib/libc/sys/getrandom.2: revision 1.3 share/man/man5/rc.conf.5: revision 1.193 share/man/man7/entropy.7: revision 1.5 share/man/man7/entropy.7: revision 1.6 share/man/man7/entropy.7: revision 1.7 share/man/man7/entropy.7: revision 1.8 etc/security: revision 1.130 share/man/man7/entropy.7: revision 1.9 etc/security: revision 1.131 sys/crypto/cprng_fast/cprng_fast.c: revision 1.19 sys/sys/rndio.h: revision 1.3 tests/lib/libc/sys/t_getrandom.c: revision 1.5 etc/defaults/rc.conf: revision 1.164 etc/defaults/rc.conf: revision 1.165 sys/sys/rndsource.h: revision 1.10 sys/kern/kern_entropy.c: revision 1.62 sys/kern/kern_entropy.c: revision 1.63 sys/kern/kern_entropy.c: revision 1.64 sys/kern/subr_cprng.c: revision 1.44 sys/kern/kern_entropy.c: revision 1.65 sys/kern/kern_clock.c: revision 1.149 sys/dev/pci/viornd.c: revision 1.22 share/man/man9/rnd.9: revision 1.32 sys/kern/subr_prf.c: revision 1.202 sys/sys/rndsource.h: revision 1.8 sys/sys/rndsource.h: revision 1.9 share/man/man7/entropy.7: revision 1.10
1. Reinstate netbsd<=9 entropy estimator to unblock /dev/random, in parallel with assessment of only confident entropy sources (seed, HWRNG) for security warnings like sshd keys in motd and daily insecurity report.
2. Make multiuser boot wait for first /dev/random output soon after loading a seed and configuring rndctl, so that getentropy(3) meets its contract starting early at boot without introducing blocking paths that could cause hangs in init(8) or single-user mode. Operators can choose to disable this wait in rc.conf.
3. Fix some bugs left over from reducing the global entropy lock from a spin lock at IPL_VM to an adaptive lock at IPL_SOFTSERIAL.
4. Update man pages.
|
1.19.6.1 | 02-Aug-2025 |
perseant | Sync with HEAD
|
1.2 | 10-Aug-2014 |
tls | branches: 1.2.4; Merge tls-earlyentropy branch into HEAD.
|
1.1 | 09-Aug-2014 |
tls | branches: 1.1.2; file cprng_fast.h was initially added on branch tls-earlyentropy.
|
1.1.2.1 | 09-Aug-2014 |
tls | Replace "ccrand" ChaCha implementation of cprng_fast with Taylor's smaller and somewhat simpler one. Fix rump builds so we can build a distribution.
|
1.2.4.2 | 20-Aug-2014 |
tls | Rebase to HEAD as of a few days ago.
|
1.2.4.1 | 10-Aug-2014 |
tls | file cprng_fast.h was added on branch tls-maxphys on 2014-08-20 00:03:34 +0000
|
1.3 | 28-Jul-2020 |
riastradh | Rewrite cprng_fast in terms of new ChaCha API.
|
1.2 | 10-Aug-2014 |
tls | branches: 1.2.4; Merge tls-earlyentropy branch into HEAD.
|
1.1 | 09-Aug-2014 |
tls | branches: 1.1.2; file files.cprng_fast was initially added on branch tls-earlyentropy.
|
1.1.2.1 | 09-Aug-2014 |
tls | Replace "ccrand" ChaCha implementation of cprng_fast with Taylor's smaller and somewhat simpler one. Fix rump builds so we can build a distribution.
|
1.2.4.2 | 20-Aug-2014 |
tls | Rebase to HEAD as of a few days ago.
|
1.2.4.1 | 10-Aug-2014 |
tls | file files.cprng_fast was added on branch tls-maxphys on 2014-08-20 00:03:34 +0000
|
1.8 | 14-Mar-2009 |
dsl | Remove all the __P() from sys (excluding sys/dist) Diff checked with grep and MK1 eyeball. i386 and amd64 GENERIC and sys still build.
|
1.7 | 11-Dec-2005 |
christos | branches: 1.7.74; 1.7.84; 1.7.90; merge ktrace-lwp.
|
1.6 | 26-Feb-2005 |
perry | nuke trailing whitespace
|
1.5 | 09-Sep-2001 |
tls | branches: 1.5.18; 1.5.26; 1.5.28; Add asm versions of blowfish and des transforms for i386.
This also involved updating the in-kernel DES functions to correspond to the versions in our in-tree OpenSSL, because the des_SPtrans table has changed; the asm code will not work with the old permutation table!
C and i386 asm code for the DES, 3DES, and Blowfish CBC modes is also included; it is not currently built as the ESP processing in esp_core.c splits the CBC operation and the cipher transform apart. Hopefully that will be fixed as there is a substantial performance improvement to be had from doing so. It will remain necessary to use the C version of the Blowfish CBC function on some i386 machines, however, as the asm version uses bswapl, which ony 486 and later processors have. The DES CBC code doesn't have this problem.
Finally, change esp_core.c to use the ecb3_encrypt function instead of calling ecb_encrypt three times; this improves performance a bit, in particular in the asm case.
|
1.4 | 06-Nov-2000 |
itojun | branches: 1.4.2; 1.4.4; 1.4.6; 1.4.8; sync with kame. - include string.h (instead of sys/systm.h) on userland compilation. make compilation under src/regress/sys/crypto happier. from minoura - (blowfish) KNF.
|
1.3 | 31-Aug-2000 |
itojun | remove a comment, which is now bogus due to the previous change. sync with kame.
|
1.2 | 31-Aug-2000 |
itojun | repair DES on LP64. past code did not interoperate with non-LP64, due to incorrect computed results. remove unnecessary #ifdef/#define. sync with kame.
|
1.1 | 14-Jun-2000 |
thorpej | branches: 1.1.1; Initial revision
|
1.1.1.1 | 14-Jun-2000 |
thorpej | branches: 1.1.1.1.2; 1.1.1.1.4; Import the IPsec crypto code from netbsd-cryptosrc-intl.
|
1.1.1.1.4.2 | 22-Jun-2000 |
minoura | Sync w/ netbsd-1-5-base.
|
1.1.1.1.4.1 | 14-Jun-2000 |
minoura | file des.h was added on branch minoura-xpg4dl on 2000-06-22 17:06:06 +0000
|
1.1.1.1.2.1 | 31-Aug-2000 |
itojun | pullup (approved by releng-1-5)
> repair DES on LP64. past code did not interoperate with non-LP64, due to > incorrect computed results. > remove unnecessary #ifdef/#define. sync with kame.
> cvs rdiff -r1.1 -r1.2 syssrc/sys/crypto/des/des.h \ > syssrc/sys/crypto/des/des_3cbc.c syssrc/sys/crypto/des/des_cbc.c \ > syssrc/sys/crypto/des/des_ecb.c syssrc/sys/crypto/des/des_locl.h \ > syssrc/sys/crypto/des/des_setkey.c > cvs rdiff -r1.6 -r1.7 syssrc/sys/netinet6/esp_core.c (equivalent change)
|
1.4.8.1 | 01-Oct-2001 |
fvdl | Catch up with -current.
|
1.4.6.1 | 13-Sep-2001 |
thorpej | Update the kqueue branch to HEAD.
|
1.4.4.1 | 21-Sep-2001 |
nathanw | Catch up to -current.
|
1.4.2.3 | 22-Nov-2000 |
bouyer | Sync with HEAD.
|
1.4.2.2 | 20-Nov-2000 |
bouyer | Update thorpej_scsipi to -current as of a month ago
|
1.4.2.1 | 06-Nov-2000 |
bouyer | file des.h was added on branch thorpej_scsipi on 2000-11-20 22:21:43 +0000
|
1.5.28.1 | 19-Mar-2005 |
yamt | sync with head. xen and whitespace. xen part is not finished.
|
1.5.26.1 | 29-Apr-2005 |
kent | sync with -current
|
1.5.18.1 | 04-Mar-2005 |
skrll | Sync with HEAD.
Hi Perry!
|
1.7.90.1 | 13-May-2009 |
jym | Sync with HEAD.
Commit is split, to avoid a "too many arguments" protocol error.
|
1.7.84.1 | 28-Apr-2009 |
skrll | Sync with HEAD.
|
1.7.74.1 | 04-May-2009 |
yamt | sync with head.
|
1.3 | 27-May-2001 |
itojun | remove files we no longer need/maintain. sync with kame
|
1.2 | 31-Aug-2000 |
itojun | branches: 1.2.2; 1.2.4; repair DES on LP64. past code did not interoperate with non-LP64, due to incorrect computed results. remove unnecessary #ifdef/#define. sync with kame.
|
1.1 | 14-Jun-2000 |
thorpej | branches: 1.1.1; Initial revision
|
1.1.1.1 | 14-Jun-2000 |
thorpej | branches: 1.1.1.1.2; 1.1.1.1.4; Import the IPsec crypto code from netbsd-cryptosrc-intl.
|
1.1.1.1.4.2 | 22-Jun-2000 |
minoura | Sync w/ netbsd-1-5-base.
|
1.1.1.1.4.1 | 14-Jun-2000 |
minoura | file des_3cbc.c was added on branch minoura-xpg4dl on 2000-06-22 17:06:07 +0000
|
1.1.1.1.2.1 | 31-Aug-2000 |
itojun | pullup (approved by releng-1-5)
> repair DES on LP64. past code did not interoperate with non-LP64, due to > incorrect computed results. > remove unnecessary #ifdef/#define. sync with kame.
> cvs rdiff -r1.1 -r1.2 syssrc/sys/crypto/des/des.h \ > syssrc/sys/crypto/des/des_3cbc.c syssrc/sys/crypto/des/des_cbc.c \ > syssrc/sys/crypto/des/des_ecb.c syssrc/sys/crypto/des/des_locl.h \ > syssrc/sys/crypto/des/des_setkey.c > cvs rdiff -r1.6 -r1.7 syssrc/sys/netinet6/esp_core.c (equivalent change)
|
1.2.4.1 | 28-Feb-2002 |
nathanw | Catch up to -current.
|
1.2.2.2 | 20-Nov-2000 |
bouyer | Update thorpej_scsipi to -current as of a month ago
|
1.2.2.1 | 31-Aug-2000 |
bouyer | file des_3cbc.c was added on branch thorpej_scsipi on 2000-11-20 22:21:43 +0000
|
1.8 | 11-Dec-2005 |
christos | merge ktrace-lwp.
|
1.7 | 26-Feb-2005 |
perry | nuke trailing whitespace
|
1.6 | 08-Sep-2002 |
elric | branches: 1.6.6; 1.6.14; 1.6.16; Added an include of sys/types.h to get u_int32_t and so on.
|
1.5 | 13-Nov-2001 |
lukem | branches: 1.5.10; add RCSIDs
|
1.4 | 09-Sep-2001 |
tls | Add asm versions of blowfish and des transforms for i386.
This also involved updating the in-kernel DES functions to correspond to the versions in our in-tree OpenSSL, because the des_SPtrans table has changed; the asm code will not work with the old permutation table!
C and i386 asm code for the DES, 3DES, and Blowfish CBC modes is also included; it is not currently built as the ESP processing in esp_core.c splits the CBC operation and the cipher transform apart. Hopefully that will be fixed as there is a substantial performance improvement to be had from doing so. It will remain necessary to use the C version of the Blowfish CBC function on some i386 machines, however, as the asm version uses bswapl, which ony 486 and later processors have. The DES CBC code doesn't have this problem.
Finally, change esp_core.c to use the ecb3_encrypt function instead of calling ecb_encrypt three times; this improves performance a bit, in particular in the asm case.
|
1.3 | 27-May-2001 |
itojun | branches: 1.3.2; 1.3.4; remove files we no longer need/maintain. sync with kame
|
1.2 | 31-Aug-2000 |
itojun | branches: 1.2.2; 1.2.4; repair DES on LP64. past code did not interoperate with non-LP64, due to incorrect computed results. remove unnecessary #ifdef/#define. sync with kame.
|
1.1 | 14-Jun-2000 |
thorpej | branches: 1.1.1; Initial revision
|
1.1.1.1 | 14-Jun-2000 |
thorpej | branches: 1.1.1.1.2; 1.1.1.1.4; Import the IPsec crypto code from netbsd-cryptosrc-intl.
|
1.1.1.1.4.2 | 22-Jun-2000 |
minoura | Sync w/ netbsd-1-5-base.
|
1.1.1.1.4.1 | 14-Jun-2000 |
minoura | file des_cbc.c was added on branch minoura-xpg4dl on 2000-06-22 17:06:07 +0000
|
1.1.1.1.2.1 | 31-Aug-2000 |
itojun | pullup (approved by releng-1-5)
> repair DES on LP64. past code did not interoperate with non-LP64, due to > incorrect computed results. > remove unnecessary #ifdef/#define. sync with kame.
> cvs rdiff -r1.1 -r1.2 syssrc/sys/crypto/des/des.h \ > syssrc/sys/crypto/des/des_3cbc.c syssrc/sys/crypto/des/des_cbc.c \ > syssrc/sys/crypto/des/des_ecb.c syssrc/sys/crypto/des/des_locl.h \ > syssrc/sys/crypto/des/des_setkey.c > cvs rdiff -r1.6 -r1.7 syssrc/sys/netinet6/esp_core.c (equivalent change)
|
1.2.4.3 | 17-Sep-2002 |
nathanw | Catch up to -current.
|
1.2.4.2 | 14-Nov-2001 |
nathanw | Catch up to -current.
|
1.2.4.1 | 21-Sep-2001 |
nathanw | Catch up to -current.
|
1.2.2.2 | 20-Nov-2000 |
bouyer | Update thorpej_scsipi to -current as of a month ago
|
1.2.2.1 | 31-Aug-2000 |
bouyer | file des_cbc.c was added on branch thorpej_scsipi on 2000-11-20 22:21:44 +0000
|
1.3.4.1 | 01-Oct-2001 |
fvdl | Catch up with -current.
|
1.3.2.3 | 10-Oct-2002 |
jdolecek | sync kqueue with -current; this includes merge of gehenna-devsw branch, merge of i386 MP branch, and part of autoconf rototil work
|
1.3.2.2 | 10-Jan-2002 |
thorpej | Sync kqueue branch with -current.
|
1.3.2.1 | 13-Sep-2001 |
thorpej | Update the kqueue branch to HEAD.
|
1.5.10.1 | 12-Sep-2003 |
tron | Pull up revision 1.6 (requested by tv in ticket #1455): Added an include of sys/types.h to get u_int32_t and so on.
|
1.6.16.1 | 19-Mar-2005 |
yamt | sync with head. xen and whitespace. xen part is not finished.
|
1.6.14.1 | 29-Apr-2005 |
kent | sync with -current
|
1.6.6.1 | 04-Mar-2005 |
skrll | Sync with HEAD.
Hi Perry!
|
1.10 | 25-Mar-2014 |
christos | fix sprintf.
|
1.9 | 11-Dec-2005 |
christos | branches: 1.9.110; 1.9.120; 1.9.126; merge ktrace-lwp.
|
1.8 | 26-Feb-2005 |
perry | nuke trailing whitespace
|
1.7 | 02-Nov-2002 |
perry | branches: 1.7.6; 1.7.14; 1.7.16; /*CONTCOND*/ a sizeof comparison
|
1.6 | 13-Nov-2001 |
lukem | add RCSIDs
|
1.5 | 09-Sep-2001 |
taca | Add including <stdio.h> for compiling in user land. This should fix compile error (really warning) in src/regress/sys/crypto/des.
|
1.4 | 09-Sep-2001 |
tls | Add asm versions of blowfish and des transforms for i386.
This also involved updating the in-kernel DES functions to correspond to the versions in our in-tree OpenSSL, because the des_SPtrans table has changed; the asm code will not work with the old permutation table!
C and i386 asm code for the DES, 3DES, and Blowfish CBC modes is also included; it is not currently built as the ESP processing in esp_core.c splits the CBC operation and the cipher transform apart. Hopefully that will be fixed as there is a substantial performance improvement to be had from doing so. It will remain necessary to use the C version of the Blowfish CBC function on some i386 machines, however, as the asm version uses bswapl, which ony 486 and later processors have. The DES CBC code doesn't have this problem.
Finally, change esp_core.c to use the ecb3_encrypt function instead of calling ecb_encrypt three times; this improves performance a bit, in particular in the asm case.
|
1.3 | 06-Nov-2000 |
itojun | branches: 1.3.2; 1.3.4; 1.3.6; 1.3.8; sync with kame. - include string.h (instead of sys/systm.h) on userland compilation. make compilation under src/regress/sys/crypto happier. from minoura - (blowfish) KNF.
|
1.2 | 31-Aug-2000 |
itojun | repair DES on LP64. past code did not interoperate with non-LP64, due to incorrect computed results. remove unnecessary #ifdef/#define. sync with kame.
|
1.1 | 14-Jun-2000 |
thorpej | branches: 1.1.1; Initial revision
|
1.1.1.1 | 14-Jun-2000 |
thorpej | branches: 1.1.1.1.2; 1.1.1.1.4; Import the IPsec crypto code from netbsd-cryptosrc-intl.
|
1.1.1.1.4.2 | 22-Jun-2000 |
minoura | Sync w/ netbsd-1-5-base.
|
1.1.1.1.4.1 | 14-Jun-2000 |
minoura | file des_ecb.c was added on branch minoura-xpg4dl on 2000-06-22 17:06:08 +0000
|
1.1.1.1.2.1 | 31-Aug-2000 |
itojun | pullup (approved by releng-1-5)
> repair DES on LP64. past code did not interoperate with non-LP64, due to > incorrect computed results. > remove unnecessary #ifdef/#define. sync with kame.
> cvs rdiff -r1.1 -r1.2 syssrc/sys/crypto/des/des.h \ > syssrc/sys/crypto/des/des_3cbc.c syssrc/sys/crypto/des/des_cbc.c \ > syssrc/sys/crypto/des/des_ecb.c syssrc/sys/crypto/des/des_locl.h \ > syssrc/sys/crypto/des/des_setkey.c > cvs rdiff -r1.6 -r1.7 syssrc/sys/netinet6/esp_core.c (equivalent change)
|
1.3.8.1 | 01-Oct-2001 |
fvdl | Catch up with -current.
|
1.3.6.2 | 10-Jan-2002 |
thorpej | Sync kqueue branch with -current.
|
1.3.6.1 | 13-Sep-2001 |
thorpej | Update the kqueue branch to HEAD.
|
1.3.4.3 | 11-Nov-2002 |
nathanw | Catch up to -current
|
1.3.4.2 | 14-Nov-2001 |
nathanw | Catch up to -current.
|
1.3.4.1 | 21-Sep-2001 |
nathanw | Catch up to -current.
|
1.3.2.3 | 22-Nov-2000 |
bouyer | Sync with HEAD.
|
1.3.2.2 | 20-Nov-2000 |
bouyer | Update thorpej_scsipi to -current as of a month ago
|
1.3.2.1 | 06-Nov-2000 |
bouyer | file des_ecb.c was added on branch thorpej_scsipi on 2000-11-20 22:21:44 +0000
|
1.7.16.1 | 19-Mar-2005 |
yamt | sync with head. xen and whitespace. xen part is not finished.
|
1.7.14.1 | 29-Apr-2005 |
kent | sync with -current
|
1.7.6.1 | 04-Mar-2005 |
skrll | Sync with HEAD.
Hi Perry!
|
1.9.126.1 | 18-May-2014 |
rmind | sync with head
|
1.9.120.1 | 20-Aug-2014 |
tls | Rebase to HEAD as of a few days ago.
|
1.9.110.1 | 22-May-2014 |
yamt | sync with head.
for a reference, the tree before this commit was tagged as yamt-pagecache-tag8.
this commit was splitted into small chunks to avoid a limitation of cvs. ("Protocol error: too many arguments")
|
1.4 | 11-Dec-2005 |
christos | merge ktrace-lwp.
|
1.3 | 26-Feb-2005 |
perry | nuke trailing whitespace
|
1.2 | 13-Nov-2001 |
lukem | branches: 1.2.16; 1.2.24; 1.2.26; add RCSIDs
|
1.1 | 09-Sep-2001 |
tls | branches: 1.1.2; 1.1.4; 1.1.6; Add asm versions of blowfish and des transforms for i386.
This also involved updating the in-kernel DES functions to correspond to the versions in our in-tree OpenSSL, because the des_SPtrans table has changed; the asm code will not work with the old permutation table!
C and i386 asm code for the DES, 3DES, and Blowfish CBC modes is also included; it is not currently built as the ESP processing in esp_core.c splits the CBC operation and the cipher transform apart. Hopefully that will be fixed as there is a substantial performance improvement to be had from doing so. It will remain necessary to use the C version of the Blowfish CBC function on some i386 machines, however, as the asm version uses bswapl, which ony 486 and later processors have. The DES CBC code doesn't have this problem.
Finally, change esp_core.c to use the ecb3_encrypt function instead of calling ecb_encrypt three times; this improves performance a bit, in particular in the asm case.
|
1.1.6.2 | 01-Oct-2001 |
fvdl | Catch up with -current.
|
1.1.6.1 | 09-Sep-2001 |
fvdl | file des_enc.c was added on branch thorpej-devvp on 2001-10-01 12:44:04 +0000
|
1.1.4.3 | 14-Nov-2001 |
nathanw | Catch up to -current.
|
1.1.4.2 | 21-Sep-2001 |
nathanw | Catch up to -current.
|
1.1.4.1 | 09-Sep-2001 |
nathanw | file des_enc.c was added on branch nathanw_sa on 2001-09-21 22:35:25 +0000
|
1.1.2.3 | 10-Jan-2002 |
thorpej | Sync kqueue branch with -current.
|
1.1.2.2 | 13-Sep-2001 |
thorpej | Update the kqueue branch to HEAD.
|
1.1.2.1 | 09-Sep-2001 |
thorpej | file des_enc.c was added on branch kqueue on 2001-09-13 01:15:32 +0000
|
1.2.26.1 | 19-Mar-2005 |
yamt | sync with head. xen and whitespace. xen part is not finished.
|
1.2.24.1 | 29-Apr-2005 |
kent | sync with -current
|
1.2.16.1 | 04-Mar-2005 |
skrll | Sync with HEAD.
Hi Perry!
|
1.6 | 24-Feb-2025 |
andvar | fix various typos in comments.
|
1.5 | 04-Feb-2019 |
mrg | branches: 1.5.36; add fallthru comments. i considered patching makefiles to ignore these problems, but this code is dead upstream and likely will be removed here rather than ever updated.
|
1.4 | 09-Sep-2001 |
tls | branches: 1.4.206; Add asm versions of blowfish and des transforms for i386.
This also involved updating the in-kernel DES functions to correspond to the versions in our in-tree OpenSSL, because the des_SPtrans table has changed; the asm code will not work with the old permutation table!
C and i386 asm code for the DES, 3DES, and Blowfish CBC modes is also included; it is not currently built as the ESP processing in esp_core.c splits the CBC operation and the cipher transform apart. Hopefully that will be fixed as there is a substantial performance improvement to be had from doing so. It will remain necessary to use the C version of the Blowfish CBC function on some i386 machines, however, as the asm version uses bswapl, which ony 486 and later processors have. The DES CBC code doesn't have this problem.
Finally, change esp_core.c to use the ecb3_encrypt function instead of calling ecb_encrypt three times; this improves performance a bit, in particular in the asm case.
|
1.3 | 06-Nov-2000 |
itojun | branches: 1.3.2; 1.3.4; 1.3.6; 1.3.8; sync with kame. - include string.h (instead of sys/systm.h) on userland compilation. make compilation under src/regress/sys/crypto happier. from minoura - (blowfish) KNF.
|
1.2 | 31-Aug-2000 |
itojun | repair DES on LP64. past code did not interoperate with non-LP64, due to incorrect computed results. remove unnecessary #ifdef/#define. sync with kame.
|
1.1 | 14-Jun-2000 |
thorpej | branches: 1.1.1; Initial revision
|
1.1.1.1 | 14-Jun-2000 |
thorpej | branches: 1.1.1.1.2; 1.1.1.1.4; Import the IPsec crypto code from netbsd-cryptosrc-intl.
|
1.1.1.1.4.2 | 22-Jun-2000 |
minoura | Sync w/ netbsd-1-5-base.
|
1.1.1.1.4.1 | 14-Jun-2000 |
minoura | file des_locl.h was added on branch minoura-xpg4dl on 2000-06-22 17:06:08 +0000
|
1.1.1.1.2.1 | 31-Aug-2000 |
itojun | pullup (approved by releng-1-5)
> repair DES on LP64. past code did not interoperate with non-LP64, due to > incorrect computed results. > remove unnecessary #ifdef/#define. sync with kame.
> cvs rdiff -r1.1 -r1.2 syssrc/sys/crypto/des/des.h \ > syssrc/sys/crypto/des/des_3cbc.c syssrc/sys/crypto/des/des_cbc.c \ > syssrc/sys/crypto/des/des_ecb.c syssrc/sys/crypto/des/des_locl.h \ > syssrc/sys/crypto/des/des_setkey.c > cvs rdiff -r1.6 -r1.7 syssrc/sys/netinet6/esp_core.c (equivalent change)
|
1.3.8.1 | 01-Oct-2001 |
fvdl | Catch up with -current.
|
1.3.6.1 | 13-Sep-2001 |
thorpej | Update the kqueue branch to HEAD.
|
1.3.4.1 | 21-Sep-2001 |
nathanw | Catch up to -current.
|
1.3.2.3 | 22-Nov-2000 |
bouyer | Sync with HEAD.
|
1.3.2.2 | 20-Nov-2000 |
bouyer | Update thorpej_scsipi to -current as of a month ago
|
1.3.2.1 | 06-Nov-2000 |
bouyer | file des_locl.h was added on branch thorpej_scsipi on 2000-11-20 22:21:44 +0000
|
1.4.206.1 | 10-Jun-2019 |
christos | Sync with HEAD
|
1.5.36.1 | 02-Aug-2025 |
perseant | Sync with HEAD
|
1.1 | 01-Jan-2014 |
pgoyette | branches: 1.1.4; 1.1.6; 1.1.10; Create modules for software crypto components.
|
1.1.10.2 | 20-Aug-2014 |
tls | Rebase to HEAD as of a few days ago.
|
1.1.10.1 | 01-Jan-2014 |
tls | file des_module.c was added on branch tls-maxphys on 2014-08-20 00:03:34 +0000
|
1.1.6.2 | 22-May-2014 |
yamt | sync with head.
for a reference, the tree before this commit was tagged as yamt-pagecache-tag8.
this commit was splitted into small chunks to avoid a limitation of cvs. ("Protocol error: too many arguments")
|
1.1.6.1 | 01-Jan-2014 |
yamt | file des_module.c was added on branch yamt-pagecache on 2014-05-22 11:40:18 +0000
|
1.1.4.2 | 18-May-2014 |
rmind | sync with head
|
1.1.4.1 | 01-Jan-2014 |
rmind | file des_module.c was added on branch rmind-smpnet on 2014-05-18 17:45:34 +0000
|
1.10 | 11-Dec-2005 |
christos | merge ktrace-lwp.
|
1.9 | 26-Feb-2005 |
perry | nuke trailing whitespace
|
1.8 | 07-Nov-2002 |
thorpej | branches: 1.8.6; 1.8.14; 1.8.16; Fix signed/unsigned comparison warnings.
|
1.7 | 13-Nov-2001 |
lukem | add RCSIDs
|
1.6 | 09-Sep-2001 |
tls | Add asm versions of blowfish and des transforms for i386.
This also involved updating the in-kernel DES functions to correspond to the versions in our in-tree OpenSSL, because the des_SPtrans table has changed; the asm code will not work with the old permutation table!
C and i386 asm code for the DES, 3DES, and Blowfish CBC modes is also included; it is not currently built as the ESP processing in esp_core.c splits the CBC operation and the cipher transform apart. Hopefully that will be fixed as there is a substantial performance improvement to be had from doing so. It will remain necessary to use the C version of the Blowfish CBC function on some i386 machines, however, as the asm version uses bswapl, which ony 486 and later processors have. The DES CBC code doesn't have this problem.
Finally, change esp_core.c to use the ecb3_encrypt function instead of calling ecb_encrypt three times; this improves performance a bit, in particular in the asm case.
|
1.5 | 03-Jul-2001 |
itojun | branches: 1.5.2; 1.5.4; properl y check DES weak key. KAME PR 363
|
1.4 | 21-Feb-2001 |
jdolecek | branches: 1.4.2; make some more constant arrays 'const'
|
1.3 | 06-Nov-2000 |
itojun | branches: 1.3.2; sync with kame. - include string.h (instead of sys/systm.h) on userland compilation. make compilation under src/regress/sys/crypto happier. from minoura - (blowfish) KNF.
|
1.2 | 31-Aug-2000 |
itojun | repair DES on LP64. past code did not interoperate with non-LP64, due to incorrect computed results. remove unnecessary #ifdef/#define. sync with kame.
|
1.1 | 14-Jun-2000 |
thorpej | branches: 1.1.1; Initial revision
|
1.1.1.1 | 14-Jun-2000 |
thorpej | branches: 1.1.1.1.2; 1.1.1.1.4; Import the IPsec crypto code from netbsd-cryptosrc-intl.
|
1.1.1.1.4.2 | 22-Jun-2000 |
minoura | Sync w/ netbsd-1-5-base.
|
1.1.1.1.4.1 | 14-Jun-2000 |
minoura | file des_setkey.c was added on branch minoura-xpg4dl on 2000-06-22 17:06:09 +0000
|
1.1.1.1.2.1 | 31-Aug-2000 |
itojun | pullup (approved by releng-1-5)
> repair DES on LP64. past code did not interoperate with non-LP64, due to > incorrect computed results. > remove unnecessary #ifdef/#define. sync with kame.
> cvs rdiff -r1.1 -r1.2 syssrc/sys/crypto/des/des.h \ > syssrc/sys/crypto/des/des_3cbc.c syssrc/sys/crypto/des/des_cbc.c \ > syssrc/sys/crypto/des/des_ecb.c syssrc/sys/crypto/des/des_locl.h \ > syssrc/sys/crypto/des/des_setkey.c > cvs rdiff -r1.6 -r1.7 syssrc/sys/netinet6/esp_core.c (equivalent change)
|
1.3.2.4 | 12-Mar-2001 |
bouyer | Sync with HEAD.
|
1.3.2.3 | 22-Nov-2000 |
bouyer | Sync with HEAD.
|
1.3.2.2 | 20-Nov-2000 |
bouyer | Update thorpej_scsipi to -current as of a month ago
|
1.3.2.1 | 06-Nov-2000 |
bouyer | file des_setkey.c was added on branch thorpej_scsipi on 2000-11-20 22:21:44 +0000
|
1.4.2.4 | 11-Nov-2002 |
nathanw | Catch up to -current
|
1.4.2.3 | 14-Nov-2001 |
nathanw | Catch up to -current.
|
1.4.2.2 | 21-Sep-2001 |
nathanw | Catch up to -current.
|
1.4.2.1 | 24-Aug-2001 |
nathanw | Catch up with -current.
|
1.5.4.1 | 01-Oct-2001 |
fvdl | Catch up with -current.
|
1.5.2.2 | 10-Jan-2002 |
thorpej | Sync kqueue branch with -current.
|
1.5.2.1 | 13-Sep-2001 |
thorpej | Update the kqueue branch to HEAD.
|
1.8.16.1 | 19-Mar-2005 |
yamt | sync with head. xen and whitespace. xen part is not finished.
|
1.8.14.1 | 29-Apr-2005 |
kent | sync with -current
|
1.8.6.1 | 04-Mar-2005 |
skrll | Sync with HEAD.
Hi Perry!
|
1.2 | 01-Jan-2014 |
pgoyette | Create modules for software crypto components.
|
1.1 | 11-Oct-2002 |
thorpej | branches: 1.1.2; 1.1.146; 1.1.156; 1.1.162; * Move config defns for the crypto algorithms into their own files. Define an attribute for each crypto algorithm, and use that attribute to select the files that implement the algorithm. * Give the "wlan" attribute a dependency on the "arc4" attribute. * Give the "cgd" pseudo-device the "des", "blowfish", "cast128", and "rijndael" attributes. * Use the new attribute-as-option-dependencies feature of config(8) to give the IPSEC_ESP option dependencies on the "des", "blowfish", "cast128", and "rijndael" attributes.
|
1.1.162.1 | 18-May-2014 |
rmind | sync with head
|
1.1.156.1 | 20-Aug-2014 |
tls | Rebase to HEAD as of a few days ago.
|
1.1.146.1 | 22-May-2014 |
yamt | sync with head.
for a reference, the tree before this commit was tagged as yamt-pagecache-tag8.
this commit was splitted into small chunks to avoid a limitation of cvs. ("Protocol error: too many arguments")
|
1.1.2.2 | 18-Oct-2002 |
nathanw | Catch up to -current.
|
1.1.2.1 | 11-Oct-2002 |
nathanw | file files.des was added on branch nathanw_sa on 2002-10-18 02:41:23 +0000
|
1.1 | 14-Jun-2000 |
thorpej | branches: 1.1.1; Initial revision
|
1.1.1.1 | 14-Jun-2000 |
thorpej | branches: 1.1.1.1.4; 1.1.1.1.6; Import the IPsec crypto code from netbsd-cryptosrc-intl.
|
1.1.1.1.6.2 | 20-Nov-2000 |
bouyer | Update thorpej_scsipi to -current as of a month ago
|
1.1.1.1.6.1 | 14-Jun-2000 |
bouyer | file podd.h was added on branch thorpej_scsipi on 2000-11-20 22:21:44 +0000
|
1.1.1.1.4.2 | 22-Jun-2000 |
minoura | Sync w/ netbsd-1-5-base.
|
1.1.1.1.4.1 | 14-Jun-2000 |
minoura | file podd.h was added on branch minoura-xpg4dl on 2000-06-22 17:06:09 +0000
|
1.1 | 14-Jun-2000 |
thorpej | branches: 1.1.1; Initial revision
|
1.1.1.1 | 14-Jun-2000 |
thorpej | branches: 1.1.1.1.4; 1.1.1.1.6; Import the IPsec crypto code from netbsd-cryptosrc-intl.
|
1.1.1.1.6.2 | 20-Nov-2000 |
bouyer | Update thorpej_scsipi to -current as of a month ago
|
1.1.1.1.6.1 | 14-Jun-2000 |
bouyer | file sk.h was added on branch thorpej_scsipi on 2000-11-20 22:21:44 +0000
|
1.1.1.1.4.2 | 22-Jun-2000 |
minoura | Sync w/ netbsd-1-5-base.
|
1.1.1.1.4.1 | 14-Jun-2000 |
minoura | file sk.h was added on branch minoura-xpg4dl on 2000-06-22 17:06:09 +0000
|
1.3 | 26-Feb-2005 |
perry | nuke trailing whitespace
|
1.2 | 09-Sep-2001 |
tls | branches: 1.2.18; 1.2.26; 1.2.28; Add asm versions of blowfish and des transforms for i386.
This also involved updating the in-kernel DES functions to correspond to the versions in our in-tree OpenSSL, because the des_SPtrans table has changed; the asm code will not work with the old permutation table!
C and i386 asm code for the DES, 3DES, and Blowfish CBC modes is also included; it is not currently built as the ESP processing in esp_core.c splits the CBC operation and the cipher transform apart. Hopefully that will be fixed as there is a substantial performance improvement to be had from doing so. It will remain necessary to use the C version of the Blowfish CBC function on some i386 machines, however, as the asm version uses bswapl, which ony 486 and later processors have. The DES CBC code doesn't have this problem.
Finally, change esp_core.c to use the ecb3_encrypt function instead of calling ecb_encrypt three times; this improves performance a bit, in particular in the asm case.
|
1.1 | 14-Jun-2000 |
thorpej | branches: 1.1.1; Initial revision
|
1.1.1.1 | 14-Jun-2000 |
thorpej | branches: 1.1.1.1.4; 1.1.1.1.6; 1.1.1.1.8; 1.1.1.1.10; 1.1.1.1.12; Import the IPsec crypto code from netbsd-cryptosrc-intl.
|
1.1.1.1.12.1 | 13-Sep-2001 |
thorpej | Update the kqueue branch to HEAD.
|
1.1.1.1.10.1 | 01-Oct-2001 |
fvdl | Catch up with -current.
|
1.1.1.1.8.1 | 21-Sep-2001 |
nathanw | Catch up to -current.
|
1.1.1.1.6.2 | 20-Nov-2000 |
bouyer | Update thorpej_scsipi to -current as of a month ago
|
1.1.1.1.6.1 | 14-Jun-2000 |
bouyer | file spr.h was added on branch thorpej_scsipi on 2000-11-20 22:21:44 +0000
|
1.1.1.1.4.2 | 22-Jun-2000 |
minoura | Sync w/ netbsd-1-5-base.
|
1.1.1.1.4.1 | 14-Jun-2000 |
minoura | file spr.h was added on branch minoura-xpg4dl on 2000-06-22 17:06:10 +0000
|
1.2.28.1 | 19-Mar-2005 |
yamt | sync with head. xen and whitespace. xen part is not finished.
|
1.2.26.1 | 29-Apr-2005 |
kent | sync with -current
|
1.2.18.1 | 04-Mar-2005 |
skrll | Sync with HEAD.
Hi Perry!
|
1.6 | 11-Dec-2007 |
lukem | use __KERNEL_RCSID()
|
1.5 | 11-Dec-2005 |
christos | branches: 1.5.46; 1.5.56; 1.5.58; 1.5.60; merge ktrace-lwp.
|
1.4 | 26-Feb-2005 |
perry | branches: 1.4.4; nuke trailing whitespace
|
1.3 | 28-Nov-2003 |
keihan | branches: 1.3.8; 1.3.10; s/netbsd.org/NetBSD.org/g
|
1.2 | 12-Nov-2002 |
itohy | branches: 1.2.6; add non-ELF .align
|
1.1 | 09-Sep-2001 |
tls | branches: 1.1.2; 1.1.6; 1.1.14; Add asm versions of blowfish and des transforms for i386.
This also involved updating the in-kernel DES functions to correspond to the versions in our in-tree OpenSSL, because the des_SPtrans table has changed; the asm code will not work with the old permutation table!
C and i386 asm code for the DES, 3DES, and Blowfish CBC modes is also included; it is not currently built as the ESP processing in esp_core.c splits the CBC operation and the cipher transform apart. Hopefully that will be fixed as there is a substantial performance improvement to be had from doing so. It will remain necessary to use the C version of the Blowfish CBC function on some i386 machines, however, as the asm version uses bswapl, which ony 486 and later processors have. The DES CBC code doesn't have this problem.
Finally, change esp_core.c to use the ecb3_encrypt function instead of calling ecb_encrypt three times; this improves performance a bit, in particular in the asm case.
|
1.1.14.3 | 11-Dec-2002 |
thorpej | Sync with HEAD.
|
1.1.14.2 | 01-Apr-2002 |
nathanw | Add a few files missed in the merge.
|
1.1.14.1 | 09-Sep-2001 |
nathanw | file des_cbc.S was added on branch nathanw_sa on 2002-04-01 18:48:06 +0000
|
1.1.6.2 | 07-Feb-2002 |
jdolecek | add manually to the branch - these were somehow missed on merge
|
1.1.6.1 | 09-Sep-2001 |
jdolecek | file des_cbc.S was added on branch kqueue on 2002-02-07 07:06:37 +0000
|
1.1.2.2 | 01-Oct-2001 |
fvdl | Catch up with -current.
|
1.1.2.1 | 09-Sep-2001 |
fvdl | file des_cbc.S was added on branch thorpej-devvp on 2001-10-01 12:44:06 +0000
|
1.2.6.4 | 04-Mar-2005 |
skrll | Sync with HEAD.
Hi Perry!
|
1.2.6.3 | 21-Sep-2004 |
skrll | Fix the sync with head I botched.
|
1.2.6.2 | 18-Sep-2004 |
skrll | Sync with HEAD.
|
1.2.6.1 | 03-Aug-2004 |
skrll | Sync with HEAD
|
1.3.10.1 | 19-Mar-2005 |
yamt | sync with head. xen and whitespace. xen part is not finished.
|
1.3.8.1 | 29-Apr-2005 |
kent | sync with -current
|
1.4.4.1 | 21-Jan-2008 |
yamt | sync with head
|
1.5.60.1 | 13-Dec-2007 |
bouyer | Sync with HEAD
|
1.5.58.1 | 13-Dec-2007 |
yamt | sync with head.
|
1.5.56.1 | 26-Dec-2007 |
ad | Sync with head.
|
1.5.46.1 | 09-Jan-2008 |
matt | sync with HEAD
|
1.5 | 11-Dec-2007 |
lukem | use __KERNEL_RCSID()
|
1.4 | 11-Dec-2005 |
christos | branches: 1.4.46; 1.4.56; 1.4.58; 1.4.60; merge ktrace-lwp.
|
1.3 | 26-Feb-2005 |
perry | branches: 1.3.4; nuke trailing whitespace
|
1.2 | 28-Nov-2003 |
keihan | branches: 1.2.8; 1.2.10; s/netbsd.org/NetBSD.org/g
|
1.1 | 09-Sep-2001 |
tls | branches: 1.1.2; 1.1.6; 1.1.14; 1.1.24; Add asm versions of blowfish and des transforms for i386.
This also involved updating the in-kernel DES functions to correspond to the versions in our in-tree OpenSSL, because the des_SPtrans table has changed; the asm code will not work with the old permutation table!
C and i386 asm code for the DES, 3DES, and Blowfish CBC modes is also included; it is not currently built as the ESP processing in esp_core.c splits the CBC operation and the cipher transform apart. Hopefully that will be fixed as there is a substantial performance improvement to be had from doing so. It will remain necessary to use the C version of the Blowfish CBC function on some i386 machines, however, as the asm version uses bswapl, which ony 486 and later processors have. The DES CBC code doesn't have this problem.
Finally, change esp_core.c to use the ecb3_encrypt function instead of calling ecb_encrypt three times; this improves performance a bit, in particular in the asm case.
|
1.1.24.4 | 04-Mar-2005 |
skrll | Sync with HEAD.
Hi Perry!
|
1.1.24.3 | 21-Sep-2004 |
skrll | Fix the sync with head I botched.
|
1.1.24.2 | 18-Sep-2004 |
skrll | Sync with HEAD.
|
1.1.24.1 | 03-Aug-2004 |
skrll | Sync with HEAD
|
1.1.14.2 | 01-Apr-2002 |
nathanw | Add a few files missed in the merge.
|
1.1.14.1 | 09-Sep-2001 |
nathanw | file des_enc.S was added on branch nathanw_sa on 2002-04-01 18:48:07 +0000
|
1.1.6.2 | 07-Feb-2002 |
jdolecek | add manually to the branch - these were somehow missed on merge
|
1.1.6.1 | 09-Sep-2001 |
jdolecek | file des_enc.S was added on branch kqueue on 2002-02-07 07:06:37 +0000
|
1.1.2.2 | 01-Oct-2001 |
fvdl | Catch up with -current.
|
1.1.2.1 | 09-Sep-2001 |
fvdl | file des_enc.S was added on branch thorpej-devvp on 2001-10-01 12:44:07 +0000
|
1.2.10.1 | 19-Mar-2005 |
yamt | sync with head. xen and whitespace. xen part is not finished.
|
1.2.8.1 | 29-Apr-2005 |
kent | sync with -current
|
1.3.4.1 | 21-Jan-2008 |
yamt | sync with head
|
1.4.60.1 | 13-Dec-2007 |
bouyer | Sync with HEAD
|
1.4.58.1 | 13-Dec-2007 |
yamt | sync with head.
|
1.4.56.1 | 26-Dec-2007 |
ad | Sync with head.
|
1.4.46.1 | 09-Jan-2008 |
matt | sync with HEAD
|
1.1 | 02-Sep-2019 |
riastradh | branches: 1.1.2; 1.1.4; 1.1.6; 1.1.8; 1.1.10; 1.1.18; Switch from NIST CTR_DRBG with AES to NIST Hash_DRBG with SHA-256.
Benefits:
- larger seeds -- a 128-bit key alone is not enough for `128-bit security' - better resistance to timing side channels than AES - a better-understood security story (https://eprint.iacr.org/2018/349) - no loss in compliance with US government standards that nobody ever got fired for choosing, at least in the US-dominated western world - no dirty endianness tricks - self-tests
Drawbacks:
- performance hit: throughput is reduced to about 1/3 in naive measurements => possible to mitigate by using hardware SHA-256 instructions => all you really need is 32 bytes to seed a userland PRNG anyway => if we just used ChaCha this would go away...
XXX pullup-7 XXX pullup-8 XXX pullup-9
|
1.1.18.2 | 13-Apr-2020 |
martin | Mostly merge changes from HEAD upto 20200411
|
1.1.18.1 | 02-Sep-2019 |
martin | file files.nist_hash_drbg was added on branch phil-wifi on 2020-04-13 08:04:17 +0000
|
1.1.10.2 | 03-Sep-2019 |
martin | Pull up following revision(s) (requested by riastradh in ticket #1705):
sys/crypto/nist_hash_drbg/nist_hash_drbg.c: revision 1.1 sys/crypto/nist_hash_drbg/nist_hash_drbg.h: revision 1.1 sys/rump/kern/lib/libcrypto/Makefile: revision 1.5 sys/crypto/nist_hash_drbg/files.nist_hash_drbg: revision 1.1 sys/rump/librump/rumpkern/Makefile.rumpkern: revision 1.176 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes256.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_drbg_config.h: file removal sys/conf/files: revision 1.1238 sys/dev/rndpseudo.c: revision 1.38 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.c: file removal sys/sys/cprng.h: revision 1.13 - 1.15 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_aes_rijndael.h: file removal sys/crypto/nist_ctr_drbg/files.nist_ctr_drbg: file removal sys/kern/subr_cprng.c: revision 1.31 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes128.h: file removal
cprng.h: use static __inline for consistency with other include headers and remove an unused function.
-
Switch from NIST CTR_DRBG with AES to NIST Hash_DRBG with SHA-256.
Benefits: - larger seeds -- a 128-bit key alone is not enough for `128-bit security' - better resistance to timing side channels than AES - a better-understood security story (<a rel="nofollow" href="https://eprint.iacr.org/2018/349">https://eprint.iacr.org/2018/349</a>) - no loss in compliance with US government standards that nobody ever got fired for choosing, at least in the US-dominated western world - no dirty endianness tricks - self-tests
Drawbacks: - performance hit: throughput is reduced to about 1/3 in naive measurements => possible to mitigate by using hardware SHA-256 instructions => all you really need is 32 bytes to seed a userland PRNG anyway => if we just used ChaCha this would go away...
|
1.1.10.1 | 02-Sep-2019 |
martin | file files.nist_hash_drbg was added on branch netbsd-7-0 on 2019-09-03 12:30:45 +0000
|
1.1.8.2 | 03-Sep-2019 |
martin | Pull up following revision(s) (requested by riastradh in ticket #1705):
sys/crypto/nist_hash_drbg/nist_hash_drbg.c: revision 1.1 sys/crypto/nist_hash_drbg/nist_hash_drbg.h: revision 1.1 sys/rump/kern/lib/libcrypto/Makefile: revision 1.5 sys/crypto/nist_hash_drbg/files.nist_hash_drbg: revision 1.1 sys/rump/librump/rumpkern/Makefile.rumpkern: revision 1.176 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes256.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_drbg_config.h: file removal sys/conf/files: revision 1.1238 sys/dev/rndpseudo.c: revision 1.38 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.c: file removal sys/sys/cprng.h: revision 1.13 - 1.15 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_aes_rijndael.h: file removal sys/crypto/nist_ctr_drbg/files.nist_ctr_drbg: file removal sys/kern/subr_cprng.c: revision 1.31 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes128.h: file removal
cprng.h: use static __inline for consistency with other include headers and remove an unused function.
-
Switch from NIST CTR_DRBG with AES to NIST Hash_DRBG with SHA-256.
Benefits: - larger seeds -- a 128-bit key alone is not enough for `128-bit security' - better resistance to timing side channels than AES - a better-understood security story (<a rel="nofollow" href="https://eprint.iacr.org/2018/349">https://eprint.iacr.org/2018/349</a>) - no loss in compliance with US government standards that nobody ever got fired for choosing, at least in the US-dominated western world - no dirty endianness tricks - self-tests
Drawbacks: - performance hit: throughput is reduced to about 1/3 in naive measurements => possible to mitigate by using hardware SHA-256 instructions => all you really need is 32 bytes to seed a userland PRNG anyway => if we just used ChaCha this would go away...
|
1.1.8.1 | 02-Sep-2019 |
martin | file files.nist_hash_drbg was added on branch netbsd-7-1 on 2019-09-03 12:28:30 +0000
|
1.1.6.2 | 03-Sep-2019 |
martin | Pull up following revision(s) (requested by riastradh in ticket #1705):
sys/crypto/nist_hash_drbg/nist_hash_drbg.c: revision 1.1 sys/crypto/nist_hash_drbg/nist_hash_drbg.h: revision 1.1 sys/rump/kern/lib/libcrypto/Makefile: revision 1.5 sys/crypto/nist_hash_drbg/files.nist_hash_drbg: revision 1.1 sys/rump/librump/rumpkern/Makefile.rumpkern: revision 1.176 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes256.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_drbg_config.h: file removal sys/conf/files: revision 1.1238 sys/dev/rndpseudo.c: revision 1.38 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.c: file removal sys/sys/cprng.h: revision 1.13 - 1.15 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_aes_rijndael.h: file removal sys/crypto/nist_ctr_drbg/files.nist_ctr_drbg: file removal sys/kern/subr_cprng.c: revision 1.31 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes128.h: file removal
cprng.h: use static __inline for consistency with other include headers and remove an unused function.
-
Switch from NIST CTR_DRBG with AES to NIST Hash_DRBG with SHA-256.
Benefits: - larger seeds -- a 128-bit key alone is not enough for `128-bit security' - better resistance to timing side channels than AES - a better-understood security story (<a rel="nofollow" href="https://eprint.iacr.org/2018/349">https://eprint.iacr.org/2018/349</a>) - no loss in compliance with US government standards that nobody ever got fired for choosing, at least in the US-dominated western world - no dirty endianness tricks - self-tests
Drawbacks: - performance hit: throughput is reduced to about 1/3 in naive measurements => possible to mitigate by using hardware SHA-256 instructions => all you really need is 32 bytes to seed a userland PRNG anyway => if we just used ChaCha this would go away...
|
1.1.6.1 | 02-Sep-2019 |
martin | file files.nist_hash_drbg was added on branch netbsd-7 on 2019-09-03 12:20:42 +0000
|
1.1.4.2 | 03-Sep-2019 |
martin | Pull up following revision(s) (requested by riastradh in ticket #1365):
sys/crypto/nist_hash_drbg/nist_hash_drbg.c: revision 1.1 sys/crypto/nist_hash_drbg/nist_hash_drbg.h: revision 1.1 sys/rump/kern/lib/libcrypto/Makefile: revision 1.5 sys/crypto/nist_hash_drbg/files.nist_hash_drbg: revision 1.1 sys/rump/librump/rumpkern/Makefile.rumpkern: revision 1.176 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes256.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_drbg_config.h: file removal sys/conf/files: revision 1.1238 sys/dev/rndpseudo.c: revision 1.38 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.c: file removal sys/sys/cprng.h: revision 1.13 - 1.15 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_aes_rijndael.h: file removal sys/crypto/nist_ctr_drbg/files.nist_ctr_drbg: file removal sys/kern/subr_cprng.c: revision 1.31 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes128.h: file removal
cprng.h: use static __inline for consistency with other include headers and remove an unused function.
-
Switch from NIST CTR_DRBG with AES to NIST Hash_DRBG with SHA-256.
Benefits: - larger seeds -- a 128-bit key alone is not enough for `128-bit security' - better resistance to timing side channels than AES - a better-understood security story (<a rel="nofollow" href="https://eprint.iacr.org/2018/349">https://eprint.iacr.org/2018/349</a>) - no loss in compliance with US government standards that nobody ever got fired for choosing, at least in the US-dominated western world - no dirty endianness tricks - self-tests
Drawbacks: - performance hit: throughput is reduced to about 1/3 in naive measurements => possible to mitigate by using hardware SHA-256 instructions => all you really need is 32 bytes to seed a userland PRNG anyway => if we just used ChaCha this would go away...
|
1.1.4.1 | 02-Sep-2019 |
martin | file files.nist_hash_drbg was added on branch netbsd-8 on 2019-09-03 12:08:21 +0000
|
1.1.2.2 | 03-Sep-2019 |
martin | Pull up following revision(s) (requested by riastradh in ticket #173):
sys/crypto/nist_hash_drbg/nist_hash_drbg.c: revision 1.1 sys/crypto/nist_hash_drbg/nist_hash_drbg.h: revision 1.1 sys/rump/kern/lib/libcrypto/Makefile: revision 1.5 sys/crypto/nist_hash_drbg/files.nist_hash_drbg: revision 1.1 sys/rump/librump/rumpkern/Makefile.rumpkern: revision 1.176 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes256.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_drbg_config.h: file removal sys/conf/files: revision 1.1238 sys/dev/rndpseudo.c: revision 1.38 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.c: file removal sys/sys/cprng.h: revision 1.15 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_aes_rijndael.h: file removal sys/crypto/nist_ctr_drbg/files.nist_ctr_drbg: file removal sys/kern/subr_cprng.c: revision 1.31 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes128.h: file removal
Switch from NIST CTR_DRBG with AES to NIST Hash_DRBG with SHA-256.
Benefits: - larger seeds -- a 128-bit key alone is not enough for `128-bit security' - better resistance to timing side channels than AES - a better-understood security story (<a rel="nofollow" href="https://eprint.iacr.org/2018/349">https://eprint.iacr.org/2018/349</a>) - no loss in compliance with US government standards that nobody ever got fired for choosing, at least in the US-dominated western world - no dirty endianness tricks - self-tests
Drawbacks: - performance hit: throughput is reduced to about 1/3 in naive measurements => possible to mitigate by using hardware SHA-256 instructions => all you really need is 32 bytes to seed a userland PRNG anyway => if we just used ChaCha this would go away...
XXX pullup-7 XXX pullup-8 XXX pullup-9
|
1.1.2.1 | 02-Sep-2019 |
martin | file files.nist_hash_drbg was added on branch netbsd-9 on 2019-09-03 07:47:59 +0000
|
1.3 | 19-Sep-2019 |
riastradh | branches: 1.3.8; Use an explicit run-time assertion where compile-time doesn't work.
|
1.2 | 19-Sep-2019 |
riastradh | Use CTASSERT where possible, run-time assertion where not.
Should fix negative-length variable-length array found by kamil.
|
1.1 | 02-Sep-2019 |
riastradh | branches: 1.1.2; 1.1.4; 1.1.6; 1.1.8; 1.1.10; Switch from NIST CTR_DRBG with AES to NIST Hash_DRBG with SHA-256.
Benefits:
- larger seeds -- a 128-bit key alone is not enough for `128-bit security' - better resistance to timing side channels than AES - a better-understood security story (https://eprint.iacr.org/2018/349) - no loss in compliance with US government standards that nobody ever got fired for choosing, at least in the US-dominated western world - no dirty endianness tricks - self-tests
Drawbacks:
- performance hit: throughput is reduced to about 1/3 in naive measurements => possible to mitigate by using hardware SHA-256 instructions => all you really need is 32 bytes to seed a userland PRNG anyway => if we just used ChaCha this would go away...
XXX pullup-7 XXX pullup-8 XXX pullup-9
|
1.1.10.2 | 03-Sep-2019 |
martin | Pull up following revision(s) (requested by riastradh in ticket #1705):
sys/crypto/nist_hash_drbg/nist_hash_drbg.c: revision 1.1 sys/crypto/nist_hash_drbg/nist_hash_drbg.h: revision 1.1 sys/rump/kern/lib/libcrypto/Makefile: revision 1.5 sys/crypto/nist_hash_drbg/files.nist_hash_drbg: revision 1.1 sys/rump/librump/rumpkern/Makefile.rumpkern: revision 1.176 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes256.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_drbg_config.h: file removal sys/conf/files: revision 1.1238 sys/dev/rndpseudo.c: revision 1.38 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.c: file removal sys/sys/cprng.h: revision 1.13 - 1.15 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_aes_rijndael.h: file removal sys/crypto/nist_ctr_drbg/files.nist_ctr_drbg: file removal sys/kern/subr_cprng.c: revision 1.31 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes128.h: file removal
cprng.h: use static __inline for consistency with other include headers and remove an unused function.
-
Switch from NIST CTR_DRBG with AES to NIST Hash_DRBG with SHA-256.
Benefits: - larger seeds -- a 128-bit key alone is not enough for `128-bit security' - better resistance to timing side channels than AES - a better-understood security story (<a rel="nofollow" href="https://eprint.iacr.org/2018/349">https://eprint.iacr.org/2018/349</a>) - no loss in compliance with US government standards that nobody ever got fired for choosing, at least in the US-dominated western world - no dirty endianness tricks - self-tests
Drawbacks: - performance hit: throughput is reduced to about 1/3 in naive measurements => possible to mitigate by using hardware SHA-256 instructions => all you really need is 32 bytes to seed a userland PRNG anyway => if we just used ChaCha this would go away...
|
1.1.10.1 | 02-Sep-2019 |
martin | file nist_hash_drbg.c was added on branch netbsd-7-0 on 2019-09-03 12:30:45 +0000
|
1.1.8.2 | 03-Sep-2019 |
martin | Pull up following revision(s) (requested by riastradh in ticket #1705):
sys/crypto/nist_hash_drbg/nist_hash_drbg.c: revision 1.1 sys/crypto/nist_hash_drbg/nist_hash_drbg.h: revision 1.1 sys/rump/kern/lib/libcrypto/Makefile: revision 1.5 sys/crypto/nist_hash_drbg/files.nist_hash_drbg: revision 1.1 sys/rump/librump/rumpkern/Makefile.rumpkern: revision 1.176 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes256.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_drbg_config.h: file removal sys/conf/files: revision 1.1238 sys/dev/rndpseudo.c: revision 1.38 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.c: file removal sys/sys/cprng.h: revision 1.13 - 1.15 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_aes_rijndael.h: file removal sys/crypto/nist_ctr_drbg/files.nist_ctr_drbg: file removal sys/kern/subr_cprng.c: revision 1.31 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes128.h: file removal
cprng.h: use static __inline for consistency with other include headers and remove an unused function.
-
Switch from NIST CTR_DRBG with AES to NIST Hash_DRBG with SHA-256.
Benefits: - larger seeds -- a 128-bit key alone is not enough for `128-bit security' - better resistance to timing side channels than AES - a better-understood security story (<a rel="nofollow" href="https://eprint.iacr.org/2018/349">https://eprint.iacr.org/2018/349</a>) - no loss in compliance with US government standards that nobody ever got fired for choosing, at least in the US-dominated western world - no dirty endianness tricks - self-tests
Drawbacks: - performance hit: throughput is reduced to about 1/3 in naive measurements => possible to mitigate by using hardware SHA-256 instructions => all you really need is 32 bytes to seed a userland PRNG anyway => if we just used ChaCha this would go away...
|
1.1.8.1 | 02-Sep-2019 |
martin | file nist_hash_drbg.c was added on branch netbsd-7-1 on 2019-09-03 12:28:30 +0000
|
1.1.6.2 | 03-Sep-2019 |
martin | Pull up following revision(s) (requested by riastradh in ticket #1705):
sys/crypto/nist_hash_drbg/nist_hash_drbg.c: revision 1.1 sys/crypto/nist_hash_drbg/nist_hash_drbg.h: revision 1.1 sys/rump/kern/lib/libcrypto/Makefile: revision 1.5 sys/crypto/nist_hash_drbg/files.nist_hash_drbg: revision 1.1 sys/rump/librump/rumpkern/Makefile.rumpkern: revision 1.176 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes256.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_drbg_config.h: file removal sys/conf/files: revision 1.1238 sys/dev/rndpseudo.c: revision 1.38 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.c: file removal sys/sys/cprng.h: revision 1.13 - 1.15 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_aes_rijndael.h: file removal sys/crypto/nist_ctr_drbg/files.nist_ctr_drbg: file removal sys/kern/subr_cprng.c: revision 1.31 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes128.h: file removal
cprng.h: use static __inline for consistency with other include headers and remove an unused function.
-
Switch from NIST CTR_DRBG with AES to NIST Hash_DRBG with SHA-256.
Benefits: - larger seeds -- a 128-bit key alone is not enough for `128-bit security' - better resistance to timing side channels than AES - a better-understood security story (<a rel="nofollow" href="https://eprint.iacr.org/2018/349">https://eprint.iacr.org/2018/349</a>) - no loss in compliance with US government standards that nobody ever got fired for choosing, at least in the US-dominated western world - no dirty endianness tricks - self-tests
Drawbacks: - performance hit: throughput is reduced to about 1/3 in naive measurements => possible to mitigate by using hardware SHA-256 instructions => all you really need is 32 bytes to seed a userland PRNG anyway => if we just used ChaCha this would go away...
|
1.1.6.1 | 02-Sep-2019 |
martin | file nist_hash_drbg.c was added on branch netbsd-7 on 2019-09-03 12:20:42 +0000
|
1.1.4.2 | 03-Sep-2019 |
martin | Pull up following revision(s) (requested by riastradh in ticket #1365):
sys/crypto/nist_hash_drbg/nist_hash_drbg.c: revision 1.1 sys/crypto/nist_hash_drbg/nist_hash_drbg.h: revision 1.1 sys/rump/kern/lib/libcrypto/Makefile: revision 1.5 sys/crypto/nist_hash_drbg/files.nist_hash_drbg: revision 1.1 sys/rump/librump/rumpkern/Makefile.rumpkern: revision 1.176 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes256.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_drbg_config.h: file removal sys/conf/files: revision 1.1238 sys/dev/rndpseudo.c: revision 1.38 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.c: file removal sys/sys/cprng.h: revision 1.13 - 1.15 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_aes_rijndael.h: file removal sys/crypto/nist_ctr_drbg/files.nist_ctr_drbg: file removal sys/kern/subr_cprng.c: revision 1.31 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes128.h: file removal
cprng.h: use static __inline for consistency with other include headers and remove an unused function.
-
Switch from NIST CTR_DRBG with AES to NIST Hash_DRBG with SHA-256.
Benefits: - larger seeds -- a 128-bit key alone is not enough for `128-bit security' - better resistance to timing side channels than AES - a better-understood security story (<a rel="nofollow" href="https://eprint.iacr.org/2018/349">https://eprint.iacr.org/2018/349</a>) - no loss in compliance with US government standards that nobody ever got fired for choosing, at least in the US-dominated western world - no dirty endianness tricks - self-tests
Drawbacks: - performance hit: throughput is reduced to about 1/3 in naive measurements => possible to mitigate by using hardware SHA-256 instructions => all you really need is 32 bytes to seed a userland PRNG anyway => if we just used ChaCha this would go away...
|
1.1.4.1 | 02-Sep-2019 |
martin | file nist_hash_drbg.c was added on branch netbsd-8 on 2019-09-03 12:08:21 +0000
|
1.1.2.3 | 18-Sep-2022 |
martin | Pull up following revision(s) (requested by msaitoh in ticket #1530):
sys/crypto/nist_hash_drbg/nist_hash_drbg.c: revision 1.2 sys/crypto/nist_hash_drbg/nist_hash_drbg.c: revision 1.3
Use CTASSERT where possible, run-time assertion where not.
Should fix negative-length variable-length array found by kamil.
Use an explicit run-time assertion where compile-time doesn't work.
|
1.1.2.2 | 03-Sep-2019 |
martin | Pull up following revision(s) (requested by riastradh in ticket #173):
sys/crypto/nist_hash_drbg/nist_hash_drbg.c: revision 1.1 sys/crypto/nist_hash_drbg/nist_hash_drbg.h: revision 1.1 sys/rump/kern/lib/libcrypto/Makefile: revision 1.5 sys/crypto/nist_hash_drbg/files.nist_hash_drbg: revision 1.1 sys/rump/librump/rumpkern/Makefile.rumpkern: revision 1.176 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes256.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_drbg_config.h: file removal sys/conf/files: revision 1.1238 sys/dev/rndpseudo.c: revision 1.38 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.c: file removal sys/sys/cprng.h: revision 1.15 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_aes_rijndael.h: file removal sys/crypto/nist_ctr_drbg/files.nist_ctr_drbg: file removal sys/kern/subr_cprng.c: revision 1.31 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes128.h: file removal
Switch from NIST CTR_DRBG with AES to NIST Hash_DRBG with SHA-256.
Benefits: - larger seeds -- a 128-bit key alone is not enough for `128-bit security' - better resistance to timing side channels than AES - a better-understood security story (<a rel="nofollow" href="https://eprint.iacr.org/2018/349">https://eprint.iacr.org/2018/349</a>) - no loss in compliance with US government standards that nobody ever got fired for choosing, at least in the US-dominated western world - no dirty endianness tricks - self-tests
Drawbacks: - performance hit: throughput is reduced to about 1/3 in naive measurements => possible to mitigate by using hardware SHA-256 instructions => all you really need is 32 bytes to seed a userland PRNG anyway => if we just used ChaCha this would go away...
XXX pullup-7 XXX pullup-8 XXX pullup-9
|
1.1.2.1 | 02-Sep-2019 |
martin | file nist_hash_drbg.c was added on branch netbsd-9 on 2019-09-03 07:47:59 +0000
|
1.3.8.2 | 13-Apr-2020 |
martin | Mostly merge changes from HEAD upto 20200411
|
1.3.8.1 | 19-Sep-2019 |
martin | file nist_hash_drbg.c was added on branch phil-wifi on 2020-04-13 08:04:17 +0000
|
1.1 | 02-Sep-2019 |
riastradh | branches: 1.1.2; 1.1.4; 1.1.6; 1.1.8; 1.1.10; 1.1.18; Switch from NIST CTR_DRBG with AES to NIST Hash_DRBG with SHA-256.
Benefits:
- larger seeds -- a 128-bit key alone is not enough for `128-bit security' - better resistance to timing side channels than AES - a better-understood security story (https://eprint.iacr.org/2018/349) - no loss in compliance with US government standards that nobody ever got fired for choosing, at least in the US-dominated western world - no dirty endianness tricks - self-tests
Drawbacks:
- performance hit: throughput is reduced to about 1/3 in naive measurements => possible to mitigate by using hardware SHA-256 instructions => all you really need is 32 bytes to seed a userland PRNG anyway => if we just used ChaCha this would go away...
XXX pullup-7 XXX pullup-8 XXX pullup-9
|
1.1.18.2 | 13-Apr-2020 |
martin | Mostly merge changes from HEAD upto 20200411
|
1.1.18.1 | 02-Sep-2019 |
martin | file nist_hash_drbg.h was added on branch phil-wifi on 2020-04-13 08:04:17 +0000
|
1.1.10.2 | 03-Sep-2019 |
martin | Pull up following revision(s) (requested by riastradh in ticket #1705):
sys/crypto/nist_hash_drbg/nist_hash_drbg.c: revision 1.1 sys/crypto/nist_hash_drbg/nist_hash_drbg.h: revision 1.1 sys/rump/kern/lib/libcrypto/Makefile: revision 1.5 sys/crypto/nist_hash_drbg/files.nist_hash_drbg: revision 1.1 sys/rump/librump/rumpkern/Makefile.rumpkern: revision 1.176 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes256.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_drbg_config.h: file removal sys/conf/files: revision 1.1238 sys/dev/rndpseudo.c: revision 1.38 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.c: file removal sys/sys/cprng.h: revision 1.13 - 1.15 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_aes_rijndael.h: file removal sys/crypto/nist_ctr_drbg/files.nist_ctr_drbg: file removal sys/kern/subr_cprng.c: revision 1.31 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes128.h: file removal
cprng.h: use static __inline for consistency with other include headers and remove an unused function.
-
Switch from NIST CTR_DRBG with AES to NIST Hash_DRBG with SHA-256.
Benefits: - larger seeds -- a 128-bit key alone is not enough for `128-bit security' - better resistance to timing side channels than AES - a better-understood security story (<a rel="nofollow" href="https://eprint.iacr.org/2018/349">https://eprint.iacr.org/2018/349</a>) - no loss in compliance with US government standards that nobody ever got fired for choosing, at least in the US-dominated western world - no dirty endianness tricks - self-tests
Drawbacks: - performance hit: throughput is reduced to about 1/3 in naive measurements => possible to mitigate by using hardware SHA-256 instructions => all you really need is 32 bytes to seed a userland PRNG anyway => if we just used ChaCha this would go away...
|
1.1.10.1 | 02-Sep-2019 |
martin | file nist_hash_drbg.h was added on branch netbsd-7-0 on 2019-09-03 12:30:45 +0000
|
1.1.8.2 | 03-Sep-2019 |
martin | Pull up following revision(s) (requested by riastradh in ticket #1705):
sys/crypto/nist_hash_drbg/nist_hash_drbg.c: revision 1.1 sys/crypto/nist_hash_drbg/nist_hash_drbg.h: revision 1.1 sys/rump/kern/lib/libcrypto/Makefile: revision 1.5 sys/crypto/nist_hash_drbg/files.nist_hash_drbg: revision 1.1 sys/rump/librump/rumpkern/Makefile.rumpkern: revision 1.176 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes256.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_drbg_config.h: file removal sys/conf/files: revision 1.1238 sys/dev/rndpseudo.c: revision 1.38 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.c: file removal sys/sys/cprng.h: revision 1.13 - 1.15 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_aes_rijndael.h: file removal sys/crypto/nist_ctr_drbg/files.nist_ctr_drbg: file removal sys/kern/subr_cprng.c: revision 1.31 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes128.h: file removal
cprng.h: use static __inline for consistency with other include headers and remove an unused function.
-
Switch from NIST CTR_DRBG with AES to NIST Hash_DRBG with SHA-256.
Benefits: - larger seeds -- a 128-bit key alone is not enough for `128-bit security' - better resistance to timing side channels than AES - a better-understood security story (<a rel="nofollow" href="https://eprint.iacr.org/2018/349">https://eprint.iacr.org/2018/349</a>) - no loss in compliance with US government standards that nobody ever got fired for choosing, at least in the US-dominated western world - no dirty endianness tricks - self-tests
Drawbacks: - performance hit: throughput is reduced to about 1/3 in naive measurements => possible to mitigate by using hardware SHA-256 instructions => all you really need is 32 bytes to seed a userland PRNG anyway => if we just used ChaCha this would go away...
|
1.1.8.1 | 02-Sep-2019 |
martin | file nist_hash_drbg.h was added on branch netbsd-7-1 on 2019-09-03 12:28:30 +0000
|
1.1.6.2 | 03-Sep-2019 |
martin | Pull up following revision(s) (requested by riastradh in ticket #1705):
sys/crypto/nist_hash_drbg/nist_hash_drbg.c: revision 1.1 sys/crypto/nist_hash_drbg/nist_hash_drbg.h: revision 1.1 sys/rump/kern/lib/libcrypto/Makefile: revision 1.5 sys/crypto/nist_hash_drbg/files.nist_hash_drbg: revision 1.1 sys/rump/librump/rumpkern/Makefile.rumpkern: revision 1.176 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes256.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_drbg_config.h: file removal sys/conf/files: revision 1.1238 sys/dev/rndpseudo.c: revision 1.38 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.c: file removal sys/sys/cprng.h: revision 1.13 - 1.15 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_aes_rijndael.h: file removal sys/crypto/nist_ctr_drbg/files.nist_ctr_drbg: file removal sys/kern/subr_cprng.c: revision 1.31 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes128.h: file removal
cprng.h: use static __inline for consistency with other include headers and remove an unused function.
-
Switch from NIST CTR_DRBG with AES to NIST Hash_DRBG with SHA-256.
Benefits: - larger seeds -- a 128-bit key alone is not enough for `128-bit security' - better resistance to timing side channels than AES - a better-understood security story (<a rel="nofollow" href="https://eprint.iacr.org/2018/349">https://eprint.iacr.org/2018/349</a>) - no loss in compliance with US government standards that nobody ever got fired for choosing, at least in the US-dominated western world - no dirty endianness tricks - self-tests
Drawbacks: - performance hit: throughput is reduced to about 1/3 in naive measurements => possible to mitigate by using hardware SHA-256 instructions => all you really need is 32 bytes to seed a userland PRNG anyway => if we just used ChaCha this would go away...
|
1.1.6.1 | 02-Sep-2019 |
martin | file nist_hash_drbg.h was added on branch netbsd-7 on 2019-09-03 12:20:42 +0000
|
1.1.4.2 | 03-Sep-2019 |
martin | Pull up following revision(s) (requested by riastradh in ticket #1365):
sys/crypto/nist_hash_drbg/nist_hash_drbg.c: revision 1.1 sys/crypto/nist_hash_drbg/nist_hash_drbg.h: revision 1.1 sys/rump/kern/lib/libcrypto/Makefile: revision 1.5 sys/crypto/nist_hash_drbg/files.nist_hash_drbg: revision 1.1 sys/rump/librump/rumpkern/Makefile.rumpkern: revision 1.176 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes256.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_drbg_config.h: file removal sys/conf/files: revision 1.1238 sys/dev/rndpseudo.c: revision 1.38 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.c: file removal sys/sys/cprng.h: revision 1.13 - 1.15 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_aes_rijndael.h: file removal sys/crypto/nist_ctr_drbg/files.nist_ctr_drbg: file removal sys/kern/subr_cprng.c: revision 1.31 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes128.h: file removal
cprng.h: use static __inline for consistency with other include headers and remove an unused function.
-
Switch from NIST CTR_DRBG with AES to NIST Hash_DRBG with SHA-256.
Benefits: - larger seeds -- a 128-bit key alone is not enough for `128-bit security' - better resistance to timing side channels than AES - a better-understood security story (<a rel="nofollow" href="https://eprint.iacr.org/2018/349">https://eprint.iacr.org/2018/349</a>) - no loss in compliance with US government standards that nobody ever got fired for choosing, at least in the US-dominated western world - no dirty endianness tricks - self-tests
Drawbacks: - performance hit: throughput is reduced to about 1/3 in naive measurements => possible to mitigate by using hardware SHA-256 instructions => all you really need is 32 bytes to seed a userland PRNG anyway => if we just used ChaCha this would go away...
|
1.1.4.1 | 02-Sep-2019 |
martin | file nist_hash_drbg.h was added on branch netbsd-8 on 2019-09-03 12:08:21 +0000
|
1.1.2.2 | 03-Sep-2019 |
martin | Pull up following revision(s) (requested by riastradh in ticket #173):
sys/crypto/nist_hash_drbg/nist_hash_drbg.c: revision 1.1 sys/crypto/nist_hash_drbg/nist_hash_drbg.h: revision 1.1 sys/rump/kern/lib/libcrypto/Makefile: revision 1.5 sys/crypto/nist_hash_drbg/files.nist_hash_drbg: revision 1.1 sys/rump/librump/rumpkern/Makefile.rumpkern: revision 1.176 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes256.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_drbg_config.h: file removal sys/conf/files: revision 1.1238 sys/dev/rndpseudo.c: revision 1.38 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.c: file removal sys/sys/cprng.h: revision 1.15 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_aes_rijndael.h: file removal sys/crypto/nist_ctr_drbg/files.nist_ctr_drbg: file removal sys/kern/subr_cprng.c: revision 1.31 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes128.h: file removal
Switch from NIST CTR_DRBG with AES to NIST Hash_DRBG with SHA-256.
Benefits: - larger seeds -- a 128-bit key alone is not enough for `128-bit security' - better resistance to timing side channels than AES - a better-understood security story (<a rel="nofollow" href="https://eprint.iacr.org/2018/349">https://eprint.iacr.org/2018/349</a>) - no loss in compliance with US government standards that nobody ever got fired for choosing, at least in the US-dominated western world - no dirty endianness tricks - self-tests
Drawbacks: - performance hit: throughput is reduced to about 1/3 in naive measurements => possible to mitigate by using hardware SHA-256 instructions => all you really need is 32 bytes to seed a userland PRNG anyway => if we just used ChaCha this would go away...
XXX pullup-7 XXX pullup-8 XXX pullup-9
|
1.1.2.1 | 02-Sep-2019 |
martin | file nist_hash_drbg.h was added on branch netbsd-9 on 2019-09-03 07:47:59 +0000
|
1.2 | 11-Dec-2005 |
christos | merge ktrace-lwp.
|
1.1 | 16-Nov-2003 |
tls | branches: 1.1.4; Move the Skipjack algorithm from sys/opencrypto to sys/crypto/skipjack. There are now no cryptographic algorithms in sys/opencrypto, which, according to the comment formerly in files.opencrypto, was the original intent.
|
1.1.4.4 | 21-Sep-2004 |
skrll | Fix the sync with head I botched.
|
1.1.4.3 | 18-Sep-2004 |
skrll | Sync with HEAD.
|
1.1.4.2 | 03-Aug-2004 |
skrll | Sync with HEAD
|
1.1.4.1 | 16-Nov-2003 |
skrll | file files.skipjack was added on branch ktrace-lwp on 2004-08-03 10:44:46 +0000
|
1.4 | 01-Jan-2014 |
pgoyette | Create modules for software crypto components.
|
1.3 | 11-Dec-2005 |
christos | branches: 1.3.110; 1.3.120; 1.3.126; merge ktrace-lwp.
|
1.2 | 26-Feb-2005 |
perry | nuke trailing whitespace
|
1.1 | 16-Nov-2003 |
tls | branches: 1.1.4; 1.1.10; 1.1.12; Move the Skipjack algorithm from sys/opencrypto to sys/crypto/skipjack. There are now no cryptographic algorithms in sys/opencrypto, which, according to the comment formerly in files.opencrypto, was the original intent.
|
1.1.12.1 | 19-Mar-2005 |
yamt | sync with head. xen and whitespace. xen part is not finished.
|
1.1.10.1 | 29-Apr-2005 |
kent | sync with -current
|
1.1.4.5 | 04-Mar-2005 |
skrll | Sync with HEAD.
Hi Perry!
|
1.1.4.4 | 21-Sep-2004 |
skrll | Fix the sync with head I botched.
|
1.1.4.3 | 18-Sep-2004 |
skrll | Sync with HEAD.
|
1.1.4.2 | 03-Aug-2004 |
skrll | Sync with HEAD
|
1.1.4.1 | 16-Nov-2003 |
skrll | file skipjack.c was added on branch ktrace-lwp on 2004-08-03 10:44:46 +0000
|
1.3.126.1 | 18-May-2014 |
rmind | sync with head
|
1.3.120.1 | 20-Aug-2014 |
tls | Rebase to HEAD as of a few days ago.
|
1.3.110.1 | 22-May-2014 |
yamt | sync with head.
for a reference, the tree before this commit was tagged as yamt-pagecache-tag8.
this commit was splitted into small chunks to avoid a limitation of cvs. ("Protocol error: too many arguments")
|
1.3 | 11-Dec-2005 |
christos | merge ktrace-lwp.
|
1.2 | 26-Feb-2005 |
perry | nuke trailing whitespace
|
1.1 | 16-Nov-2003 |
tls | branches: 1.1.4; 1.1.10; 1.1.12; Move the Skipjack algorithm from sys/opencrypto to sys/crypto/skipjack. There are now no cryptographic algorithms in sys/opencrypto, which, according to the comment formerly in files.opencrypto, was the original intent.
|
1.1.12.1 | 19-Mar-2005 |
yamt | sync with head. xen and whitespace. xen part is not finished.
|
1.1.10.1 | 29-Apr-2005 |
kent | sync with -current
|
1.1.4.5 | 04-Mar-2005 |
skrll | Sync with HEAD.
Hi Perry!
|
1.1.4.4 | 21-Sep-2004 |
skrll | Fix the sync with head I botched.
|
1.1.4.3 | 18-Sep-2004 |
skrll | Sync with HEAD.
|
1.1.4.2 | 03-Aug-2004 |
skrll | Sync with HEAD
|
1.1.4.1 | 16-Nov-2003 |
skrll | file skipjack.h was added on branch ktrace-lwp on 2004-08-03 10:44:46 +0000
|
1.1 | 20-Aug-2020 |
riastradh | [ozaki-r] libsodium glue
|
1.1 | 20-Aug-2020 |
riastradh | [ozaki-r] libsodium glue
|
1.1 | 20-Aug-2020 |
riastradh | [ozaki-r] libsodium glue
|
1.1 | 20-Aug-2020 |
riastradh | [ozaki-r] libsodium glue
|
1.1 | 20-Aug-2020 |
riastradh | [ozaki-r] libsodium glue
|
1.1 | 20-Aug-2020 |
riastradh | [ozaki-r] libsodium glue
|
1.1 | 20-Aug-2020 |
riastradh | [ozaki-r] libsodium glue
|
1.2 | 26-Jul-2024 |
riastradh | branches: 1.2.2; 1.2.6; sys/crypto/sodium: Add self-test for XChaCha20/Poly1305 AEAD.
PR kern/58468
|
1.1 | 26-Jul-2024 |
riastradh | sys/crypto/sodium: Add a self-test for IETF ChaCha20/Poly1305 AEAD.
PR kern/58468
|
1.2.6.2 | 02-Aug-2025 |
perseant | Sync with HEAD
|
1.2.6.1 | 26-Jul-2024 |
perseant | file sodium_selftest.h was added on branch perseant-exfatfs on 2025-08-02 05:56:30 +0000
|
1.2.2.2 | 09-Oct-2024 |
martin | Pull up following revision(s) (requested by riastradh in ticket #933):
sys/external/isc/libsodium/src/sodium_module.c: revision 1.2 sys/external/isc/libsodium/include/core.h: revision 1.2 sys/external/isc/libsodium/include/stdlib.h: revision 1.2 sys/modules/sodium/Makefile.sodmod: revision 1.4 sys/external/isc/libsodium/include/crypto_verify_16.h: revision 1.2 sys/external/isc/libsodium/include/errno.h: file removal sys/crypto/sodium/sodium_selftest.h: revision 1.1 sys/external/isc/libsodium/include/stdint.h: revision 1.2 sys/crypto/sodium/sodium_selftest.h: revision 1.2 sys/external/isc/libsodium/include/assert.h: file removal sys/external/isc/libsodium/conf/files.libsodium: revision 1.7 sys/rump/kern/lib/libcrypto/Makefile: revision 1.24 sys/external/isc/libsodium/src/sodium_selftest.c: revision 1.1 sys/external/isc/libsodium/src/sodium_selftest.c: revision 1.2 sys/external/isc/libsodium/include/string.h: revision 1.2
sys/crypto/sodium: Add a self-test for IETF ChaCha20/Poly1305 AEAD. PR kern/58468
sys/crypto/sodium: Fill out crypto_verify_16 stub.
Without this change, libsodium silently accepts forgeries.
This one's a doozy, and it's a sobering reminder that: (a) wg(4) is still experimental (only user of libsodium in kernel; both are available only through default-off optional modules). (b) Known-answer test vectors are critical, including negative tests (test that forgeries are rejected), and must be mandatory for all new crypto code -- and should be added to old crypto code too. (c) Crypto code must also have self-tests that run in the same environment, not just the same code in a different build or test environment -- the libsodium code itself is fine, but we built it differently and need to exercise it differently from upstream's automatic tests.
It's my fault for not catching this earlier. What happened is: 1. ozaki-r@ adapted libsodium to build in the kernel with various glue to build code meant for standard userland C, like errno.h and string.h. 2. Since libsodium's crypto_verify_16.c uses various SIMD intrinsics on various architectures, it couldn't be used directly in the kernel build, because -- at the time -- we hadn't wired up any header files for SIMD intrinsics or any runtime support for saving and restoring SIMD state appropriately in the kernel. 3. ozaki-r@ put a similar glue header file crypto_verify_16.h to override libsodium's, with a stub to be implemented later, and presumably forgot to remind me about it. 4. I missed the stub in crypto_verify_16.h when reviewing the libsodium import and wg(4) code because it was in the same directory as various other simple glue code that I deemed low-risk. (I did make one change to that glue code, to replace cprng_fast by cprng_strong, but I suspect I found that by searching for cprng_fast users rather than by reviewing this code.) 5. I broke my own rule about always having known-answer test vectors for crypto code because I figured libsodium was well-enough exercised that we could skimp on it for now, and my focus was more on the state machine and synchronization logic than on the crypto. 6. I had not yet written known-answer test vectors for the higher-level wg(4) protocol messages.
Before we can remove the `experimental' tag from wg(4) we will need to (among other things): i. Write self-tests for the rest of (what we use from) libsodium. ii. Write extensive known-answer test vectors for all the wg(4) protocol messages (and ideally state machine transitions). iii. Write self-tests for a reasonable subset of the wg(4) KATs. iv. Review all of the libsodium glue code I neglected to review. PR kern/58468
sys/crypto/sodium: Simplify string.h stub.
Not sure of any particular problem with the previous stub, but let's make sure to use the same prototypes for memset/memcpy/memmove as everything else in the kernel. PR kern/58468
sys/crypto/sodium: Nix unused assert.h stub.
Maybe this was a vestige of an earlier draft of the libsodium import, but it doesn't appear to be needed now by any libsodium files we use. PR kern/58468
sys/crypto/sodium: Nix risky defines from core.h stub.
These are risky not because they might cause crypto flaws, but because they might cause usage of the SIMD unit in the kernel along paths where we haven't made it safe.
That said -- no change to the amd64 module .o and .kmod files, so this doesn't currently make a difference; it's just risky to have around in case we later include other parts of libsodium that it does affect, like the Salsa20 code. PR kern/58468
sys/crypto/sodium: Nix unused errno.h.
Maybe this was a vestige of an earlier draft of the libsodium import, but it doesn't appear to be needed now by any libsodium files we use. PR kern/58468
sys/crypto/sodium: Simplify stdint.h stub. No change to the .o or .kmod files; just the .d make dependency files change. PR kern/58468
sys/crypto/sodium: Tighten stdlib.h glue. 1. Make sure nothing uses malloc and free. All of the routines we need should work in fixed-size, caller-allocated buffers and reasonable stack space. 2. Make panic message for abort() stub clearer. There are calls to it, but they imply internal errors inside libsodium which should not happen unless there is an unrecoverable software bug in libsodium. PR kern/58468
sys/crypto/sodium: Add self-test for XChaCha20/Poly1305 AEAD. PR kern/58468
|
1.2.2.1 | 26-Jul-2024 |
martin | file sodium_selftest.h was added on branch netbsd-10 on 2024-10-09 10:49:04 +0000
|