CVS commit: src

["Taylor R Campbell" <riastradh%netbsd.org@localhost>]

Module Name:    src
Committed By:   riastradh
Date:           Mon Jun 29 23:44:02 UTC 2020

Modified Files:
        src/distrib/sets/lists/debug: mi
        src/distrib/sets/lists/tests: mi
        src/sys/conf: files
        src/sys/dev: cgd_crypto.c
        src/sys/rump/kern/lib/libcrypto: Makefile
        src/tests/dev/cgd: Makefile
Added Files:
        src/sys/crypto/adiantum: adiantum.c adiantum.h adiantum_selftest.c
            files.adiantum
        src/tests/dev/cgd: t_cgd_adiantum.c

Log Message:
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.


To generate a diff of this commit:
cvs rdiff -u -r1.319 -r1.320 src/distrib/sets/lists/debug/mi
cvs rdiff -u -r1.862 -r1.863 src/distrib/sets/lists/tests/mi
cvs rdiff -u -r1.1270 -r1.1271 src/sys/conf/files
cvs rdiff -u -r0 -r1.1 src/sys/crypto/adiantum/adiantum.c \
    src/sys/crypto/adiantum/adiantum.h \
    src/sys/crypto/adiantum/adiantum_selftest.c \
    src/sys/crypto/adiantum/files.adiantum
cvs rdiff -u -r1.25 -r1.26 src/sys/dev/cgd_crypto.c
cvs rdiff -u -r1.7 -r1.8 src/sys/rump/kern/lib/libcrypto/Makefile
cvs rdiff -u -r1.10 -r1.11 src/tests/dev/cgd/Makefile
cvs rdiff -u -r0 -r1.1 src/tests/dev/cgd/t_cgd_adiantum.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.