CONFIG_CRYPTO_SERPENT is not enabled

[Aegeontis]

Describe the bug

The serpent encryption algorithm is not supported in the kernel.

Steps to reproduce the behaviour

1. cryptsetup benchmark
2. Results for serpent are N/A

Device (s)

Raspberry Pi 4 Mod. B

System

$ cat /etc/rpi-issue
Raspberry Pi reference 2023-05-03
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 7c750947a959fb626a70c09fd17c65815df192ac, stage2

$ vcgencmd version
Mar 17 2023 10:50:39 
Copyright (c) 2012 Broadcom
version 82f3750a65fadae9a38077e3c2e217ad158c8d54 (clean) (release) (start)

$ uname -a
Linux mainserver 6.1.74-v8+ #1 SMP PREEMPT Sun Jan 28 01:30:24 UTC 2024 aarch64 GNU/Linux

Logs

No response

Additional context

I am not entirely sure why the algorthm is disabled. I can reasonably come up with 2 options:

1. Its too slow due to not being properly supported on the hardware side
2. It doesnt work at all on some devices

To test both, I have created https://github.com/Aegeontis/rpi-linux-serpent. The repo compiles the kernel in exactly the same way as the upstream one, except enabling serpent support. I installed the compiled kernel from that repo (arm64 on rpi4) and everything works fine. Speeds are acceptable.

[popcornmix]

We generally don't enable everything. There is some cost to enabling a module. What is the size of the serpent module produced? (note that gets multiplied up by the different kernel configurations for different Pi models).

If the size is non-trivial, and the number of users who actually use it is tiny, then you can consider adding a module to be taxing all users, for the few who benefit.

Can you describe how having this module available benefits Pi users? What is your use case, and how is using serpent preferable to using other (currently available) crypto options?

[Aegeontis]

We generally don't enable everything.

Makes sense, the lib + kernel sizes are pretty small (although that might be just arm)

What is the size of the serpent module produced?

Setting CONFIG_CRYPTO_SERPENT=m adds exactly one file: modules/version/kernel/crypto/serpent_generic.ko. Below are the sizes of that file in each build.

arm64_build: 120288 bytes
bcm2709_build: 6812 bytes
bcm2711_arm64_build: 7716 bytes
bcm2711_build: 6836 bytes
bcm2712_build: 7724 bytes
bcm2835_build: 219052 bytes
bcmrpi_build: 7036 bytes

What is your use case, and how is using serpent preferable to using other (currently available) crypto options?

The other available options on rpi are twofish and aes. Serpent is special due to being the strongest algorithm out of all 3 (aes, twofish, serpent). It is also the slowest and the least used, which makes it less appealing to potential crackers.
In my use case specifically, I want to make sure that if my encrypted data ever gets leaked, it wont be cracked, even in 10,20,30 years.

[popcornmix]

arm64_build: 120288 bytes

The name and size of this line seems out of line with other values (which are modestly sized).

Can you confirm exactly what that is measuring?

[Aegeontis]

I agree, it is odd that the arm64_build's serpent_generic.ko is much bigger than the others. I have double checked and the size is correct. You can however check for yourself here: https://github.com/Aegeontis/rpi-linux-serpent/actions/runs/7696189399/artifacts/1202440509

I triggered another run of the github action to see if its consistent: https://github.com/Aegeontis/rpi-linux-serpent/actions/runs/7697361282

[Aegeontis]

The results of the new build run are the same, the serpent module for the arm64_build is still 120288 bytes