Fidor

Since thor2002ro provided kernel w/ adiantum.ko support (link to Github), I'm posting a guide how I've changed my pools encryption from default AES to Xchacha12. Here are my steps (for potential future users): WARNING: those steps are dangerous. If mistaken one can loose existing data. Be careful and make backups. Be sure you understand what you are doing! 1. Identify which pool are you going to convert root@NAS:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS loop0 7:0 0 557.3M 1 loop /usr loop1 7:1 0 566.2M 1 loop /lib sda 8:0 1 239M 0 disk └─sda1 8:1 1 112M 0 part sdb 8:16 0 119.2G 0 disk └─sdb1 8:17 0 119.2G 0 part /boot sdc 8:32 0 1.9T 0 disk └─sdc1 8:33 0 1.9T 0 part └─sdc1 254:1 0 1.9T 0 crypt /mnt/data-2tb sdd 8:48 0 1.9T 0 disk └─sdd1 8:49 0 1.9T 0 part └─sdd1 254:2 0 1.9T 0 crypt /mnt/raid1-2tb sde 8:64 0 1.9T 0 disk └─sde1 8:65 0 1.9T 0 part └─sde1 254:3 0 1.9T 0 crypt sdf 8:80 0 953.9G 0 disk └─sdf1 8:81 0 953.9G 0 part └─sdf1 254:0 0 953.9G 0 crypt /mnt/data-1tb From now on we will focus on /dev/sdf1 (/mnt/data-1tb). 2. Check status of encryption root@NAS:~# cryptsetup status sdf1 /dev/mapper/sdf1 is active and is in use. type: LUKS2 cipher: aes-xts-plain64 keysize: 512 bits key location: keyring device: /dev/sdf1 sector size: 512 offset: 32768 sectors size: 2000374448 sectors mode: read/write flags: discards 3. Stop the ARRAY/Pools in UI 4a. Either re-encrypt device If HDD contains data which you can't backup, You can try to re-encrypt that device. Be aware that this approach will take a lot of time root@NAS:~# cryptsetup reencrypt --cipher xchacha12,aes-adiantum-plain64 --hash sha256 --key-size 256 /dev/sdf1 Enter passphrase for key slot 0: Progress: 0.1%, ETA 12h31m08s, 998 MiB written, speed 21.7 MiB/s Continue to step 7. 4b. Or destroy and encrypt from scratch Since my pool was empty and I did not have 12h of time, I've decided to destroy my pool and create new one: root@NAS:~# cryptsetup luksFormat --type luks2 --sector-size 4096 --cipher xchacha12,aes-adiantum-plain64 --hash sha256 --key-size 256 /dev/sdf1 WARNING: Device /dev/sdf1 already contains a 'crypto_LUKS' superblock signature. WARNING! ======== This will overwrite data on /dev/sdf1 irrevocably. Are you sure? (Type 'yes' in capital letters): YES Enter passphrase for /dev/sdf1: Verify passphrase: AFAIK Unraid supports only one passphrase for all devices. So use the one you are already using. 5. Create FS on top for new LUKS device Now we need to create btrfs FS (or ZFS). Tricky part is to use the same UUID so UnRaid will find the that device. First we need to extract previous UUID (data-1tb was the pool name - see first step): root@NAS:~# grep UUID /boot/config/pools/data-1tb.cfg diskUUID="c2c18aa0-7e1b-4e6a-baa7-174269eb62e5" The we need to create btrfs FS (which was FS that I used previously): root@NAS:~# mkfs.btrfs -U c2c18aa0-7e1b-4e6a-baa7-174269eb62e5 /dev/mapper/sdf1 btrfs-progs v6.12 See https://btrfs.readthedocs.io for more information. Performing full device TRIM /dev/mapper/sdf1 (953.85GiB) ... NOTE: several default settings have changed in version 5.15, please make sure this does not affect your deployments: - DUP for metadata (-m dup) - enabled no-holes (-O no-holes) - enabled free-space-tree (-R free-space-tree) Label: (null) UUID: c2c18aa0-7e1b-4e6a-baa7-174269eb62e5 Node size: 16384 Sector size: 4096 (CPU page size: 4096) Filesystem size: 953.85GiB Block group profiles: Data: single 8.00MiB Metadata: DUP 1.00GiB System: DUP 8.00MiB SSD detected: yes Zoned device: no Features: extref, skinny-metadata, no-holes, free-space-tree Checksum: crc32c Number of devices: 1 Devices: ID SIZE PATH 1 953.85GiB /dev/mapper/sdf1 Note: If unsure which command to use (which parameters), especially in case of RAID1 pools, create such pool in UI, then search /var/log/syslog files for mkfs.btrfs or zfs commands (grep shcmd /var/log/syslog) 6. Close LUKS device Before we start UnRaid Array again all LUKS devices must be closed root@NAS:~# cryptsetup luksClose sdf1 7. Start ARRAY/Pools in UI 8. Check the status of LUKS device If everything went fine, the device should start and in CLI the following output should be returned: root@NAS:~# cryptsetup status sdf1 /dev/mapper/sdf1 is active and is in use. type: LUKS2 cipher: xchacha12,aes-adiantum-plain64 keysize: 256 bits key location: keyring device: /dev/sdf1 sector size: 4096 offset: 32768 sectors size: 2000374448 sectors mode: read/write flags: discards I'm using Xchacha for over 2 weeks now (I was working on custom kernel previously) without any issues.

I've compiled adiantum.ko kernel module and here are some numbers: Default encryption: root@NAS:/var/log# cryptsetup benchmark --cipher aes-xts-plain64 --key-size 512 # Tests are approximate using memory only (no storage IO). # Algorithm | Key | Encryption | Decryption aes-xts 512b 34.1 MiB/s 35.1 MiB/s AES-512 equivalent in Xchacha20: root@NAS:/var/log# cryptsetup benchmark --cipher xchacha20,aes-adiantum-plain64 # Tests are approximate using memory only (no storage IO). # Algorithm | Key | Encryption | Decryption xchacha20,aes-adiantum 256b 96.7 MiB/s 96.5 MiB/s AES-256 equivalent in Xchacha12 (recommended for old devices/slow (ARM) CPU such as ones used in NASes): root@NAS:/var/log# cryptsetup benchmark --cipher xchacha12,aes-adiantum-plain64 # Tests are approximate using memory only (no storage IO). # Algorithm | Key | Encryption | Decryption xchacha12,aes-adiantum 256b 117.7 MiB/s 117.8 MiB/s So we can have 3-4 times performance improvements just by adding extra module to the kernel: CONFIG_CRYPTO_ADIANTUM=m

Hi, I'm setting unRaid on ReadyNAS 314 and I'm trying to configure LUKS2 on selected pools. Since the CPU on NAS does not support AES-NI the default AES ciphers are pretty slow. Exactly for that reason the xchacha12 and aes-adiantum-plain64 were created. While being secure those algorithms provides significant performance boost. As I'm not afraid of using CLI, so here is my feature request: Please add the adiantum.ko to kernel modules. [ Adding UI allowing to select encryption algos when creating encryption pool would be a nice touch but I suspect this would increase the amount of work. ] Best regards, Adam