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

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

 

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.