crickyx@helios4:~$ zgrep -iE "xts|aes" /proc/config.gz
The important modules are compiled in (don't need to be loaded). So, this tells me that a reboot shouldn't be needed. Still don't know why a reboot "fixes" it.
today I tried to install OMV 4.x with the latest
The installation log inside the browser says:
- Setting up cryptsetup-bin (2:1.7.3-4) ...
- Processing triggers for man-db (22.214.171.124-2) ...
- Processing triggers for openmediavault (4.1.19-1) ...
- >>> *************** Error ***************
- Invalid RPC response. Please check the syslog for more information.
- <<< *************************************
- Restarting engine daemon ...
- Setting up cryptsetup (2:1.7.3-4) ...
The syslog does not show anything that might be helpful.
No HDD shows up when trying to setup encryption via the GUI.
Of course I could use cryptsetup and luksformat myself, but this is something OMV might not like at all and will not get notified of. To get all properly working inside the GUI would be the best.
In the past this plugin worked great, but due to the installation error I am stuck at the moment.
If you are in need of more information I would be glad to help.
I am a absolutely Tech noob, so pls excuse my dumb question.
My Qestion is:
How can i lock the hdd, after formating and mounting it ? I know that, when i unmount it, i can lock it again. But it is the only way ?
I would be thankful for your help .
Hi, I was going to rise an issue (improvement request) on the LUKS Plugin github, but I guess it's better to first discuss it here.
Some ARM based boards have hardware encryption acceleration engine, it is the case of the Helios4 board based on the Marvell Armada388 that has CESA engines. However those hardware encryption engines are limited in which cipher they do support. CESA does not accelerate aes-xts-plain64 cipher which is the default cipher for LUKS and actually I don't think there is any SoC out there that can accelerate XTS.
For user to enjoy hardware encryption acceleration provided by CESA engine they should choose chiper aes-cbc-essiv:sha256 for their disk encryption.
Could we imagine an advance settings where user can choose the cipher when creating encrypted device on OMV ? Limited to 2 choices :
- aes-xts-plain64 (default)
I created a dirty patch for people to hard code in your plugin the right cipher in the case of Helios4. I could try to create the feature describe above, but I need to understand how the OMV plugin framework works first
Here a cryptsetup benchmark run on Helios4 and you could see that user can enjoy a significant boost by choosing the right cipher.
- # Tests are approximate using memory only (no storage IO).
- PBKDF2-sha1 201959 iterations per second for 256-bit key
- PBKDF2-sha256 257508 iterations per second for 256-bit key
- PBKDF2-sha512 162217 iterations per second for 256-bit key
- PBKDF2-ripemd160 175464 iterations per second for 256-bit key
- PBKDF2-whirlpool 23523 iterations per second for 256-bit key
- # Algorithm | Key | Encryption | Decryption
- aes-cbc 128b 101.9 MiB/s 104.9 MiB/s
- serpent-cbc 128b 24.6 MiB/s 32.0 MiB/s
- twofish-cbc 128b 39.0 MiB/s 44.4 MiB/s
- aes-cbc 256b 92.2 MiB/s 94.6 MiB/s
- serpent-cbc 256b 25.2 MiB/s 32.0 MiB/s
- twofish-cbc 256b 39.7 MiB/s 44.4 MiB/s
- aes-xts 256b 62.0 MiB/s 55.7 MiB/s
- serpent-xts 256b 29.4 MiB/s 31.9 MiB/s
- twofish-xts 256b 43.1 MiB/s 44.4 MiB/s
- aes-xts 512b 48.2 MiB/s 41.7 MiB/s
- serpent-xts 512b 29.7 MiB/s 31.9 MiB/s
- twofish-xts 512b 43.5 MiB/s 44.3 MiB/s
More benchmark here
github.com/OpenMediaVault-Plug…e/luks/container.inc#L347. It wouldn't be hard to add one.
If I add a list of ciphers, I would add all that are supported but a note could mention other things. Are there any boards that support a different cipher? I don't want to make a change just for the helios.
I did a bit of research and most ARM SoC have crypto engine
The basic features of their encryption and decryption engine are :
AES 128/192/256 key mode
ECB/CBC chain mode
SHA-1, SHA-256, and MD5 hash func
Actually I found that some last gen ARM SoC familly even support XTS chain mode. But overall I think most ARM SoC would get better performance by using aes-cbc-essiv:sha256 instead of aes-xts-plain64.
I would recommend however to leave aes-xts-plain64 as the default and let user choose explicitly the other cipher if needed. Up to the board developer to advertise such improvement tweaks