是否可以预先计算git提交哈希，以便将其置于提交本身？

Question

我正准备从网站管理员中移除一项我不相信任何人正在使用的功能。但是，我想留言，某人 仍在使用它。我打算用以下内容替换HTML模板：

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

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

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

Answer 1

This script做了类似于短哈希的事情。

假设（SHA-1）散列函数均匀分布（这是一种点），很容易计算概率。这是一个示例SHA-1哈希：

0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33

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

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

Answer 2

如果哈希：

，你可以这样做

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

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

Answer 3

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

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