cryptsetup: cannot open veracrypt volumes (but works with cryptsetup-openssl)

[allthesebugs]

Maintainer: @dangowrt (I think?) Environment: Linux LEDE 4.14.105 #0 SMP Thu Mar 14 21:55:06 2019 armv7l GNU/Linux (Linksys wrt1900ACS)

Unfortunately the package cryptsetup-openssl has been deprecated: https://git.openwrt.org/?p=feed/packages.git;a=commit;h=4815585a3bda9c4fc69782103f19cf8dbffb94e6

However this package is the only one being able to open volumes encrypted with VeraCrypt. Using cryptsetup-openssl in the last included version (2.0.5) I get the following output: https://pastebin.com/8f3igJMc

However, using the non-openssl variant (version 2.1.0), the output looks like this: https://pastebin.com/61JiEju9

As you can see it uses only one try for finding the correct hashing algorithm and then immediately fails. So I would ask to either bring back cryptsetup-openssl or help me figure out what is wrong here. Thanks!

[diizzyy]

It's probably because (without looking at the code) that the kernel supports a lot less algorithms than OpenSSL. While I understand your issue it boils down to how to handle out of tree "packages". Veracrypt has never been a part of the OpenWrt package repo and "breaking" compatibilty isn't a violation as it's unreasonable to expect someone to account for all possible unknown scenarios. I think that most reasonable approach would be to convert your storage to a supported variant and/or import veracrypt and friends but it does seem a bit redundant these days.

[allthesebugs]

You make a fair point. But unfortunately as it is Veracrypt is still the go-to open source software for full disk encryption on Windows (and also works fine on MacOS and Linux). Since cryptsetup claims to support Veracrypt shouldn't the OpenWrt package reflect that?

[diizzyy]

That depends on your viewpoint. The majority of devices that runs OpenWrt are "dinky" MIPS or older PPC boxes with limited space and processing power so usually size is prioritized over performance and features however it's a trade-off as both x86 and ARM can be powerful enough to cope with "heavy" crypto loads. There are cases where you might want a small encrypted storage on a "dinky" device while not pulling rather large dependencies while it might not be much of an issue on ARM and x86.

You might be able to get it going if you know the algorithms used for your storage device and add those to the kernel.

[neheb]

Interesting fallout...

The actual solution here would be to create kernel support for this. crypto/tcrypt.c has support for TrueCrypt but no VeraCrypt. under cryptsetup's lib/tcrypt/tcrypt.c, there is veracrypt support.

This errors on

TCRYPT: trying KDF: pbkdf2-ripemd160-2000.

try running cryptsetup --benchmark and see if it shows up. If it doesn't, you might be missing a kernel module or two.

edit: The more I think about it the more I believe it to be missing kernel modules. The XTS one is also needed here.

[allthesebugs]

Running cryptsetup benchmark gives the following output: https://pastebin.com/4qA5PViZ

While there is PBKDF2-ripemd160, pbkdf2-ripemd160-2000 is indeed missing.

So you're saying that my kernel lacks a few modules which should be there in a standard OpenWrt installation?

[neheb]

No. you need to install them.

opkg update opkg install kmod-crypto-whatever

[allthesebugs]

Shucks, of course I made that benchmark with my local cryptsetup-openssl copy. When I use the current non openssl version these are the results: https://pastebin.com/VVJRs9JW

As you can see the PBKDF2-ripemd160 algorithm is missing completely. Also, I am not able to figure out which kmod-crypto package I could install to remedy this.

[neheb]

Oh hey what do you know. It's not included. If you compile your own builds, can you test this patch?

diff --git a/package/kernel/linux/modules/crypto.mk b/package/kernel/linux/modules/crypto.mk
index 8756aae282..4d15739391 100644
--- a/package/kernel/linux/modules/crypto.mk
+++ b/package/kernel/linux/modules/crypto.mk
@@ -581,6 +581,17 @@ endef
 $(eval $(call KernelPackage,crypto-pcompress))

+define KernelPackage/crypto-rmd160
+  TITLE:=RIPEMD160 digest CryptoAPI module
+  DEPENDS:=+kmod-crypto-hash
+  KCONFIG:=CONFIG_CRYPTO_RMD160
+  FILES:=$(LINUX_DIR)/crypto/rmd160.ko
+  AUTOLOAD:=$(call AutoLoad,09,rmd160)
+  $(call AddDepends/crypto)
+endef
+
+$(eval $(call KernelPackage,crypto-rmd160))
+
 define KernelPackage/crypto-rsa
   TITLE:=RSA algorithm
   DEPENDS:=+kmod-crypto-manager +kmod-asn1-decoder

[allthesebugs]

Unfortunately I do not compile my own builds; I could ask the guy who maintains the build I use whether he'd be willing to test this patch though. The change should be obvious when running cryptsetup benchmark, right? I.E. RIPEMD160 should be available?

[neheb]

I tested this with cryptsetup benchmark. It shows up. I've also submitted upstream. Should make it in soon.

Thanks for reporting btw.

PBKDF2-sha1          N/A
PBKDF2-sha256      62415 iterations per second for 256-bit key
PBKDF2-sha512      27397 iterations per second for 256-bit key
PBKDF2-ripemd160   37882 iterations per second for 256-bit key
PBKDF2-whirlpool     N/A

[allthesebugs]

Thank you very much for the help! I do appreciate it a lot!

So I guess I'll close this

[neheb]

@allthesebugs merged. Please retest tomorrow or whenever.

[allthesebugsv2]

Sorry it took me so long but I've been away (and lost my account details in the mean time).

Unfortunately it is not working for me; there are still no benchmark results for ripemd160 and I cannot mount my volumes. I have installed the kmod for ripemd160:

root@LEDE:~# opkg list |grep RIPE
kmod-crypto-rmd160 - 4.14.111-1 - RIPEMD160 digest CryptoAPI module

The build is from the 20th of April; it is also not working the build maintainer.

[neheb]

Maybe cryptsetup needs an update :man_shrugging:

I tested a local compile FWIW.

[allthesebugsv2]

I am using version 2.1.0 of cryptsetup. Is there a more recent version? Sorry if I am bit thick but I am not sure I understand where the problem lies...