是否可以反转 SHA-1？
我正在考虑使用 SHA-1 创建一个简单的轻量级系统来验证通过未加密连接进行通信的小型嵌入式系统。
假设我使用来自“密钥”的输入创建了一个像这样的 sha1，并使用时间戳对其进行调味，这样 SHA-1 就会一直变化。
sha1("My Secret Key"+"a timestamp")
然后我将这个 SHA-1 包含在通信和服务器中，它可以进行相同的计算。希望没有人能够弄清楚“秘密密钥”。
但这是真的吗？
如果你知道我是这样做的，你就会知道我确实在里面放了一个时间戳，你会看到 SHA-1。然后您可以使用这两个并找出“密钥”吗？
secret_key = bruteforce_sha1(sha1, timestamp)
注1：我想你可以以某种方式蛮力，但这实际上需要多少工作？
注2：我不打算加密任何数据，我只是想知道是谁发送的。
不，您不能反转 SHA-1，这正是它被称为安全哈希算法的原因。
但是，您绝对应该做的是将正在传输的消息包含在哈希计算中。否则，中间人可以截获消息，并使用签名（仅包含发送者的密钥和时间戳）将其附加到假消息（它仍然有效）。
而且您现在可能应该将 SHA-256 用于新系统。
sha("My Secret Key"+"a timestamp" + the whole message to be signed)
您还需要另外以明文形式传输时间戳，因为否则您将无法验证摘要（除了尝试许多似是而非的时间戳）。
暴力攻击是否可行取决于您的密钥的长度。
整个系统的安全性将依赖于这个共享的秘密（因为发送者和接收者都需要知道，但没有其他人知道）。攻击者会尝试获取密钥（但暴力猜测或尝试从您的设备获取），而不是尝试破坏 SHA-1。
SHA-1 是一种哈希函数，旨在使逆向操作变得非常困难。出于这个原因，这种散列函数通常被称为单向函数或加密散列函数。
然而，SHA-1 的抗碰撞性在 2005 年理论上被打破了。这允许找到两个具有相同哈希值的不同输入，比具有 2 80成本和 50% 概率的通用生日攻击更快。2017年，碰撞攻击变得可行，被称为shattered。
截至 2015 年，NIST 放弃了用于签名的 SHA-1。您应该考虑为新应用程序使用更强大的东西，例如SHA-256 。
Jon Callas在 SHA-1 上：
是时候步行了，但不要跑到消防出口。你看不到烟雾，但火警警报已经响起。
问题实际上是如何通过不安全的会话进行身份验证。
这样做的标准是使用消息摘要，例如HMAC。
您发送消息明文以及该消息的随附哈希，其中您的秘密已混合。
所以代替你的：
sha1("My Secret Key"+"a timestamp")
你有：
msg,hmac("My Secret Key",sha(msg+msg_sequence_id))
消息序列 id 是一个简单的计数器，用于跟踪双方在此“会话”中交换的消息数量 - 这可以防止攻击者简单地重播以前看到的消息。
这是验证消息的行业标准和安全方式，无论它们是否加密。
（这就是为什么你不能暴力破解哈希：）
哈希是一种单向函数，这意味着许多输入都产生相同的输出。
如您所知，您可以对时间戳的范围做出明智的猜测，然后您可以遍历所有这些时间戳，计算哈希值并进行比较。
当然，您检查的范围内的两个或多个时间戳可能会“冲突”，即尽管时间戳不同，但它们会生成相同的哈希。
因此，从根本上说，没有任何方法可以确定地反转散列。
您不能反转 SHA-1 加密字符串并不完全正确。
您不能直接反转一个，但可以使用彩虹表来完成。
维基百科： 彩虹表是用于反转加密哈希函数的预计算表，通常用于破解密码哈希。表通常用于恢复由一组有限字符组成的特定长度的明文密码。
本质上，SHA-1 的安全性取决于所使用密码的强度。如果用户的密码很长且字符组合不明确，那么现有的彩虹表不太可能拥有加密字符串的密钥。
您可以在此处测试您的加密 SHA-1 字符串：http: //sha1.gromweb.com/
您可以使用互联网上的其他彩虹表，以便 Google 反向 SHA1。
Note that the best attacks against MD5 and SHA-1 have been about finding any two arbitrary messages m1 and m2 where h(m1) = h(m2) or finding m2 such that h(m1) = h(m2) and m1 != m2. Finding m1, given h(m1) is still computationally infeasible.
Also, you are using a MAC (message authentication code), so an attacker can't forget a message without knowing secret with one caveat - the general MAC construction that you used is susceptible to length extension attack - an attacker can in some circumstances forge a message m2|m3, h(secret, m2|m3) given m2, h(secret, m2). This is not an issue with just timestamp but it is an issue when you compute MAC over messages of arbitrary length. You could append the secret to timestamp instead of pre-pending but in general you are better off using HMAC with SHA1 digest (HMAC is just construction and can use MD5 or SHA as digest algorithms).
Finally, you are signing just the timestamp and the not the full request. An active attacker can easily attack the system especially if you have no replay protection (although even with replay protection, this flaw exists). For example, I can capture timestamp, HMAC(timestamp with secret) from one message and then use it in my own message and the server will accept it.
Best to send message, HMAC(message) with sufficiently long secret. The server can be assured of the integrity of the message and authenticity of the client.
You can depending on your threat scenario either add replay protection or note that it is not necessary since a message when replayed in entirety does not cause any problems.
哈希取决于输入，对于相同的输入，将给出相同的输出。
所以，除了其他答案，请记住以下几点：
如果您使用密码开始哈希，则可以预先计算彩虹表，并快速添加合理的时间戳值，如果您从时间戳开始，这要困难得多。
所以，不要使用 sha1("My Secret Key"+"a timestamp")
go for sha1("a timestamp"+"My Secret Key")
是否可以反转 SHA-1？
SHA-1 旨在成为一种抗冲突哈希，其目的是使查找具有相同哈希的不同消息变得困难。它还被设计为具有原像抗性，即应该很难找到具有规定哈希的消息，以及第二原像抗性，因此很难找到与规定消息具有相同哈希的第二条消息.
SHA-1 的抗碰撞性实际上在2017 年被 Google 的团队打破，NIST 已经在 2015 年出于签名目的删除了 SHA-1。
另一方面，SHA-1 原像抗性仍然存在。应注意原像电阻，如果输入空间较短，则很容易找到原像。因此，您的密钥至少应为 128 位。
SHA-1("我的密钥"+"时间戳")
这是前缀秘密结构，有一个攻击案例，称为对基于 Merkle-Damgard 的哈希函数（如 SHA-1 ）的长度扩展攻击。应用于 Flicker。不应将其与 SHA-1 或 SHA-2 一起使用。一个可以使用
HMAC-SHA-256（HMAC 不需要哈希函数的抗碰撞性，因此 SHA-1 和 MD5 仍然适用于 HMAC，但是忘记了它们）以实现更好的安全系统。HMAC 具有双重调用哈希函数的成本。这是时间要求系统的弱点。一张纸条; HMAC 是密码学中的野兽。
KMAC是来自 SHA-3 的前缀秘密结构，因为 SHA-3 具有抗长度扩展攻击的能力，所以这是安全的。
使用带有前缀结构的BLAKE2，这也是安全的，因为它还可以抵抗长度扩展攻击。BLAKE 是一个非常快速的哈希函数，现在它也有一个并行版本 BLAKE3（需要一些时间进行安全分析）。Wireguard 使用 BLAKE2 作为 MAC。
然后我将这个 SHA-1 包含在通信和服务器中，它可以进行相同的计算。希望没有人能够弄清楚“秘密密钥”。
但这是真的吗？
如果你知道我是这样做的，你就会知道我确实在里面放了一个时间戳，你会看到 SHA-1。然后您可以使用这两个并找出“密钥”吗？
secret_key = bruteforce_sha1（sha1，时间戳）
您没有定义密钥的大小。如果您的攻击者知道时间戳，那么他们会尝试通过搜索来查找它。如果我们考虑比特币矿工的集体力量，截至 2022 年，他们在一年内达到约2 93双 SHA-256。因此，您必须根据您的风险调整您的安全性。截至 2022 年，NIST 的最低安全性为 112 位。应该考虑上述 128 位的秘密大小。
注1：我想你可以以某种方式蛮力，但这实际上需要多少工作？
鉴于上面的答案。作为一种特殊情况，针对Grover 算法（一种用于查找原像的 Quantum 算法）的可能实现，应该使用大于 256 输出大小的散列函数。
注2：我不打算加密任何数据，我只是想知道是谁发送的。
这不是办法。只有当秘密像 DHKE 一样相互共享时，您的构造才能工作。这是只有发件人和您才知道的秘密。除了管理这个问题，更好的方法是使用数字签名来解决这个问题。此外，一个人也将获得不可否认性。
我相信公认的答案在技术上是正确的，但在适用于用例时是错误的：通过公共/非可信媒体创建和传输防篡改数据。
因为虽然暴力破解或反转 SHA 哈希在技术上非常困难，但是当您通过 Internet 发送纯文本“数据和数据的哈希 + 秘密”时，如上所述，可以智能地获取在捕获足够的数据样本后保密。想一想 - 您的数据可能会发生变化，但密钥保持不变。所以每次你发送一个新的数据块，它都是一个运行基本破解算法的新样本。使用 2 个或更多包含不同数据的样本和数据+秘密的哈希，您可以验证您确定的秘密是正确的，而不是误报。
这种情况类似于 Wifi 破解者在捕获足够的数据包后如何破解 wifi 密码。在您收集到足够的数据后，生成密钥就很简单了，即使您在技术上并未反转 SHA1 甚至 SHA256。确保您的数据未被篡改或验证您在另一端与谁交谈的唯一方法是使用 GPG 等（公钥和私钥）加密整个数据块。当您正在散列的数据可见时，散列本质上总是不安全的。
实际上，这实际上取决于您首先进行散列的应用程序和目的。如果所需的安全级别是微不足道的，或者说你在一个 100% 完全受信任的网络中，那么散列可能是一个可行的选择。希望网络上没有人或任何入侵者对您的数据感兴趣。否则，据我目前可以确定，唯一可靠可行的选择是基于密钥的加密。您可以加密整个数据 blob，也可以只对其进行签名。
注意：这是英国人在二战期间能够破解 Enigma 密码的方式之一，从而有利于盟军。
对此有什么想法吗？
SHA1 旨在防止从哈希中恢复原始文本。但是，存在 SHA1 数据库，允许通过其 SHA 哈希查找常用密码。