是否有用于 cryptsetup 的加密后端，它要么始终是线程安全的，要么可以以线程安全的方式轻松使用（甚至修改，最好以最少的努力），以简单地测试密钥是否正确？
背景和我尝试过的：
我首先测试是否可以修改 cryptsetup 的源代码以使用 pthread 简单地测试多个密钥。这崩溃了，我相信我最初使用的是 gcrypt。最终，我尝试了 cryptsetup 稳定源中可用的所有后端，发现 openssl 和 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()）是行不通的。