Re: sync rijndael-alg-fst.c with OpenBSD

[Taylor R Campbell <campbell+netbsd-tech-crypto%mumble.net@localhost>]

   Date: Sat, 1 Oct 2016 16:45:22 +0100
   From: Alexander Nasonov <alnsn%yandex.ru@localhost>

   Taylor R Campbell wrote:
   > 1. Implement AES-NI in the kernel and teach cgd(4) to use it.
   >    Requires saving and restoring the SSE state in kernel threads --
   >    I'm not sure offhand what the status of that on x86 is.

   It's a very well known implementation but it's x86 only. Other platforms
   are still vulnerable to timing attacks.

Quite so.  However, for disks that are already encrypted with AES, the
problems of AES are unavoidable: either slow, hardware-specific, or
vulnerable -- pick one.

   > 2. Add support for a block cipher that is not designed to leak secrets
   >    through timing like AES is, such as Threefish.  Here's some
   >    portable C code for Threefish:
   > 
   >    http://mumble.net/~campbell/tmp/threefish.c
   >    http://mumble.net/~campbell/tmp/threefish.h

   It looks nice. Is there anything that stops you from porting it to
   NetBSD?

Just time.  Hooking that code up to the cgd_crypto API is left as an
easy exercise for the more time-endowed reader.

   > If you want to make it, could you also add an AES self-test with a few
   > known-answer test vectors, like we have for ChaCha20 in
   > sys/crypto/cprng_fast/cprng_fast.c?

   Your case is simpler because you test only one algorithm on startup.
   It's not clear when to test cgd algorithms. For instance, it could be
   done when cgd is attached or when a key/params are received from
   userspace.

You could do it for all algorithms in the cgd module initialization.
A handful of block ciphers * a handful of encrypt/decrypt operations
should take negligible time.  But if you wanted to do it instead when
configuring a cgd, and return ENXIO if the crypto self-test fails,
that would be OK too.

My main concern is that we ought to have automatic internal self-tests
for any new changes to the crypto code, especially if there might be
any hardware-specific code added such as AES-NI or any analogues on
ARM, RISC-V, &c.  Exactly how that figures into the code isn't
important to me as long as it always runs no matter what AES code
we're using.

   While we're here, two const arrays can be made static in
   crypto_core_selftest():

I don't see an obvious advantage, but no objection here if you see one
and want to make that change.  This code isn't performance-critical,
so the main metric to optimize in this case would be kernel code size.