3 回答

TA貢獻1998條經驗 獲得超6個贊
原始答案(2012)(見shattered.io
下面的2017 SHA1碰撞)
Linus的那個舊的(2006)答案可能仍然是相關的:
不。如果它具有相同的SHA1,則意味著當我們從另一端接收到對象時,我們將不會覆蓋我們已有的對象。
所以會發生的是,如果我們看到碰撞,任何特定存儲庫中的“早期”對象將始終最終覆蓋。但請注意,“早期”顯然是每個存儲庫,因為git對象網絡生成的DAG不是完全有序的,因此雖然不同的存儲庫會同意直接祖先情況下的“早期”,如果對象來自分離而非直接相關的分支,兩個不同的回購可能顯然已經得到了不同順序的兩個對象。
但是,從安全角度來看,“早先將覆蓋”非常符合您的要求:請記住,git模型是您應該主要只信任自己的存儲庫。
因此,如果你執行“git pull
”,新的傳入對象根據定義不如你已經擁有的對象值得信任,因此允許新對象替換舊對象是錯誤的。所以你有兩種碰撞案例:
在不經意的那種,你不知何故是非常非常不走運,而兩個文件最終具有相同SHA1。
此時,當您提交該文件(或執行“git-update-index
”將其移入索引但尚未提交)時,會計算新內容的SHA1,但由于它與舊對象匹配,將不會創建新對象,并且commit-or-index最終指向舊對象。
您不會立即注意到(因為索引將與舊對象SHA1匹配,這意味著像“git diff
” 這樣的東西將使用簽出的副本),但是如果你曾經做過樹級差異(或者你做了克?。┗蚶?,或強制結帳)你會突然注意到該文件已更改為某些內容與你的預期完全不同。
所以你通常會很快注意到這種碰撞。
在相關的新聞中,問題是如何處理無意中的碰撞。
首先,讓我提醒人們,無意中的碰撞實際上真的不太可能,所以我們很可能永遠不會在完整的歷史中看到它宇宙
但是如果它發生了,那就不是世界末日:你最有可能要做的就是改變稍微相撞的文件,并強制使用更改的內容強制進行新的提交(添加注釋說“/* This line added to avoid collision */
”)和然后教git關于已被證明是危險的魔法SHA1。
因此,在幾百萬年中,我們可能必須向git添加一個或兩個“中毒”SHA1值。這不太可能成為維護問題;)該攻擊者那種碰撞,因為有人打破(或野蠻強制)SHA1。
這一個顯然是一個很多比無意樣的可能性較大,但顧名思義它總是一個“遠程”庫。如果攻擊者可以訪問本地存儲庫,他就會有更容易的方法來阻止你。
所以在這種情況下,碰撞完全不是問題:你會得到一個與攻擊者意圖不同的“壞”存儲庫,但是因為你永遠不會真正使用他的碰撞對象,所以它實際上與攻擊者根本沒有發現碰撞,但只是使用你已經擁有的對象(即它100%相當于生成相同SHA1的相同文件的“普通”沖突)。
經常提到使用SHA-256的問題,但現在不采取行動(2012)。
注意:從2018和Git 2.19開始,代碼被重構為使用SHA-256。
注(幽默):你可以強制提交到一個特定的SHA1 前綴,項目gitbrute從布拉德·菲茨帕特里克(bradfitz
)。
gitbrute強制執行一對作者+提交者時間戳,以便生成的git commit具有您想要的前綴。
示例:https://github.com/bradfitz/deadbeef
丹尼爾Dinnyes指出,在評論中,以7.1的Git工具-修正選擇,其中包括:
更高的可能性是你的編程團隊的每個成員都會在同一天晚上被無關緊要的事件中的狼襲擊和殺死。
即便是最近(2017年2月)也shattered.io
證明了造成SHA1碰撞的可能性:(
請參閱我的單獨答案中的更多信息,包括Linus Torvalds的Google+帖子)
a /仍需要超過9,223,372,036,854,775,808個SHA1計算。這需要相當于6,500年單CPU計算和110年單GPU計算的處理能力。
b /會偽造一個文件(使用相同的SHA1),但是使用附加約束,其內容和大小會產生相同的SHA1(單獨內容上的沖突是不夠的):請參閱“ 如何計算git哈希? ”) :blob SHA1基于內容和大小計算。
有關更多信息,請參閱Valerie Anita Aurora的 “ 加密哈希函數的生命周期 ” 。 在那頁中,她指出:
谷歌花了6500個CPU年和110個GPU年來說服每個人我們需要停止使用SHA-1來處理安全關鍵應用程序。
還因為它很酷
查看更多在我下面的單獨的答案。
- 3 回答
- 0 關注
- 1056 瀏覽
添加回答
舉報