bcrypt与这些哈希函数不同，因为Blowfish是一种分组密码，为了产生一种哈希，使用了“反馈”。对GPU平台不太熟悉。有人知道bcrypt是否可以移植到GPU上吗？为什么？
#1 楼
这不是不可能，只会更加困难。这是由于RAM。在GPU中，您具有许多可以执行32位运算的核心。只要它们在各自的寄存器上运行，它们将在每个周期和每个内核一次运行。但是，RAM访问更麻烦。每组内核都可以访问少量共享RAM，并且所有内核都可以读写GPU主RAM，但是存在访问限制：并非所有内核都可以同时读写RAM（对主RAM的约束更加严格）。现在，bcrypt是Blowfish密钥调度的一种变体，它是在一个表（几千字节）上定义的，该表在整个算法中不断地被访问和修改。由于表的大小，每个内核都必须将其存储在GPU主RAM中，并且它们将争用内存总线。因此bcrypt可以运行-但不能完全并行。任何时候，大多数内核都会停滞，等待内存总线变为空闲状态。这来自bcrypt所包含的基本运算的类型，而不是bcrypt源自分组密码的密钥调度这一事实。对于SHA-1或SHA-256，计算完全包含在其中在少数几个寄存器上进行32位操作，因此密码破解程序将完全不进行任何内存访问就可以运行，并且完全可以实现完全并行（我在我的GeForce 9800 GTX +上做到了，我得到了理论最大值的98％通过直接展开的SHA-1实现提高速度）。
有关CUDA中编程模型的详细信息，请参阅《 CUDA C编程指南》。而且，bcrypt的作者现在提出了scrypt（编辑：实际上不是同一个人； scrypt的作者是Colin Percival，而bcrypt由Niels Provos和DavidMazières设计），确切地说，在内存访问上甚至更重因此很难在GPU和FPGA上实现。
评论
$ \ begingroup $
scrypt非常酷！您如何看待使用硬存储算法进行密钥派生和密码存储？如果我没有记错的话，PBKDF2很难操作，因此对于使用GPU或FPGA进行破解来说是最佳选择。
$ \ endgroup $
–浏览
11年8月13日在7:37
$ \ begingroup $
因此，每个内核具有自己的4 KB（快速）内存的专用硬件实现对bcrypt来说是好的，不是吗？ （当然，不用于scrypt。）
$ \ endgroup $
–PaŭloEbermann
11年8月13日在15:57
$ \ begingroup $
@Rook：我们想要的是一种密码处理算法，它对于攻击者而言应尽可能慢，对于“诚实用户”则应尽可能快。因此，针对诚实用户将使用的软件对其进行优化是有意义的，这是一台具有通用CPU的PC（或类似产品），它非常擅长访问大量RAM。所以是的，内存硬算法是个好主意-当然，直到您的目标系统之一是内存受限的嵌入式系统为止。
$ \ endgroup $
–托马斯·波宁（Thomas Pornin）
11年8月13日在16:06
$ \ begingroup $
@Paulo：是的，具有快速嵌入式RAM块的专用硬件对于bcrypt应该是有效的。较新的FPGA（例如Xilinx的Virtex 5）具有此类RAM模块；这是Percival认为bcrypt不够内存的原因，因此设计了scrypt的原因。
$ \ endgroup $
–托马斯·波宁（Thomas Pornin）
11年8月13日在16:08
$ \ begingroup $
当您说“每个内核组都可以访问少量共享RAM”时，我们实际上是在谈论多少RAM？数量少于典型处理器的L2缓存吗？
$ \ endgroup $
–大卫·佩里（David Perry）
2011-10-11 17:58
#2 楼
现在已经为GPU和FPGA实施了bcrypt。看到Bcrypt密码破解非常慢吗？如果您使用数百个FPGA，那就不行！。那里描述的GPU实现仅比CPU实现快。但是，FPGA实施更具成本效益，并且功耗降低了一个数量级。但是到目前为止，它似乎只能在不连续的FPGA板上运行。
特别是，首先，他们比较了两个成本都在千美元左右的系统：一个CPU（AMD EPYC 7401P-24核，3.0） GHz），高端GPU（Nvida RTX-2080Ti）。对于使用工作因子12（2 ^ 12哈希）的bcrypt来说，两者都非常慢，例如197 vs 219哈希/秒。
但是FPGA实现（使用来自Ripper的杰克的开源代码）可以在单个ZTEX 1.15y板上完成约一千个工作因数12哈希/秒，仅使用3-5％的功率。
评论
有一阵子我误读了“ Cuda”为“ Cuba”，并认为这是一个加密导入问题。