是否可以预先计算一个 git commit 哈希，以便可以将其放置在提交本身中？答案

【问题标题】：Is it possible to precompute a git commit hash such that it can be placed in the commit itself?是否可以预先计算一个 git commit 哈希，以便可以将其放置在提交本身中？
【发布时间】：2013-06-01 19:47:13
【问题描述】：

我正要从网站管理员中删除一项我认为没有人在使用的功能。不过，我想在某人仍在使用它的情况下留言。我打算用以下效果替换 HTML 模板：

<p>This feature has been disabled.  If you need it back please ask engineering to revert #1234567890abcdef<p>

显然，我意识到这可以通过两次提交轻松完成。但是我认为从密码学的角度来看这是一个有趣的问题。

假设您只能修改哈希本身，那么满足此属性的哈希实际存在的可能性有多大？当你缩短散列（因为 git 允许唯一的前缀）时，这种散列的可能性可能会增加。 6 字符前缀的概率是多少？找到的难度有多大？

【问题讨论】：

我已将此问题标记为关闭，因为我相信这不是编程专业的实际问题。如果是这样，它更适合crypto.stackexchange.com

标签： git cryptography sha

【解决方案1】：

如果哈希可以这样做：

很短。只需尝试多次，直到满足该属性。 n 位散列的成本为 2^n。 SHA-1 的 160 位远太长，无法正常工作。您可以对哈希的前几位执行此操作。大约 8-12 个十六进制数字（32-48 位）应该是可行的，无需太多努力。
哈希具有允许这样做的数学结构。 CRC 和类似的哈希值是这样工作的。使用 SHA-1 等典型的加密哈希是不可能的。

简而言之，您不能拥有包含自己的哈希的提交。

【讨论】：

【解决方案2】：

This script 对短散列做类似的事情。

假设 (SHA-1) 哈希函数是均匀分布的（这很重要），计算概率很容易。这是一个示例 SHA-1 哈希：

0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33

40 个字符。每个字符 4 位。 2^(number-of-characters * 4) 可能性。

因此，如果您想要 SHA-1 的前 7 个半字节（十六进制字符），您正在查看 2^(7*4) == 1/268435456 找到正确哈希的机会。（如您所见，这对于脚本来说应该不会太难！）

【讨论】：

注意，我不确定脚本实际上是否可以轻松找到 7 个半字节（其示例用法使用较少），但理论上，there are tools 可以计算十亿的 SHA每秒 -1 个哈希值。

【解决方案3】：

您可以使用git hash-object <fileName> 获取对象的哈希值，看看这篇帖子How to assign a Git SHA1's to a file without Git?

虽然我不认为你想做的事是可能的。编辑文件将更改文件的哈希值。因此，如果您计算哈希并将该值放入文件中，则文件的哈希现在已更改。因此，您保存在文件中的哈希不会是正确的哈希。

【讨论】：