是否存在cryptsetup的加密后端，它既可以是线程安全的，也可以以线程安全的方式轻松使用（甚至可以轻松修改，最好以最小的努力），以便简单地测试密钥是否正确？
背景和我尝试的内容：
我开始测试是否可以修改cryptsetup的源代码，以便使用pthreads简单地测试多个密钥。这个崩溃了，我相信我最初使用过gcrypt。最后我尝试了cryptsetup稳定源中的所有后端，发现openssl和nettle似乎可以避免崩溃。
但是，我的测试不是很彻底，即使它（特别是nettle）没有崩溃，它似乎在使用线程时无法正常工作。当使用单个线程时，它始终有效，但增加线程数使得它越来越不可能无声地找不到正确的密钥。
这适用于强制LUKS设备。我知道pbkdf将它减慢到爬行速度。我也意识到即使KDF不存在，AES的密钥空间也不会耗尽。这只是为了以网络分布式和多线程方式实现它的乐趣。
我注意到cryptsetup（libdevmapper.c）的来源：
/*
* libdevmapper is not context friendly, switch context on every DM call.
* FIXME: this is not safe if called in parallel but neither is DM lib.
*/
但是，我可能没有正确使用它。
if(!LUKS_open_key_with_hdr(CRYPT_ANY_SLOT, key, strlen(key), &cd->u.luks1.hdr, &vk, cd)) {
return 0;
}
每个工作线程都这样做。我只在工作线程启动之前调用crypt_init（）和crypt_load（）一次，并将它们自己的struct crypt_device的单独副本传递给它们。每次尝试都会在本地创建vk。这些密钥只是从具有互斥锁访问控制的单词列表中获取。我发现如果每个线程每次调用这些函数（crypt_init和crypt_load），它似乎更容易崩溃。
尝试开始删除和重写使用dmcrypt的代码是否完全不正确？在LUKS_endec_template（）中，它将一个循环设备附加到加密设备，并创建一个dm设备，它最终提供给open（），然后它将fd提供给read_blockwise（）。我的想法是简单地跳过所有这些，因为我不需要使用设备，除了验证密钥。但是，只是直接打开加密设备（并将其提供给read_blockwise（））不起作用。