我正在读一本关于HashMap hashing functions的Rust书，我无法理解这两句话。
默认情况下，HashMap使用加密安全散列函数，可以抵御拒绝服务（DoS）攻击。这不是最快的哈希算法，但是随着性能下降而带来更好的安全性的权衡是值得的。
我知道什么是加密安全哈希函数，但我不理解它背后的基本原理。根据我的理解，HashMap的良好散列函数应该只有三个属性：
在加密安全散列函数中，其他属性与散列表的99％（甚至99.99％）时间并不真正相关。
所以我的问题是：“对DoS攻击和更好的安全性的抵抗”甚至意味着在HashMap的背景下？
让我们开始向后：你如何做HashMap？
多年来，基于Hash Flooding的各种软件堆栈遭到多次攻击。如果您知道某个站点是由哪个框架提供支持的，因此使用了哪个哈希函数，并且此哈希函数不具有加密安全性，那么您可以预先计算一组大量字符串哈希到相同的数字。
然后，您只需将此集合注入站点，并且对于每个（简单）请求，它执行不成比例的大量工作，因为插入N个元素需要执行O（N2）操作。
Rust是后见之明的构想，因此默认情况下注意避免这种攻击，推断真正需要性能的用户只需切换哈希函数。
假设我们使用HashMap将一些用户数据存储在Web应用程序中。假设用户可以以某种方式选择（部分）密钥 - 也许密钥是用户名或上传文件的文件名或类似的东西。
如果我们不使用加密安全散列函数，这意味着攻击者可以创建所有映射到相同输出的多个输入。当然，哈希映射必须处理冲突，因为它们是自然发生的。
但是当不自然地发生许多冲突时，哈希映射实现可能会做出奇怪的事情。例如，查找某些键可能具有O（n）的运行时间。或者哈希映射可能认为它必须因为所有冲突而增长;但是增长不会解决问题，因此哈希映射会增长，直到使用所有内存。无论哪种情况，都很糟糕。哈希映射只是假设在统计上，很少发生冲突。
当然，这不是“窃取用户数据”攻击 - 至少不是直接攻击。但是，如果系统的某个部分很弱，这会使攻击者更容易发现其他弱点。
密码安全散列函数可以防止此攻击，因为攻击者无法创建映射到相同值的多个密钥（至少在没有尝试所有密钥的情况下）。
与哈希表的99％（甚至99.99％）时间并不真正相关。
应该是。但这很难平衡。我想我们都会同意，如果20％的用户由于不安全的哈希函数而在他们的应用程序中遇到安全问题（而80％的人不关心），那么使用“默认安全”方法仍然是个好主意。 5％/ 95％呢？ 1％/ 99％呢？很难说阈值在哪里，对吗？
已经有很多关于此的讨论。因为是的，大多数人只注意到哈希映射的缓慢。也许我上面描述的情况非常罕见，默认情况下不值得减慢所有其他用户的代码。但是已经确定了，默认的哈希函数不会改变，幸运的是你可以选择自己的哈希函数。
如果服务器应用程序将用户输入（例如Web应用程序中的帖子数据）存储在哈希表中，则恶意用户可能会尝试提供大量具有相同哈希值的输入，从而导致大量哈希冲突从而大大减慢了地图上的操作，使其可以用作DoS攻击（例如HashMap中所述）。
如果哈希是加密安全的，攻击者将更难以找到具有相同哈希值的输入。