| History log of /src/sys/crypto/aes/aes_impl.c |
| Revision | | Date | Author | Comments |
| 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
|
