Comment 8 for bug 922821

This seems to be a bug in ecryptfs-utils.

During init, ecryptfs-utils will look at /proc/crypto to gather the already loaded ciphers. Some of the aes modules are built into the kernel, so those are already picked up from there, however the blowfish cipher isn't built in or auto-loaded by anything in either kernel version.

It's next form of cipher discovery has a map of ciphers and kernel module names in src/libecryptfs/cipher_list.c that contains (among others):

        {"blowfish", "blowfish.ko", 16, 16, 56, 2, 1},

and during init it will loop over this map and look for modules in /lib/modules/`uname -r`/kernel/crypto and see if those .ko files exist. If they do, it presents the cipher name as available. If the .ko doesn't exist in that directory, it doesn't present that cipher as an option.

With the 3.1.x series of kernels, blowfish.ko is present so it's available. With the renames/additions mentioned in comment #1, that specific .ko name isn't present so the cipher isn't available.

Ideally, ecryptfs would be looking at modaliases instead of actual file names, because the 3.2 (and future) kernels still maintain the 'blowfish' modalias on blowfish_generic.ko. The newly added optimized blowfish-x86_64.ko has the same alias as well. That whole list of module names seems fairly stale at this point and should probably either be updated or removed.

I'm reassigning this to ecryptfs-utils for now. The workaround is to modprobe the cipher you want if it isn't already listed before trying to mount an ecryptfs filesystem. Until ecryptfs-utils is updated, any system with a 3.2 or newer kernel will have this issue, so that will shortly include all 3 Fedora releases.