Git'i kullanırken karma bir çarpışmam olsaydı ne olurdu?

Örneğin, aynı sha1 sağlama toplamı ile iki dosya yürütmeyi başarabilirim, git fark eder mi ya da dosyalardan birini bozar mıyım?

Git bununla yaşamak için geliştirilebilir mi yoksa yeni bir karma algoritmasına geçmek zorunda mıyım?

(Lütfen bunun ne kadar olası olduğunu tartışarak bu soruyu saptırmayın - Teşekkürler)

10 Ay'da Atom Toplama

Bir SHA-1 karması 40 hex karakter dizesidir ... karakter başına 4 bit 40 ... 160 bittir. Şimdi 10 bitin yaklaşık 1000 (tam olarak 1024) olduğunu biliyoruz, yani 1 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 farklı SHA-1 karmaları var ... 10 ⁴⁸ .

Bu eşdeğeri nedir? Ay yaklaşık 10 ^47'den oluşuyor atomdan oluşur. Yani 10 Ay'ımız varsa ... ve bu aylardan birine rastgele bir atom seçersen ... ve sonra devam et ve tekrar rastgele bir atom seç ... ... sonra aynı atomu iki kez seçmen , verilen iki git komutunun aynı SHA-1 karmasına sahip olma olasılığıdır.

Bunun üzerine soruyu sorabiliriz ...

Çarpışmalar hakkında endişelenmeye başlamadan önce bir depoda kaç komisyona ihtiyacınız var?

Bu, "Doğum günü saldırıları" ile ilgilidir, bu da "Doğum Günü Paradoksu" veya "Doğum Günü Sorunu" anlamına gelir; bu, belirli bir kümeden rastgele seçtiğinizde, muhtemelen iki kere bir şey seçmiş olmak. Ancak "şaşırtıcı derecede az" burada çok göreceli bir terimdir.

Wikipedia'nın Doğum Günü Paradoksu çarpışma olasılığı hakkında bir tablosu var . 40 karakterlik karmaya giriş yok. Ancak 32 ve 48 karakterlik girişlerin enterpolasyonu, 5 * 10 ²² git aralığına iner ve % 0.1'lik bir çarpışma olasılığı söz konusudur. Bu, çarpışma olasılığınız% 0.1 olan bir şansa ulaşmadan önce elli bin milyar milyar farklı taahhüt veya elli Zettacommits .

Bu taahhütler için yalnızca karma değerlerin bayt toplamı, bir yıl boyunca Dünya'da üretilen tüm verilerden daha fazla veri olacaktır; yani, YouTube'un video akışından daha hızlı yayılması gerekir. Bunda iyi şanslar. : D

Bunun amacı, bir kişi kasıtlı olarak bir çarpışmaya neden olmadıkça, birinin rastgele meydana gelme olasılığı o kadar şaşırtıcıdır ki, bu sorunu göz ardı edebilirsiniz.

"Ama bir çarpışma olduğunda meydana ardından gerçekte ne oluyor?"

Tamam, düşünülemez olanın gerçekleştiğini veya kasıtlı bir SHA-1 karma çarpışmasını uyarlamayı başardığını varsayalım . O zaman ne olacak?

Bu durumda, birinin denediği yerde mükemmel bir cevap var . Bu cevaptan alıntı yapacağım:

1. Aynı karmaya sahip bir damla zaten varsa, herhangi bir uyarı almazsınız. Her şey yolunda gibi görünüyor, ama birisini klonladığınızda veya geri döndüğünüzde, en son sürümü kaybedeceksiniz (yukarıda açıklananlara uygun olarak).
2. Bir ağaç nesnesi zaten varsa ve aynı karma ile bir damla oluşturursanız: Siz itmeye çalışana veya birileri deponuzu klonlayana kadar her şey normal görünecektir. O zaman repo bozuk olduğunu göreceksiniz.
3. Bir taahhüt nesnesi zaten varsa ve aynı karma ile bir damla oluşturursanız: # 2 ile aynı - bozuk
4. Bir blob zaten varsa ve aynı karma ile bir taahhüt nesnesi yaparsanız, "ref" güncellenirken başarısız olur.
5. Bir damla zaten varsa ve aynı karma ile bir ağaç nesnesi yaparsanız. Taahhüt oluşturulurken başarısız olur.
6. Bir ağaç nesnesi zaten varsa ve aynı karmaya sahip bir taahhüt nesnesi yaparsanız, "ref" güncellenirken başarısız olur.
7. Bir ağaç nesnesi zaten varsa ve aynı karmaya sahip bir ağaç nesnesi yaparsanız, her şey yolunda görünecektir. Ancak taahhütte bulunduğunuzda, tüm havuz yanlış ağaca atıfta bulunacaktır.
8. Bir taahhüt nesnesi zaten varsa ve aynı karma ile bir taahhüt nesnesi yaparsanız, her şey yolunda görünecektir. Ancak taahhütte bulunduğunuzda, taahhüt asla oluşturulmayacak ve HEAD işaretçisi eski bir taahhüde taşınacaktır.
9. Bir kesinleştirme nesnesi zaten varsa ve aynı hash ile bir ağaç nesnesi yaparsanız, kesinleştirme oluşturulurken başarısız olur.

Göründüğünüz gibi bazı durumlar iyi değil. Özellikle # 2 ve 3 numaralı durumlar deponuzu bozar. Bununla birlikte, hatanın bu depoda kaldığı ve saldırı / tuhaf olasılıkların diğer depolara yayılmadığı görülmektedir.

Ayrıca, kasıtlı çarpışmalar meselesinin gerçek bir tehdit olarak kabul edildiği görülmektedir ve bu nedenle örneğin GitHub, bunu önlemek için önlemler almaktadır .

Git'te iki dosya aynı karma toplamına sahipse, bu dosyalara özdeş davranır. Bu kesinlikle olası olmayan bir durumda, her zaman bir taahhüt geri gidebilir ve dosyada bir şeyleri değiştirebilir, böylece artık çarpışmazlar ...

Bkz dizisindeki Torvalds' yazı ‘sha-256 düşünmek başlayan?’ git posta listesinden .

Bu soruyu neden "sorun" olmadığını açıklamaksızın "ama" hakkıyla cevaplamak gerçekten mümkün değil. Bunu bir karma gerçekten ne iyi bir kavrama olmadan yapmak mümkün değildir. Bir CS programında karşılaşabileceğiniz basit vakalardan daha karmaşıktır.

Burada bilgi teorisinin yanlış anlaşılması var. Çok miktarda bilgiyi bir miktar (yani bir karma) atarak daha küçük bir miktara indirirseniz, verilerin uzunluğu ile doğrudan ilgili bir çarpışma olasılığı olacaktır. Veriler ne kadar kısa olursa, daha az olması muhtemeldir. Şimdi, çarpışmaların büyük çoğunluğu anlamsız olacak, bu da onların gerçekleşme olasılığını daha yüksek hale getirecektir (asla anlamsızca kontrol edemezsiniz ... ikili bir görüntü bile biraz yapılandırılmıştır). Sonunda, şans uzak. Sorunuzu cevaplamak için, evet, git onlara aynı şekilde davranacak, hash algoritmasını değiştirmek yardımcı olmayacak, bir çeşit "ikinci kontrol" alacaktır, ama sonuçta, çok fazla "ek kontrol" verisine ihtiyacınız olacak % 100 emin olmak için veri uzunluğu olarak ... 99.99999 olacağını unutmayın ... gerçekten çok sayıda basamak .... açıklamak gibi basit bir kontrol ile emin. SHA-x kriptografik olarak güçlü karmalardır, yani kasıtlı olarak birbirlerine ÇOK BENZER ve aynı karmaya sahip iki kaynak veri kümesi oluşturmak genellikle zor değildir. Verideki bir bit değişiklik, karma çıkışında birden fazla (tercihen mümkün olduğunca çok) bit değişikliği oluşturmalıdır, bu da karmadan tüm kümeye geri dönmenin çok zor (ama imkansız değil) anlamına gelir. Çarpışmalar ve böylece orijinal mesajı bu çarpışma kümesinden çıkarın - birkaç tanesi hariç hepsi anlamsız olacak ve mesaj uzunluğu önemli bir uzunluktaysa elemek için çok fazla sayılamayacak olanlar. Bir kripto karmasının dezavantajı, hesaplamak için yavaş olmalarıdır ... genel olarak.

Peki, Git için ne anlama geliyor? Fazla değil. Hashler o kadar nadiren yapılır (diğer her şeye göre), hesaplama cezaları operasyonlar genel olarak düşüktür. Bir çift çarpışmayı vurma şansı çok düşüktür, gerçekleşmesi gerçekçi bir şans değildir ve hemen algılanmaz (yani, kodunuz büyük olasılıkla aniden durur), kullanıcının sorunu düzeltmesine (bir revizyonu yedeklemesine, ve değişikliği tekrar yapın ve zaman değişikliği nedeniyle neredeyse kesinlikle farklı bir karma elde edersiniz, bu da git'teki hash'ı besler). Git'te rasgele ikili dosyaları saklıyorsanız, sizin için gerçek bir sorun olması daha olasıdır, ki bu aslında birincil kullanım modeli değildir. Bunu yapmak istiyorsanız ... muhtemelen geleneksel bir veritabanı kullanmaktan daha iyi olursunuz.

Bunu düşünmek yanlış değil - birçok insanın "düşünülmeye değer olmadığı muhtemel" olarak geçmesi iyi bir soru - ama bundan biraz daha karmaşık. Böyle bir şey olursa, kolayca algılanabilir olmalıdır, normal bir iş akışında sessiz bir yolsuzluk olmaz.

Git bununla yaşamak için geliştirilebilir mi yoksa yeni bir karma algoritmasına geçmek zorunda mıyım?

Herhangi bir karma algoritma için çarpışmalar mümkündür, bu nedenle karma işlevini değiştirmek sorunu engellemez, sadece gerçekleşme olasılığını azaltır. O zaman gerçekten iyi bir karma işlevini seçmelisiniz (SHA-1 zaten, ama söylenmemelisiniz :)

" Git bir damla üzerinde SHA-1 çarpışmasını nasıl ele alacaktı? " Bölümünde iyi bir çalışma görebilirsiniz .

Bir SHA1 çarpışması artık mümkün olduğundan ( bu cevapta shattered.io ile referans verdiğim gibi ), Git 2.13'ün (2. Çeyrek 2017) SHA-1 uygulamasının "çarpışma yaratma girişimi algılama" varyantı ile mevcut durumu iyileştireceğini / azaltacağını bilin Marc Stevens (CWI) ve Dan Shumow (Microsoft) tarafından hazırlanmıştır .

Bkz. Taahhüt f5f5e7f , taahhüt 8325e43 , taahhüt c0c2006 , taahhüt 45a574e , taahhüt 28dc98e (16 Mar 2017), Jeff King ( peff) .
^{(Göre Birleştirilmiş - Junio Cı Hamano gitster- içinde 48b3693 tamamlama 2017 24 Mar)}

Makefile: Yapmak DC_SHA1 varsayılanı yap

Varsayılan olarak OpenSSL kitaplığındaki SHA1 uygulamasını kullanırdık.
Son "parçalanmış" duyurudan sonra çarpışma saldırılarına karşı dikkatli olmaya çalışırken, insanları DC_SHA1 uygulamasını kullanmaya teşvik etmek için varsayılanı değiştirin.
Uygulamayı OpenSSL'den kullanmak isteyenler OPENSSL_SHA1=YesPlease" make" çalıştırırken bunu açıkça isteyebilirler .

Aslında bir Git-nesne çarpışması yok, bu yüzden yapabileceğimiz en iyi şey parçalanmış PDF'lerden birini test-sha1 aracılığıyla çalıştırmaktır. Bu, çarpışma kontrolünü tetiklemeli ve ölmelidir.

Git bununla yaşamak için geliştirilebilir mi yoksa yeni bir karma algoritmasına geçmek zorunda mıyım?

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? ".

Başka bir karma algoritması kullanabileceksiniz: SHA1 artık Git için tek değil.

Git 2.18 (2.Ç 2018) belgelerini işliyor.

Bkz. Taahhüt 5988eb6 , taahhüt 45fa195 (26 Mar 2018) Ævar Arnfjörð Bjarmason ( avar) .
^{(Göre Birleştirilmiş Junio Cı Hamano - gitster- içinde işlemek d877975 , 11 Nisan 2018)}

doc hash-function-transition: SHAttered'ın ne anlama geldiğini açıklığa kavuşturun

Git için SHAttered saldırısının ne anlama geldiğini açıklamaya çalışın.
Metnin önceki sürümü, Git'in zaten bu özel saldırı için bir azaltıcılığa sahip olduğundan bahsetmiyordu, SHAttered araştırmacılarının kriptanaltik çarpışma saldırılarını tespit edeceğini iddia ediyor.

Bazı nüansları yanlış anlamış olabilirim, ancak bildiğim kadarıyla bu yeni metin git'teki SHA-1 ile mevcut durumu doğru bir şekilde özetliyor. Yani git artık SHA-1'i kullanmıyor, Hardened-SHA-1'i kullanıyor (sadece% 99.99999999999 ... aynı çıktıları üretiyorlar).

Dolayısıyla önceki metin şu iddiada yanlıştı:

[...] Sonuç olarak [SHAttered], SHA-1 artık kriptografik olarak güvenli kabul edilemez [...]

Konu bu değil. SHAttered'a karşı bir hafifletmemiz var, ancakNewHash SHA-1 veya Hardened-SHA-1'de gelecekteki güvenlik açıklarına karşı harekete geçmenin ihtiyatlı olduğunu düşünüyoruz .

Böylece yeni belgeler şu şekildedir:

Git v2.13.0 ve sonraki sürümler, varsayılan olarak, SHAttered saldırısına karşı savunmasız olmayan, sertleştirilmiş bir SHA-1 uygulamasına taşındı.

Dolayısıyla Git aslında SHA-1 olmayan yeni bir karmaya taşındı ve güvenlik açıklarını paylaşmadı, yeni karma işlevi SHAttered tarafından yayınlanan iki PDF dışında bilinen tüm girdiler için tam olarak aynı çıktıyı üretiyor araştırmacılar ve yeni uygulama (bu araştırmacılar tarafından yazılmıştır) gelecekteki kriptanaltik çarpışma saldırılarını tespit ettiğini iddia ediyor.

Ne olursa olsun, SHA-1'in herhangi bir varyantını yeni bir karmaya taşımak akıllıca sayılır. Gelecekte SHA-1'e yönelik saldırıların gelecekte yayınlanmayacağına dair bir garanti yoktur ve bu saldırıların uygulanabilir hafifletici etkileri olmayabilir.

SHA-1 ve varyantları gerçekten kırılmış olsaydı, Git'in hash işlevi artık kriptografik olarak güvenli kabul edilemezdi. Bu, karma değerlerin iletişimini etkileyecektir, çünkü belirli bir karma değerin, konuşmacının amaçladığı bilinen iyi içerik sürümünü temsil ettiğine güvenemedik.

Not: Şimdi aynı belge (3. Çeyrek 2018, Git 2.19) "yeni karmayı" SHA-256 olarak açıkça referans almaktadır : bkz. " Git neden daha modern SHA kullanmıyor? ".

Google artık SHA-1 çarpışmasının belirli ön koşullar altında mümkün olduğunu iddia ediyor: https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html

Git dosya bütünlüğünü kontrol etmek için SHA-1 kullandığından, git'deki dosya bütünlüğünün tehlikeye atıldığı anlamına gelir.

IMO, git kasıtlı çarpışma artık mümkün olduğundan kesinlikle daha iyi bir karma algoritması kullanmalıdır.

Bir karma çarpışma o kadar düşüktür ki, tamamen akıl almazdır! Dünyanın dört bir yanındaki bilim adamları bir tanesine ulaşmak için çok çalışıyorlar, ancak henüz yönetemediler. Yine de MD5 gibi bazı algoritmalar için başarılı oldular.

Olasılıklar nelerdir?

SHA-256 , 2 ^ 256 olası karmaya sahiptir. Bu yaklaşık 10 ^ 78'dir . Ya da daha grafik olmak gerekirse, çarpışma olasılığı yaklaşık

1: 100000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000

Piyango kazanma şansı hakkındadır 14 Mio: 1 . SHA-256 ile çarpışma şansı arka arkaya 11 gün piyango kazanmak gibidir !

Matematik açıklama: 14000000 ^ 11 ~ 2 ^ 256

Ayrıca, evrende yaklaşık 10 ^ 80 atom vardır. Bu, SHA-256 kombinasyonlarından sadece 100 kat daha fazla.

Başarılı MD5 çarpışması

MD5 için bile şans çok düşük. Yine de, matematikçiler bir çarpışma yaratmayı başardılar:

d131dd02c5e6eec4 693d9a0698aff95c 2fcab5 8 712467eab 4004583eb8fb7f89
55ad340609f4b302 83e4888325 7 1415a 085125e8f7cdc99f d91dbdf280373c5b
d8823e3156348f5b ae6dacd436c919c6 dd53e2 b 487da03fd 02396306d248cda0
e99f33420f577ee8 ce54b67080 a 80d1e c69821bcb6a88393 96f965 2 b6ff72a70

ile aynı MD5'e sahiptir

d131dd02c5e6eec4 693d9a0698aff95c 2fcab5 0 712467eab 4004583eb8fb7f89
55ad340609f4b302 83e4888325 f 1415a 085125e8f7cdc99f d91dbd7280373c5b
d8823e3156348f5b ae6dacd436c919c6 dd53e2 3 487da03fd 02396306d248cda0
e99f33420f577ee8 ce54b67080 2 80d1e c69821bcb6a88393 96f965 bir b6ff72a70

Bu, algoritmasının kırıldığı için MD5'in daha az güvenli olduğu anlamına gelmez. Bilerek MD5 çarpışmaları oluşturabilirsiniz, ancak yanlışlıkla MD5 çarpışması olasılığı hala 2 ^ 128'dir ve bu hala çok fazladır.

Sonuç

Çarpışmalar hakkında tek bir endişe duymanıza gerek yok. Hashing algoritmaları, dosya benzerliğini kontrol etmenin ikinci en güvenli yoludur. Tek daha güvenli yol ikili bir karşılaştırmadır.

Sanırım şimdi ne olacağını biliyoruz - deponuzun bozulmasını beklemelisiniz ( kaynak ).

Kısa süre önce bir BSD tartışma grubunda 2013-04-29 tarihli bir yayın buldum

http://openbsd-archive.7691.n7.nabble.com/Why-does-OpenBSD-use-CVS-td226952.html

afişin iddia ettiği yer:

Git rebase'i kullanarak bir kez karma bir çarpışmaya girdim.

Ne yazık ki, iddiasıyla ilgili hiçbir kanıt sunmuyor. Ama belki onunla iletişime geçmeye ve ona bu sözde olayı sormaya çalışıyorsun.

Ancak daha genel bir düzeyde, doğum günü saldırısından dolayı, SHA-1 karma çarpışma şansı 1'dir (2, 80).

Bu kulağa çok fazla geliyor ve kesinlikle dünyanın tüm Git depolarında bulunan tek tek dosyaların toplam sürüm sayısından çok daha fazla.

Ancak, bu yalnızca sürüm geçmişinde kalan sürümler için geçerlidir.

Bir geliştirici yeniden temellendirmeye çok fazla güveniyorsa, bir şube için her yeniden iskan çalıştırıldığında, o dalın tüm sürümlerindeki (veya dalın yeniden temel alan kısmındaki) tüm taahhütler yeni karmalar alır. Aynı durum "git filter-branch" ile yapılan her dosya için de geçerlidir. Bu nedenle, "rebase" ve "filtre dalı", hepsi gerçekte tutulmamasına rağmen, zaman içinde üretilen karma sayısı için büyük çarpanlar olabilir: Sık sık, yeniden temellendirdikten sonra (özellikle bir dalı "temizlemek" amacıyla) ), orijinal şube atılır.

Ancak çarpışma, rebase veya filtre dalı sırasında meydana gelirse, yine de olumsuz etkileri olabilir.

Başka bir şey git depolarındaki toplam karma varlık sayısını tahmin etmek ve bunların pow'den ne kadar uzakta olduklarını görmek olacaktır (2, 80).

Diyelim ki yaklaşık 8 milyar insanımız var ve hepsi git koşuyor ve eşyalarını kişi başına 100 git deposunda tutuyor. Ayrıca, ortalama deponun 100 taahhüt ve 10 dosya olduğunu varsayalım ve bu dosyalardan yalnızca biri işlem başına değişir.

Her revizyon için, ağaç nesnesi ve işleme nesnesinin kendisi için en az bir karmamız vardır. Değişen dosya ile birlikte her revizyon için 3 karma, dolayısıyla depo başına 300 karmaya sahibiz.

8 milyar insanın 100 deposu için bu hala pow'den (2, 80) uzak olan pow (2, 47) verir.

Bununla birlikte, bu yukarıda belirtilen çarpma etkisini içermez, çünkü bu tahmine nasıl dahil edileceğimden emin değilim. Belki de bir çarpışma olasılığını önemli ölçüde artırabilir. Özellikle uzun bir taahhüt geçmişinin (Linux Çekirdeği gibi) birçok insan tarafından küçük değişiklikler için yeniden kullanıldığı, ancak yine de etkilenen tüm taahhütler için farklı karmalar oluşturan çok büyük depolar varsa.