Twofish-cbc-essiv:sha256 missing after upgrade

Hi All,

After recent upgrade (apt full-upgrade) am now on kernel 5.10.78-2-osmc only to discover that support for twofish-cbc-essiv:sha256 is missing.
This is required to open my Luks volume with cryptsetup.

The other messages interesting are:

# Not enough physical memory detected, PBKDF max memory decreased from 1048576kB to 471722kB.
# PBKDF argon2i, hash sha256, time_ms 2000 (iterations 0), max_memory_kb 471722, parallel_threads 4.

# Userspace crypto wrapper cannot use twofish-cbc-essiv:sha256 (-2).

I’d prefer to avoid re-encrypting drive.

cryptsetup shows this:

# cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1       150484 iterations per second for 256-bit key
PBKDF2-sha256     234475 iterations per second for 256-bit key
PBKDF2-sha512     165494 iterations per second for 256-bit key
PBKDF2-ripemd160  127501 iterations per second for 256-bit key
PBKDF2-whirlpool   24417 iterations per second for 256-bit key
argon2i       4 iterations, 76276 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
argon2id      4 iterations, 86759 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
#     Algorithm |       Key |      Encryption |      Decryption
        aes-cbc        128b        27.4 MiB/s        48.2 MiB/s
    serpent-cbc        128b               N/A               N/A
    twofish-cbc        128b               N/A               N/A
        aes-cbc        256b        23.9 MiB/s        35.4 MiB/s
    serpent-cbc        256b               N/A               N/A
    twofish-cbc        256b               N/A               N/A
        aes-xts        256b        52.4 MiB/s        47.1 MiB/s
    serpent-xts        256b               N/A               N/A
    twofish-xts        256b               N/A               N/A
        aes-xts        512b        41.2 MiB/s        35.9 MiB/s
    serpent-xts        512b               N/A               N/A
    twofish-xts        512b               N/A               N/A

Did I miss something? I can’t find modules for this kernel and only what could find is under old kernel:

 find /lib -iname *twofish*

Any help is very welcome.

p.s. I’ve been always on OSMC kernel and also found some notes that default Raspberry Pi kernels didn’t seem to have twofish - so whilst disappearance is weird, it would be great to have it re-enabled. I’d prefer to avoid re-compiling kernel or re-encrypting data, as it would mean transferring somewhere TBs of data, only to reformat disk and transfer it back.

Happy to accept a PR to re-add this. Alternatively, let me know CONFIG options needed.


@sam_nazarko - thank you, appreciate help.

I’ll see how to submit PR.
Looking through kernel options, it looks like only the two are needed, but am not 100% sure. The rest of twofish ones in kernel config seems to be x86_64, hence not applicable to us.
I have to admit that without having this enabled I can’t for sure say if this will bring back functionality to life or if some other dependent module has been removed too.

	tristate "Twofish cipher algorithm"
	  Twofish cipher algorithm.

	  Twofish was submitted as an AES (Advanced Encryption Standard)
	  candidate cipher by researchers at CounterPane Systems.  It is a
	  16 round block cipher supporting key sizes of 128, 192, and 256

	  See also:

	  Common parts of the Twofish cipher algorithm shared by the
	  generic c and the assembler implementations.

PR created: PR/RFE: twofish-cbc-essiv:sha256 - ask to get it back into kernel for cryptesetup/luks volume support · Issue #681 · osmc/osmc · GitHub

Thank you!

@sam_nazarko , would you mind to point me to where I could read how to raise PR? Github PR/RFE in subject is raised, but seems like it is not what’s needed as PR. Did quick check but can’t find a description.


Ok, did my reading :wink: created fork, tried and failed to compile everything within privileged docker, moved to VM, compiled.
Then got stuck with… best way to test and re-compile without building everything from scratch each time.

So a little bit of digging how scripts works and it was ok’ish (not sure if done the right way).
Mounted (bind) folders as script does and did chroot to toolchain (as compiled on x86_64 for armv7).

PR is here:

p.s will cross post to RFE/PR as raised on Github for completeness.

Thank you for help.

I’ve now merged this.

I’d appreciate it if you could test this and provide feedback before we potentially release this as an update to other users. To test this update:

  1. Login via the command line
  2. Run the following command to add the staging repository:
    echo 'deb buster-devel main' | sudo tee /etc/apt/sources.list.d/osmc-devel.list
  3. Run the following commands to update: sudo apt-get update && sudo apt-get dist-upgrade && reboot
  4. Your system should have have received the update.

Please see if the issue is resolved.

I also recommend you remove /etc/apt/sources.list.d/osmc-devel.list after updating.

I’d also recommend you deactivate the staging repository. You can do so with the following command:
sudo rm /etc/apt/sources.list.d/osmc-devel.list.

Please note that we will automatically disable this update channel after 14 days on your device in case you forget to do so to ensure that your system reverts to the stable update channel.

Thanks again for integrating this PR. I’ll not be able to test it over next days as am in process of re-transmitting backup to off-site due to earlier disk mis-behavior.

Once finished I can do that.