04a6492d1e
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. |
||
|---|---|---|
| .. | ||
| dev | ||
| fs | ||
| include | ||
| kern | ||
| librump | ||
| net | ||
| share | ||
| Makefile | ||
| Makefile.rump | ||
| README.compileopts | ||
| README.dirs | ||
| TODO | ||
| ldscript.rump | ||
| ldscript_sun.rump | ||
| linksyms_sun.c | ||
| listsrcdirs | ||
| makerumpsyscalls.sh | ||
| rump.sysmap | ||
| sunldgen.sh | ||
README.dirs
$NetBSD: README.dirs,v 1.12 2013/01/08 13:12:26 pooka Exp $
The following is a quick rundown of the current directory structure.
First, components in the kernel namespace, i.e. compiled with -D_KERNEL
sys/rump/librump - rump kernel base and factions
/rumpkern - kernel core, e.g. syscall, interrupt and lock support
/rumpdev - device support, e.g. autoconf subsystem
/rumpnet - networking support and sockets layer
/rumpvfs - file system support
sys/rump/include
/machine - used for architectures where the rump kernel ABI is not yet the
same as the kernel module ABI. will eventually disappear
completely
/rump - kernel headers installed to userspace
sys/rump/dev - device components, e.g. audio, raidframe, usb drivers
sys/rump/fs - file system components
/lib/lib${fs} - kernel file system code
sys/rump/net - networking components
/lib/libnet - subroutines from sys/net, e.g. route and if_ethersubr
/lib/libnetinet - TCP/IP
/lib/libvirtif - a virtual interface which uses host tap(4) to shovel
packets. This is used by netinet and if_ethersubr.
/lib/libshmif - a virtual interface which uses a memory mapped file
as an ethernet bus. works completely unprivileged.
/lib/libsockin - implements PF_INET using host kernel sockets. This is
mutually exclusive with net, netinet and virtif.
The rest are out-of-kernel components (i.e. no -D_KERNEL).
hypercall interface:
src/lib/librumpuser
The "rumpuser" hypercall interfaces are used by a rump kernel to
access host resources.
remote client interface:
src/lib/librumpclient
The rumpclient library provides remote access to rump kernel servers.
system call hijacking:
src/lib/librumphijack
The rumphijack library allows intercepting system calls and redirecting
them to a rump kernel server instead of the host kernel. In other
words, it allows existing binaries to request indicated services from
a rump kernel instead of from the host kernel.
Users:
src/lib
/libp2k - puffs-to-vfs adaption layer, userspace namespace
/libukfs - user kernel file system, a library to access file system
images (or devices) directly in userspace without going
through a system call and puffs. It provides a slightly
higher interface than syscalls.
src/usr.sbin/puffs
rump_$fs - userspace file system daemons using the kernel fs code
src/share/examples/rump
Various examples detailing use of rump kernels in different scenarios.
These are provided source-only.