GnuPG具有迭代+盐化S2K形式的内置慢速哈希。

与bcrypt或scrypt相比是否有缺点？ GnuPG的慢散列方法是否可以在GPU中轻松实现自动化？

#1 楼

OpenPGP的“迭代和加盐S2K”只是一个很长输入上的单个哈希实例，其中包括盐和密码的重复连接。这对GPU非常友好，尤其是在使用基于32位基本操作构建的哈希函数时（此类别包括MD5，SHA-1，SHA-256和RIPEMD-160； GPU不擅长处理64-位操作，例如SHA-512）。因此，当尝试攻击使用该密钥派生功能处理的密码时，攻击者将从GPU中获得很好的提振。内部结构差异很大，它们在硬件上具有相似的使用模式。相比之下，bcrypt和scrypt需要更快的访问RAM，这使GPU处于劣势。 Bcrypt仍然可以容纳数千KB的RAM，因此仍然易于通过FPGA进行优化。 scrypt看起来更好，但是因为它是新的而显得闪亮，这在密码系统中不是一件好事（就像好酒一样，好的加密必须等待几年才能获得最佳质量；有关更详尽的讨论，请参见此答案）。 />
让我强调一下，实际上，OpenPGP的S2K（或PBKDF2）很少是给定系统中最薄弱的部分。尽管存在所有缺点，但S2K优于简单的不带盐的非迭代哈希，最好是未加盐的哈希调用，这在已部署的应用程序中仍然很常见。

评论

$ \ begingroup $
只是一些琐事，但请注意，支持64位算术（最新的）的GPU仍然非常快-在最坏的情况下，它比32位算术慢4倍，通常接近2倍。使用128位算术进行的哈希运算对于GPU的处理将更加痛苦，因为必须执行的一般进位操作无法很好地映射到SIMD向量指令（这使得对压缩函数进行向量化更加困难）。
$ \ endgroup $
–托马斯
2012年7月17日在7:20


$ \ begingroup $
不幸的是，只要软件工程仍然是未经许可的职业，并且不会因犯错而受到刑事处罚，我认为我们将继续看到无盐散列甚至原始密码存储。
$ \ endgroup $
–RomanSt
2012年10月10日23:15


$ \ begingroup $
@Thomas是否有甚至使用128位算术的哈希？
$ \ endgroup $
–森林
18年4月22日在8:37

#2 楼

大多数哈希函数（似乎包括S2k）都不占用大量内存。这样，您可以非常便宜地在GPU上运行其迭代变量的大量计算。

但是，Scrypt被设计为占用大量内存的，因此，如果没有巨大的内存需求，就无法真正有效地并行运行它。