LWN: Comments on "Adiantum: encryption for the low end"

Adiantum: encryption for the low end

mcortese — Tue, 05 Feb 2019 19:01:13 +0000

> Low-end devices bound for developing countries [...] lack encryption support because the hardware doesn't provide any cryptographic acceleration.

Many laptops from less than 5 years ago not targeted at developing countries are equipped with Celeron processors with no AES-NI support as well.

Adiantum: encryption for the low end

zyzzyva — Thu, 17 Jan 2019 23:57:48 +0000

> Is there any reason not change the `crytsetup` default to be 4K?

(1) Compatibility with old kernels and cryptsetup versions. The 4K encryption sector support is still fairly new, after all.

(2) It's not guaranteed safe on disks with 512-byte sectors, as it can break atomicity guarantees that might be assumed by software. I don't believe this is a problem on modern disks or flash storage, nor on ext4 or f2fs. But the cryptsetup default needs to be more conservative.

Adiantum: encryption for the low end

jhoblitt — Thu, 17 Jan 2019 22:29:06 +0000

It took some fiddling around to discover it, but this is the procedure to list the sector size on an existing device. I've poked at several systems and at least as of f28, the install wizard doesn't seem to be changing the default sector size.

```
$ sudo dmsetup ls --target crypt
luks-4b88e721-274f-44de-8668-c1bda37ee74b (253, 0)
luks-8ec7f0a1-5670-400c-9b0e-809cf65aa09d (253, 4)
$ sudo cryptsetup status luks-8ec7f0a1-5670-400c-9b0e-809cf65aa09d
/dev/mapper/luks-8ec7f0a1-5670-400c-9b0e-809cf65aa09d is active and is in use.
type: LUKS1
cipher: aes-xts-plain64
keysize: 512 bits
key location: dm-crypt
device: /dev/sda2
sector size: 512
offset: 4096 sectors
size: 1462509568 sectors
mode: read/write
```

There also isn't any mention of setting the sector size in the fedora wiki: https://fedoraproject.org/wiki/Disk_Encryption_User_Guide nor does there appear to be a builtin mechanism to configure it via kickstart but, presumably, it could be done in a `%pre` block.

Is there any reason not change the `crytsetup` default to be 4K?

Adiantum: encryption for the low end

zyzzyva — Thu, 17 Jan 2019 22:02:04 +0000

Yes, the dm-crypt sector size is a creation-time parameter. The default is 512 bytes, but since Linux v4.12 larger sizes are supported. With cryptsetup/LUKS, 4K sectors require cryptsetup v2.0.0+ and using the LUKS2 format. cryptsetup v2.0.6+ supports Adiantum; an example format command with Adiantum is:

cryptsetup luksFormat --type luks2 --sector-size 4096 -c xchacha12,aes-adiantum-plain64 -s 256 <device>

But 4K sectors can be used with other ciphers too.

Meanwhile, fscrypt (which will also support Adiantum in Linux v5.0) has always encrypted file contents in 4K blocks.

Adiantum: encryption for the low end

zyzzyva — Thu, 17 Jan 2019 21:40:31 +0000

Adiantum is not "bad encryption". Not only does it use modern ciphers with 256-bit keys and substantial security margins, but it's also the first wide-block encryption mode in the kernel. Wide-block modes (tweakable super-pseudorandom permutations) are the state of the art in disk encryption research as they protect against a stronger class of adversary than narrow-block modes such as XTS, LRW, and CBC.

Storage encryption in Android is local to the device; by design other devices cannot decrypt the data. This includes SD cards used as "adoptable storage". SD cards used as "removable storage" are actually unencrypted FAT as that is the lowest common denominator among all computers and devices; the availability of a new encryption algorithm on some devices will not change that.

Adiantum: encryption for the low end

faramir — Thu, 17 Jan 2019 19:28:08 +0000

While for this specific use case (encryption of dedicated local storage) the idea of introducing less expensive encryption options is preferable to nothing, I'm worried about how this could bleed into other use cases. We've seen a number of cases where people attack communications systems which allow a choice of encryption options by forcing use of a weak or broken option in order to intercept or modify data. In the world of USB flash drives, in general, we are stuck with the FAT filesystem because that's the only thing that every device can handle. Even low-end devices often have some way to use them with removable storage (USB OTG, microSD cards). I would hate for everyone to use "bad" encryption on such devices just because that was the only option that everyone supported. At a minimum, I hope that vendors continue to ship devices that support all of the options no matter how slow the implementation might be. I would even encourage making the more secure option the default for removable storage when a user requests such device to be formatted securely.

Adiantum: encryption for the low end

zyzzyva — Thu, 17 Jan 2019 18:57:33 +0000

> Does this mean that aes instructions aren't expected to be common up-coming low-end ~armv7 cores but neon is and/or a migration armv8 isn't happening any time soon?

Yes for some markets; many new low-end devices are still being designed and shipped with 32-bit processors like Cortex-A7 that lack AES instructions, and it's unclear when this will change. They do have NEON still. Also even some low-end ARMv8 processors, e.g. Cortex-A53 in some SoCs, lack AES instructions.

> If armv8 isn't going to be common on the low end, at least for android devices, does that mean the google play 2021 64bit app deadline won't apply to some markets?

This is answered in the announcement (https://android-developers.googleblog.com/2019/01/get-you...). The requirement is that apps provide 64-bit versions, not that they cannot provide 32-bit versions; Play will continue to support 32-bit. Also it doesn't apply to apps explicitly targeting Wear OS or Android TV.

Adiantum: encryption for the low end

jhoblitt — Thu, 17 Jan 2019 16:14:51 +0000

If armv8 isn't going to be common on the low end, at least for android devices, does that mean the google play 2021 64bit app deadline won't apply to some markets?

Adiantum: encryption for the low end

jhoblitt — Thu, 17 Jan 2019 16:11:07 +0000

^typo: s/block size/sector size/

Adiantum: encryption for the low end

jhoblitt — Thu, 17 Jan 2019 16:10:16 +0000

Does this mean that aes instructions aren't expected to be common up-coming low-end ~armv7 cores but neon is and/or a migration armv8 isn't happening any time soon?

Adiantum: encryption for the low end

jhoblitt — Thu, 17 Jan 2019 15:59:14 +0000

I don't know if it is realistic to change the block size after the fact I suspect it is a creation time parameter from looking at `man 8 cryptsetup`.

```
--sector-size <bytes>
Set sector size for use with disk encryption. It must be power
of two and in range 512 - 4096 bytes. The default is 512 bytes
sectors. This option is available only in the LUKS2 mode.

Note that if sector size is higher than underlying device hard‐
ware sector and there is not integrity protection that uses data
journal, using this option can increase risk on incomplete sec‐
tor writes during a power fail.

If used together with --integrity option and dm-integrity jour‐
nal, the atomicity of writes is guaranteed in all cases (but it
cost write performance - data has to be written twice).

Increasing sector size from 512 bytes to 4096 bytes can provide
better performance on most of the modern storage devices and
also with some hw encryption accelerators.
```

Adiantum: encryption for the low end

Sesse — Thu, 17 Jan 2019 13:03:40 +0000

> To get good performance some dm-crypt users will need to use 4096-byte sectors rather than the default of 512, but they really ought to be doing so anyway.

Wait, are you saying the default in LUKS is 512? How can I see what I'm using? Can I change it without a luksFormat with --sector-size?

Adiantum: encryption for the low end

zyzzyva — Thu, 17 Jan 2019 03:49:01 +0000

Thanks for reporting on this work! A few clarifications:

> As a replacement, the Adiantum encryption mode was developed

FWIW, we started work on this even before we proposed Speck128-XTS as a faster-to-deploy solution. So it's been in the works for longer than it may seem. Though, naturally development did speed up when it became clear there wouldn't be an interim solution.

> Speck mostly fit the bill, but it turns out that Adiantum is even faster (roughly 30%), so the political issues that made Speck untenable turned out to be a boon for users.

To be clear, Adiantum is only faster on sufficiently long messages; the 30% number is for 4096-byte messages. But that's fine for the intended use cases. To get good performance some dm-crypt users will need to use 4096-byte sectors rather than the default of 512, but they really ought to be doing so anyway.

> The encryption cipher used is XChaCha12, which is a block cipher based on the ChaCha family of stream ciphers.

XChaCha12 is still a stream cipher; it just accepts a longer nonce than ChaCha12.

> Two rounds of XChaCha12

Normally there is just one XChaCha12 invocation per encryption or decryption. There's another to derive subkeys, but that's only needed when setting a new key.

> According to Biggers, this provides a better security margin than HPolyC or AES.

I didn't say exactly that :-) Adiantum and HPolyC both use the same cryptographic primitives: XChaCha12 and AES-256. So their "security margin" under the usual definition (percent of total rounds the best attack doesn't reach) is the same, and can't really be better than XChaCha12's or AES-256's alone. But that's not the only measure of security; for example, slightly more messages can be safely encrypted with the same key with Adiantum than HPolyC, due to the different choice of universal hash function family. (Though, in practice it doesn't matter as the number of messages is extremely large in both cases!)