Pra*_*tic 135 git hash-function
为什么Git使用加密哈希函数SHA-1而不是更快的非加密哈希函数？
相关问题:
Stack Overflow问题为什么Git使用SHA-1作为版本号？问为什么Git使用SHA-1而不是序列号进行提交.
Von*_*onC 193
TLDR;
你可以从Linus Torvalds本人那里查看,当他在2007年向谷歌展示Git时 :(
强调我的)
我们检查被认为是加密安全的校验和.没有人能够打破SHA-1,但重点是,就git而言,SHA-1甚至不是安全功能.这纯粹是一致性检查.
安全部分在其他地方.很多人都认为,因为git使用SHA-1而SHA-1用于加密安全的东西,他们认为这是一个巨大的安全功能.它与安全没有任何关系,它只是你能得到的最好的哈希.拥有良好的哈希值对于能够信任您的数据是好的,它恰好具有一些其他好的功能,这意味着当我们哈希对象时,我们知道哈希是分布良好的,我们不必担心某些分发问题.
从内部来看,它意味着从实现的角度来看,我们可以相信散列非常好,我们可以使用散列算法,并且知道没有坏的情况.
因此,有一些理由喜欢加密方面,但它确实是关于信任数据的能力.
我保证,如果你把你的数据放在git中,你可以相信这样一个事实:五年之后,从你的硬盘转换成DVD到任何新技术,你复制了它,五年后你可以验证数据你退出是你输入的完全相同的数据.这是你真正应该在源代码管理系统中寻找的东西.
使用Git 2.16(2018年第一季度)更新2017年12月:支持替代SHA的努力正在进行中:请参阅" 为什么Git不使用更现代的SHA？ ".
我在" git如何处理blob上的SHA-1冲突？ "中提到过,你可以设计一个具有特定SHA1 前缀的提交(仍然是一项极其昂贵的工作).
但问题仍然存在,正如Eric Sink在" Git:Cryptographic Hashes "中所提到的(Version by Example(2011)书:
DVCS从不会遇到具有相同摘要的两个不同数据,这一点非常重要.幸运的是,良好的加密哈希函数旨在使这种冲突极不可能.
除非你考虑像" 通过遗传编程寻找最先进的非加密哈希 "这样的研究,否则很难找到具有低冲突率的良好非加密哈希.
您还可以阅读" 考虑使用非加密哈希算法进行哈希加速 ",其中提到了例如" xxhash ",一种极快的非加密哈希算法,工作速度接近RAM限制.
关于在Git中更改哈希的讨论并不新鲜:
(Linus Torvalds)
Mozilla代码没有任何剩余,但是嘿,我从它开始.回想起来,我可能应该从PPC asm代码开始,已经做了阻塞 - 但这是一个"20/20后见之明"的事情.
另外,嘿,mozilla代码是一堆可怕的东西,这就是为什么我如此坚信我可以改进的东西.所以这是它的一种来源,即使它更多地是关于动机方面而不是任何实际的剩余代码;)
您需要注意如何衡量实际的优化增益
(Linus Torvalds)
我几乎可以保证它只是因为它使gcc生成垃圾代码而改进了东西,然后隐藏了一些P4问题.
(John Tapsell - johnflux)
将git从SHA-1升级到新算法的工程成本要高得多.我不确定它是如何做得好的.
首先,我们可能需要部署一个版本的git(让我们称之为这个对话的版本2),这允许有一个新的哈希值的插槽,即使它没有读取或使用该空间 - 它只是使用另一个槽中的SHA-1哈希值.
这样一旦我们最终部署了更新版本的git,让我们称之为版本3,除了SHA-1哈希之外还会产生SHA-3哈希,使用git版本2的人将能够继续互操作.
(尽管根据此讨论,他们可能容易受到攻击,而依赖于仅限SHA-1的补丁的人可能会受到攻击.)
简而言之,切换到任何哈希并不容易.
2017年2月更新:是的,理论上可以计算出碰撞的SHA1:shattered.io
GIT是如何受到影响的？
GIT强烈依赖SHA-1来识别和完整性检查所有文件对象和提交.
基本上可以创建两个具有相同头部提交哈希和不同内容的GIT存储库,例如良性源代码和后端源代码.
攻击者可能有选择地向目标用户提供任一存储库.这将要求攻击者计算自己的碰撞.
但:
此攻击需要超过9,223,372,036,854,775,808个SHA1计算.这需要相当于6,500年单CPU计算和110年单GPU计算的处理能力.
所以,让我们不要惊慌失措.
请参阅" Git如何处理blob上的SHA-1碰撞？ ".