MD5 或 SHA 不是问题。哈希可用于假名化。问题是哈希需要加盐（或胡椒粉），以便其他来源的数据无法用于识别此人。

我的电子邮件在任何地方都是一样的。它的哈希值也是一样的。所以这意味着，在这种情况下，哈希和我的电子邮件成为同义词。就像用户名和一个人的合法姓名（如果配对）一样。如果在这种情况下使用哈希，就 GDPR 而言，您实际上一无所获。

在不知道附加值的情况下，用盐（或胡椒）进行散列使得去匿名化几乎是不可能的。在这种情况下，盐（或胡椒）几乎成为了象征。

与往常一样，请咨询您的 DPO。

实际上，化名是混淆某人的 PII/NPI 的任何方法，因此无法合理地追溯到某个特定的个人。GDPR 并不一定规定您需要使用哪种散列算法才能符合其标准，老实说 - 最好不要，因为如果您考虑这样一个事实，即如果每个人都使用完全相同的方法混淆，你正在创造一个巨大的单点故障。您最好的选择（如上所述）是使用某种形式的带有盐的标记化，为您的算法添加额外的随机性，使其不易被暴力破解。

散列电子邮件的问题在于它们通常很短且易于暴力破解。

如果您使用盐，根据定义，它是一个公共“密钥”，因此您无需在保护方面添加任何内容。由于 GDPR 包括您自己无法追踪您的客户，因此您是这里的被告和攻击者，因此任何胡椒或密码对您自己都没有多大用处。

真正的问题是蛮力。我不是安全专家，但我们目前正在考虑解决与您的问题类似的问题：对于每个用户电子邮件，应用哈希算法 N 次，其中 N 是 Min 和 Max 之间的随机数。在您的数据库中查找时，获取用户提供的电子邮件并将其哈希最小时间，然后查找，然后再次哈希，然后查找等，直到您找到匹配项或达到最大时间。

为每个数据库条目设置 N 变化的好处是，暴力攻击需要尝试对他们尝试的每个组合进行哈希 Max-times，而如果你有组合，你很可能只在 ( Max-Min)/2 哈希迭代。所以平均而言，你让攻击者的生活比你的更难。这是假设您的数据库查找比每次散列迭代更快。

一些进一步的思考：

1. 使用耗时的散列算法
2. 使用好盐（长且随机）
3. 考虑为每次迭代改变盐： salt(n) = f(salt(n-1))
4. 考虑让盐在每次迭代之间演变： salt(n) = f(salt(n-1), hash(n-1))
5. 顺便说一句，不要存储N。