Support for Serpent-XTS crypto?


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.


:smiley: 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. :slight_smile:

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. :slight_smile:

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 :slight_smile:

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.