Hi,
why is serpent-xts crypto cipher NOT included in the ARM kernel (module xts)?
I understand that builds for ARM strive to be compact, but serpent is a very good cipher and competes with aes, especially on a platform (ARM) which does not include anything like Intel’s aes-ni extension, which only accelerates aes cipher OPS.
Would it be an option to include it in the future?
It appears to be in the pi4 kernel.
mmmm then it’s one of the serpent modules. I am talking about the pi4 kernel, actually.
xts is actually there, but not for serpent:
$ cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1 403298 iterations per second for 256-bit key
PBKDF2-sha256 647269 iterations per second for 256-bit key
PBKDF2-sha512 506069 iterations per second for 256-bit key
PBKDF2-ripemd160 334367 iterations per second for 256-bit key
PBKDF2-whirlpool 125307 iterations per second for 256-bit key
argon2i 4 iterations, 291278 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
argon2id 4 iterations, 174720 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
# Algorithm | Key | Encryption | Decryption
aes-cbc 128b 74.7 MiB/s 74.7 MiB/s
serpent-cbc 128b N/A N/A
twofish-cbc 128b 54.9 MiB/s 52.5 MiB/s
aes-cbc 256b 60.5 MiB/s 59.4 MiB/s
serpent-cbc 256b N/A N/A
twofish-cbc 256b 54.4 MiB/s 57.2 MiB/s
aes-xts 256b 89.4 MiB/s 90.8 MiB/s
serpent-xts 256b N/A N/A
twofish-xts 256b 64.2 MiB/s 62.1 MiB/s
aes-xts 512b 69.2 MiB/s 70.0 MiB/s
serpent-xts 512b N/A N/A
twofish-xts 512b 64.2 MiB/s 62.0 MiB/s
I searched for module xts you specified above. I searched again just now for serpent and it is not enabled. I will enable it in the next kernel compile.
thanks!
Great a new cipher for the kernel !
Do you know any software/middleware/process that use it ?
Yeah, actually having a reason to enable it (other than a benchmark tool), would be great. 
The reason is that I do use serpent-xts-512 as the cipher for my LUKS partitions (I have an i7/950, without aes-ni, so I don’t see a reason to use aes).
When I try to use those partitions on my raspi, I simply can’t, because serpent-xts is not there either as built-in or as module.
The “benchmarking tool” was used to demonstrate that that cipher is not in…
So it’s something you use.
Which seems to be out the norm/defaults for most distros.
I like to be special.
The fact is that I need to have a way to use it, even as a module, otherwise I need to build my own kernel.
We could probably build it as a module, like X64 does.
It seems SERPENT_AVX (which implies CRYTPO_XTS) is an x86_64 only thing…
So while we have both SERPENT and XTS enabled in the kernel, we won’t get SERPENT_XTS.
Hi, sorry for the late answer.
I can confirm that I am able to mount on my Raspi4 my external drives, LUKS-encrypted this way on my x86_64 machine:
cryptsetup luksFormat -s 512 --cipher serpent-xts-plain64 /dev/whatever
I don’t know what that “depends on” in the source file actually means.
It works on aarch64
The AVX is the x86_64 only part. The serpent-xts-plain works cross-platform, and is indeed a very fast cipher for machines without AES hardware instructionset.
CRYPTO_XTS is already enabled in our kernel.