Re: Adiantum and integrity safe?

On 15.05.2019 08.38, Milan Broz wrote:
> On 14/05/2019 12:17, Kristian Klausen wrote:
>> I have a weak Intel Atom(N450) server and three external HDDs. I want to use the HDDs in RAID 5 with encryption  and integrity[1].
>>
>> The Atom CPU is rather weak:
>> #           Algorithm |  Key |  Encryption |  Decryption
>> aes-xts                  256b    36.5 MiB/s   37.0 MiB/s
>> xchacha12,aes-adiantum   256b    83.4 MiB/s   84.3 MiB/s
>> So I want to use Adiantum, is it safe to combine them?
>> Ex[2][3]: cryptsetup luksFormat --type luks2 <device> --cipher xchacha12,aes-adiantum --integrity poly1305
> Hi,
>
> this combination will not work.
>
> Adiantum is fast, but integrity checking will slow it down, so these requirements are going againts themselves.
>
> But thew problem is technical here:
>
> - the proper parameter is "--cipher xchacha12,aes-adiantum-IV" (IV is plain64 for non-integrity mode,
> but should be random for integrity protection modes)
>
> - the "poly1305" authenticator is intended to be used with chacha20 through RFC7539 wrapper,
> so it will try to wrap Adiantum using the RFC7539 and it is not supported.
> (Cipher test will return fail because constructed kernel cipher string is not supported.)
>
> (The intended use was --cipher chacha20-random --integrity poly1305, but it will be quite slow here.)
>
> - You should be able to use Adiantum with other authentication tags (like --integrity hmac-sha256)
> but it will be slow on Atom.
Thanks for the very thorough answer.

I just did some benchmarking*:
aes-xts-plain64                                        | 17,8 MB/s
xchacha12,aes-adiantum-plain64                         | 22,5 MB/s
xchacha20,aes-adiantum-plain64                         | 24,6 MB/s
xchacha20,aes-adiantum-plain64 --integrity hmac-sha256 | 7,3 MB/s 
(around the same with --integrity-no-journal)
As you can see the Atom is weak.

I also tried plain integrity:
with journal    | 11,2 MB/s
without journal | 32 MB/s without journal
without journal and xchacha20,aes-adiantum-plain64 ontop | 19,1 MB/s

I'm not sure how costly RAID-5 is, so it could be even worse.
So I'm probably going with either dm-integrity -> mdraid or dm-integrity 
-> mdraid -> dm-crypt.

*:
truncate -s 500M disk1.img
dd if=/dev/urandom of=key.bin bs=512 count=1

sudo cryptsetup luksFormat -q --type luks2 --cipher <cipher> disk1.img 
key.bin
sudo cryptsetup luksOpen disk1.img disk1luks --key-file key.bin

# integrity only
#sudo integritysetup format disk1.img
#sudo integritysetup open disk1.img disk1integrity
#sudo dd if=/dev/zero of=/dev/mapper/disk1integrity bs=1M oflag=direct 
status=progress

# crypt ontop
#sudo cryptsetup luksFormat -q --type luks2 --cipher 
xchacha20,aes-adiantum-plain64 /dev/mapper/disk1integrity key.bin
#sudo cryptsetup luksOpen /dev/mapper/disk1integrity disk1luks 
--key-file key.bin

sudo dd if=/dev/zero of=/dev/mapper/disk1luks bs=1M oflag=direct 
status=progress
>
> If you do not need authenticated encryption, but just add crc32 integrity checking, maybe stacking
> RAID over dm-integrity (using integritysetup) will work better (with optional LUKS layer on top using
> fast Adiantum cipher).
>
> There are currently some experiments with new bitmap mode in dm-integrity (will be supported by next
> integritysetup) that are intended exactly for this RAID stacking scenario, but it is not stable yet.
>
>
> Milan
>
>
>> [1] https://gist.github.com/MawKKe/caa2bbf7edcc072129d73b61ae7815fb
>> [2] https://mirrors.edge.kernel.org/pub/linux/utils/cryptsetup/v2.0/v2.0.0-ReleaseNotes
>> [3] https://mirrors.edge.kernel.org/pub/linux/utils/cryptsetup/v2.0/v2.0.6-ReleaseNotes
>>
>> Regards
>> Kristian Klausen
>>
>> _______________________________________________
>> dm-crypt mailing list
>> [email protected]
>> https://www.saout.de/mailman/listinfo/dm-crypt
>>
Kristian
_______________________________________________
dm-crypt mailing list
[email protected]
https://www.saout.de/mailman/listinfo/dm-crypt