CVS log for src/sys/crypto/aes/aes.h

Up to [cvs.NetBSD.org] / src / sys / crypto / aes

Request diff between arbitrary revisions

Keyword substitution: kv
Default branch: MAIN

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.)

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.

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.

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