是否可以重建加密哈希的密钥答案

【问题标题】：Is It Possible To Reconstruct a Cryptographic Hash's Key是否可以重建加密哈希的密钥
【发布时间】：2011-01-18 20:58:20
【问题描述】：

我们希望在我们的数据库中以加密方式 (SHA-256) 散列一个秘密值。由于我们想用它作为在我们的数据库中查找单个记录的一种方式，我们不能为每个加密值使用不同的随机盐。

我的问题是：如果可以无限制地访问我们的数据库，并且攻击者至少知道一个秘密值和散列值对，那么攻击者是否有可能对加密密钥进行逆向工程？ IE，那么攻击者是否能够反转所有哈希值并确定所有秘密值？

如果是这样的话，这似乎违背了加密哈希的全部目的，所以也许我遗漏了一些东西。

【问题讨论】：

SHA-256 不是键控散列。 SHA256 HMAC 是。
是的，这是我遗漏的要点之一——散列函数和 HMAC 之间的区别。只要我们使用 HMAC，攻击者就不可能确定其他秘密值，即使他们知道给定的秘密值及其对应的 HMAC。对吗？
嗯，这与使用 HMAC 无关——一个普通的散列就足以防止确定其他散列值。 HMAC 添加了盐（但在计算过程中，这比将其添加到您的秘密中更好） - 这可以防止预先计算的彩虹表。看看这里chargen.matasano.com/chargen/2007/9/7/…，也许谷歌彩虹表，你会发现很多信息
哦，顺便说一句 - 当您评论自己的问题时，除非您写 @recursive 或 @tanascius ，否则没有人会收到通知 :) 请参见此处：blog.stackoverflow.com/2010/01/new-improved-comments-with-reply

标签： security encryption

【解决方案1】：

没有针对 SHA-256 的公开“第一原像”攻击。如果没有这种打开快捷方式的攻击，攻击者就不可能从其 SHA-256 哈希中恢复秘密值。

但是，提及“密钥”可能表明对哈希的一些混淆。哈希算法不使用密钥。因此，如果攻击者能够攻击一个“秘密值-哈希值”对，他就不会学习一个能够让他轻松反转其余哈希值的“密钥”。

当一个哈希被成功攻击时，通常是因为原始消息来自一个小空间。例如，大多数密码都是从相对较短的真实单词列表中选择的，可能有一些简单的排列。因此，攻击者不是系统地测试每个可能的密码，而是从几十亿个最常见密码的有序列表开始。为了避免这种情况，重要的是从大空间中随机选择“秘密值”。

有一些消息身份验证算法将密钥与一些数据一起散列。这些算法用于保护消息的完整性不被篡改。但它们无助于阻止原像攻击。

【讨论】：

好的，但是在没有盐的情况下，如果他们所做的只是散列一个序列，那将是一个微不足道的彩虹表。
即使为 8 个可打印字符创建彩虹表也并非易事。为 128 位值创建彩虹表是不可能的。
我在考虑一个明文域非常知名的情况，例如散列一个数字序列。您可以对第一个 n 进行散列，对于您有时间的任何 n 值。
这种情况就是我所说的，“当一个哈希被成功攻击时，通常是因为原始消息来自一个小空间。......为了避免这种情况，重要的是从大空间中随机选择‘秘密值’。”
好的，我想我们完全一致。

【解决方案2】：

简而言之，yes。

【讨论】：

但是暴力破解哈希与对算法进行逆向工程是不同的……当可以对算法进行逆向工程时，您就不再需要计算能力了。（逆向工程是一个错误的词——它更像是构建一个逆向算法，直到现在这是不可能的）
不是一个有用的答案——“足够的计算能力”可以用于暴力攻击以破解几乎任何密钥（显然不是一次性键盘），但如果这是唯一的攻击可供您使用，并且具有较大的密钥空间，这仍然是一个非常安全的系统。
我相信逆向工程的原始用法是为了重建共享密钥，SHA-256 算法的加密攻击不是必需的。虽然攻击（或反转）SHA-256算法可能足以重建或恢复原始共享密钥，但它不是必要恢复钥匙。例如，如果搜索空间足够小或搜索时间（或计算能力）足够长，那么蛮力方法就足够了。
""足够的计算能力"可以通过暴力攻击破解任何密钥" - 实际上没有。暴力破解 2^256 键空间（在找到解决方案之前平均搜索 2^128 个键）在物理上不使用已知算法可行，并且单个已知计算能力的总和任务。参考：en.wikipedia.org/wiki/Brute_force_attack#Theoretical_limits
IMO 链接（推荐使用 HMAC 与普通哈希）比答案更有用（由于计算能力的假设，这是错误的）。

【解决方案3】：

不，SHA 哈希是不可逆的（至少不容易）。当你散列一些东西时，如果你需要反转它，你需要重建散列。这通常使用私钥（盐）和公钥来完成。

例如，如果我试图阻止基于我的用户 ID 的访问。我会散列我的用户 ID 和盐。比如说MD5。我的用户 ID 是“12345”，盐是“abcde”

所以我将对字符串“12345_abcde”进行哈希处理，返回哈希值“7b322f78afeeb81ad92873b776558368”

现在我将把哈希和公钥传递给验证应用程序，“12345”是公钥和 has。

验证应用程序知道盐，所以它散列相同的值。 “12345_abcde”，这反过来会生成完全相同的哈希值。然后我将我验证的哈希值与传递的哈希值进行比较，它们匹配。如果我在不修改哈希的情况下以某种方式修改了公钥，则会生成不同的已导致不匹配。

【讨论】：

【解决方案4】：

是的，有可能，但今生不可能。

【讨论】：

@Pentium10：你不能确定 ;)
...除非有新的发展。当然，即使有当前的选择，攻击者也可能会走运。赔率是反对的，但他们只是赔率。

【解决方案5】：

使用多个 GPU 的现代蛮力攻击可以在短时间内破解此问题。我建议您遵循此应用程序的密码存储指南。这里是the current password storage guidelines from OWASP。目前，他们推荐一个长盐值，以及具有 64,000 次迭代的 PBKDF2，它迭代地拉伸密钥并使其计算复杂以强制输入值。请注意，这也会使您生成密钥值在计算上变得复杂，但其想法是您生成密钥的频率将远低于攻击者所必须的频率。也就是说，与典型的密码存储/挑战应用程序相比，您的设计需要更多的密钥派生，因此您的设计可能存在致命缺陷。还要记住，迭代次数应该每 18 个月翻一番，以使计算复杂度遵循摩尔定律。这意味着您的系统需要某种方式来允许您重新散列这些值（可能通过组合散列技术）。随着时间的推移，你会发现旧的 HMAC 函数被密码分析者破解，你需要准备好更新你的算法。例如，MD5 或 SHA-1 的单次迭代曾经就足够了，但现在已经不行了。还有其他不需要 PBKDF2 的 HMAC 功能也可以满足您的需求（例如 bcrypt 或 scrypt），但 PBKDF2当前是受到最严格审查的行业标准。有人可能会争辩说 bcrypt 或 scrypt 也是合适的，但这也是为什么应该使用可插拔方案来允许您随着时间的推移升级 HMAC 功能的另一个原因。

【讨论】：