TLDR;
2007'de Git'i Google'a geri sunduğunda Linus Torvalds'ın kendisinden kontrol edebilirsiniz :
(vurgu benim)
Kriptografik olarak güvenli kabul edilen sağlama toplamlarını kontrol ediyoruz. Kimse SHA-1'i kıramadı, ama asıl nokta, git ile ilgili olarak SHA-1, bir güvenlik özelliği bile değil. Tamamen bir tutarlılık kontrolü .
Güvenlik parçaları başka yerlerdedir. Git SHA-1 kullandığından ve SHA-1 kriptografik olarak güvenli şeyler için kullanıldığından, birçok insan bunun büyük bir güvenlik özelliği olduğunu düşünüyor. Güvenlikle hiçbir ilgisi yok, alabileceğiniz en iyi karma.
İyi bir karmaya sahip olmak verilerinize güvenebilmek için iyidir, başka bazı iyi özelliklere de sahip olur, bu da nesneleri hash ettiğimizde, karmanın iyi dağıtıldığını biliyoruz ve belirli dağıtım sorunları hakkında endişelenmemiz gerekmiyor .
Dahili olarak uygulama açısından, hash'in o kadar iyi olduğuna güvenebiliriz, hash algoritmalarını kullanabilir ve kötü durum olmadığını biliriz.
Bu nedenle, şifreleme tarafını sevmenin bazı nedenleri de var, ancak gerçekten verilerinize güvenme yeteneği ile ilgili.
Verilerinizi git'e koyarsanız, beş yıl sonra, sabit diskinizden DVD'ye yeni teknolojiye dönüştürüldükten ve kopyaladıktan sonra , beş yıl sonra verileri doğrulayabileceğinize güvenebilirsiniz. geri almak, girdiğiniz verilerle aynı. Ve bu gerçekten bir kaynak kodu yönetim sisteminde aramanız gereken bir şey .
Aralık 2017'yi Git 2.16 (Q1 2018) ile güncelleyin: alternatif bir SHA'yı desteklemek için bu çaba devam ediyor: bkz. " Git neden daha modern SHA kullanmıyor? ".
Ben "sözü bir damla? Üzerinde bir SHA1 çarpışma ele Git olacağını nasıl o" olabilir bir belirli SHA1 ile taahhüt mühendisi öneki (hala son derece masraflı bir çaba).
Ancak Eric Sink'in " Git: Cryptographic Hashes " ( Örnek ile Versiyon Kontrolü (2011) kitabında da belirtildiği gibi, konu hala devam ediyor :
DVCS'nin asla aynı özete sahip iki farklı veri parçasıyla karşılaşmaması oldukça önemlidir. Neyse ki, iyi kriptografik hash fonksiyonları, bu tür çarpışmaları son derece olası hale getirmek için tasarlanmıştır.
" Genetik Programlama ile Son Teknoloji Olmayan Kriptografik Karmaları Bulma " gibi bir araştırma düşünmedikçe, düşük çarpışma oranına sahip iyi kriptografik olmayan karmayı bulmak daha zordur .
Ayrıca , RAM sınırlarına yakın hızlarda çalışan son derece hızlı bir kriptografik olmayan Hash algoritması olan " xxhash " ifadesinden bahseden " Hızlandırma için kriptografik olmayan karma algoritmanın kullanımını düşünün " bölümünü okuyabilirsiniz .
Git'te karma değerini değiştirmeyle ilgili tartışmalar yeni değil:
(Linus Torvalds)
Orada gerçekten bir şey değil kalan mozilla kodunun, ama hey, ben ondan başladı. Geriye dönüp baktığımda, muhtemelen zaten blokaj yapan PPC asm kodundan başlamalıydım - ama bu bir "20/20 gezisi" türünde bir şey.
Ayrıca hey, korkunç bir kabuk yığını olan mozilla kodu, şeyleri geliştirebilmem için neden bu kadar ikna olduğumdu. Yani bu, motivasyon tarafıyla ilgili gerçek kodlardan daha fazla olsa bile, bunun için bir tür kaynaktır;)
Ve gerçek optimizasyon kazancını nasıl ölçeceğiniz konusunda dikkatli olmanız gerekir
(Linus Torvalds)
Ben hemen hemen sadece gcc bok kodu üretmek yapar, çünkü daha sonra bazı P4 sorunları gizler şeyler geliştirmek garanti edemez.
(John Tapsell - johnflux)
Git'i SHA-1'den yeni bir algoritmaya yükseltmenin mühendislik maliyeti çok daha yüksektir . Nasıl iyi yapılabileceğinden emin değilim.
Her şeyden önce, muhtemelen bu alanı okumasa veya kullanmasa da yeni bir karma değer için bir yuva olmasını sağlayan bir git (bu konuşma için sürüm 2 diyelim) sürümünü kullanmamız gerekiyor - sadece kullanıyor diğer yuvadaki SHA-1 karma değeri.
Bu şekilde sonunda git'in daha yeni bir sürümünü kullandığımızda, buna SHA-1 karmalarına ek olarak SHA-3 karmaları üreten sürüm 3 diyelim, git sürüm 2'yi kullanan kişiler etkileşime devam edebilecekler.
(Bu tartışma uyarınca, savunmasız olabilirler ve yalnızca SHA-1 yamalarına güvenen kişiler savunmasız olabilir.)
Kısacası, herhangi bir karmaya geçmek kolay değildir.
Şubat 2017'yi güncelleyin: evet, teorik olarak çarpışan bir SHA1'i hesaplamak mümkündür: shattered.io
GIT nasıl etkilenir?
GIT, tüm dosya nesneleri ve taahhütlerinin tanımlanması ve bütünlük kontrolü için SHA-1'e güvenmektedir.
Aynı kafa işleme karması ve farklı içeriğe sahip iki GIT deposu oluşturmak mümkündür, örneğin iyi huylu bir kaynak kodu ve arka kapı.
Saldırgan, potansiyel olarak her iki havuzu hedef kullanıcılara sunabilir. Bu, saldırganların kendi çarpışmalarını hesaplamasını gerektirecektir.
Fakat:
Bu saldırı 9,223,372,036,854,775,808 SHA1 hesaplaması gerektirmiştir. Bu, eşdeğer işlem gücünü 6.500 yıllık tek CPU hesaplamaları ve 110 yıllık tek GPU hesaplamaları olarak aldı.
Bu yüzden henüz paniğe kapılmayalım.
" Git bir damla üzerinde SHA-1 çarpışmasını nasıl ele alır? "