Git neden daha modern SHA kullanmıyor?

Git'in revizyon için kimlik olarak SHA-1 özetini kullandığını okudum. Neden SHA'nın daha modern bir sürümünü kullanmıyor?

Neden SHA'nın daha modern bir sürümünü kullanmıyor?

Aralık 2017: Olacak. Ve Git 2.16 (Q1 2018), bu amacı gösteren ve uygulayan ilk sürümdür.

Not: Aşağıdaki Git 2.19'a bakın: SHA-256 olacaktır .

Git 2.16, Git'te hangi hash fonksiyonunun kullanıldığını tanımlamak için bir altyapı önerecek ve çeşitli kod yollarında bunu eklemek için bir çaba göstermeye başlayacaktır.

Bkz c250e02 taahhüt tarafından (28 Kas 2017) ( ``) Ramsay Jones .
See commit eb0ccfd , commit 78a6766 , commit f50e766 , commit abade65 (12 Kas 2017) by brian m. carlson ( bk2204) .
^{(Göre Birleştirilmiş - Junio Cı Hamano gitster- içinde 721cc43 tamamlama 2017 13 Ara)}

Karma algoritmayı temsil eden yapı ekleyin

Gelecekte ek bir karma algoritmayı desteklemek istediğimizden, bir karma algoritmayı ve onunla birlikte gitmesi gereken tüm verileri temsil eden bir yapı ekleyin . Karma algoritmaların kolay numaralandırılmasına izin vermek için
bir sabit ekleyin .
Uygulamak işlevitypedefs bu API ile uyumlu mevcut SHA1 fonksiyonları için soyut herhangi karma algoritması tarafından kullanılabilen API ve mahfazalar oluşturmak için.

İkili boyutun yanı sıra onaltılık boyut için bir değer gösterin .
Biri her zaman diğerinin iki katı olacak olsa da, iki değerin ikisi de kod tabanı boyunca son derece yaygın olarak kullanılır ve her ikisinin de daha iyi okunabilirlik sağlaması sağlanır.

Boş nesne kimliği için karma algoritma yapısına bir giriş dahil etmeyin.
Bu değer tamamen sıfır olduğu için, uygun şekilde boyutlandırılmış, tümü sıfır olan herhangi bir nesne kimliği kullanılabilir ve hash başına belirli bir tanesini depolamaya gerek yoktur.

Mevcut hash fonksiyonu geçiş planı, kullanıcıdan SHA-1 veya NewHash formatında olabilecek girdileri kabul edeceğimiz bir zamanı öngörmektedir.
Kullanıcının hangisini sağladığını bilemediğimizden , doğru değeri yukarı aramamız gerektiğini belirtmemize izin vermek için bilinmeyen algoritmayı temsil eden bir sabit ekleyin .

Karma algoritma desteğini depo kurulumuyla entegre edin

Git'in gelecekteki sürümlerinde, ek bir karma algoritmayı desteklemeyi planlıyoruz.
Karma algoritmaların numaralandırmasını depo kurulumuyla entegre edin ve yapı havuzundaki numaralandırılmış verilere bir işaretçi depolayın .
Elbette, şu anda yalnızca SHA-1'i destekliyoruz, bu nedenle bu değeri read_repository_format .
Gelecekte, bu değeri yapılandırmadan sıralayacağız.

Global depodaki yapı işaretçisine işaret eden bir sabitthe_hash_algo ekleyin hash_algo.
Bunun, öğeleri kullanıcıya görüntülemek için kullanılan karma değil, verileri diske serileştirmek için kullanılan karma değer olduğuna dikkat edin.
Geçiş planı, bunların farklı olabileceğini öngörüyor. Bu durumu sağlamak için
gelecekte (diyelim ki ui_hash_algo) ek bir unsur ekleyebiliriz .

Git 2.19 (Q3 2018) için Ağustos 2018 güncellemesinde Git , NewHash olarak SHA- 256'yı seçecek gibi görünüyor.

Bkz. Commit 0ed8d8d (04 Ağu 2018), Jonathan Nieder ( artagnon) .
Bkz. Commit 13f5e09 (25 Tem 2018), commitvar Arnfjörð Bjarmason ( avar) .
^{( Junio ​​C Hamano ile birleştirildi - gitster- in commit 34f2297 , 20 Ağu 2018)}

dochash-function-transition : NewHash olarak SHA-256 seçin

Güvenlik açısından bakıldığında, SHA-256, BLAKE2, SHA3-256, K12 ve benzerlerinin benzer güvenlik özelliklerine sahip olduğuna inanılıyor gibi görünüyor.
Güvenlik açısından hepsi iyi seçeneklerdir.

SHA-256'nın birçok avantajı vardır:

• Bir süredir ortalıkta dolaşıyor, yaygın olarak kullanılıyor ve hemen hemen her kripto kitaplığı (OpenSSL, mbedTLS, CryptoNG, SecureTransport, vb.) Tarafından destekleniyor.

• SHA1DC ile karşılaştırdığınızda, çoğu vektörleştirilmiş SHA-256 uygulaması hızlanma olmasa bile gerçekten daha hızlıdır.

• OpenPGP (hatta sanırım CMS) ile imzalar yapıyorsak, SHA-2 kullanacağız, bu nedenle güvenliğimizin iki ayrı algoritmaya bağlı olması mantıklı değil. Birine güvenebildiğimizde tek başına güvenliği kırabiliriz.

Yani SHA-256 öyle .
Bunu söylemek için karma işlev geçiş tasarım belgesini güncelleyin.

Bu yamadan sonra, içinde değişken adı NewHash olarak 2008'den itibaren ilgisiz kullanım dışında " " dizesinin kalan örneği kalmadı .t/t9700/test.pl

Git 2.20 (2018 4. Çeyrek) ile SHA 256'ya geçişin devam ettiğini görebilirsiniz:

Bkz 0d7c419 işlemek , dda6346 işlemek , eccb5a5 işlemek , 93eb00f işlemek , d8a3a69 işlemek , fbd0e37 taahhüt , f690b6b işlemek , 49d1660 taahhüt , 268babd taahhüt , fa13080 taahhüt , 7b5e614 taahhüt , 58ce21b işlemek , 2f0c9e9 taahhüt , 825544a taahhüt tarafından (15 Ekim 2018) Brian m . carlson ( bk2204) .
Bkz. Commit 6afedba (15 Ekim 2018), SZEDER Gábor ( szeder) .
^{(BirleştirenJunio C Hamano - gitster- içinde d829d49 işlemek , 30 Ekim 2018)}

sabit kodlu sabitleri değiştirin

40 tabanlı birkaç sabiti uygun şekilde GIT_MAX_HEXSZveya referanslarıyla değiştirin the_hash_algo.
Tüm kullanımları dönüştürme GIT_SHA1_HEXSZkullanmak the_hash_algoonlar herhangi bir karma uzunluğuna uygun şekilde yerleştirin.
Onaltılık nesne kimliğinin boyutu için sabit kodlanmış bir sabit kullanmak yerine parse_oid_hex, ayrıştırılmış nesne kimliğinden sonraki noktalardan hesaplanan işaretçiyi kullanmak için geçiş yapın .

GIT_SHA1_HEXSZayrıca Git 2.22 (Q2 2019) ile kaldırılır / değiştirilir ve d4e568b işlenir .

Bu geçiş, sha-256 karması ekleyen ve Git'i "NewHash" ile oluşturmaya izin vermek için kodun içinden geçiren Git 2.21 (Q1 2019) ile devam ediyor.

Bkz 4b4e291 işlemek , 27dc04c işlemek , 13eeedb işlemek , c166599 işlemek , 37649b7 taahhüt , a2ce0a7 işlemek , 50c817e taahhüt , 9a3a0ff işlemek , 0dab712 taahhüt , 47edb64 taahhüt (2018 14 Kas) ve 2f90b9d işlemek , 1ccf07c taahhüt tarafından (22 Ekim 2018) Brian m . carlson ( bk2204) .
^{(Göre Birleştirilmiş - Junio Cı Hamano gitster- içinde 33e4ae9 tamamlama 2019 29 Ara)}

SHA-256 desteğinin temel uygulamasını ekleyin (Şubat 2019)

SHA-1 zayıf ve yeni bir hash fonksiyonuna geçmemiz gerekiyor.
Bir süredir bu yeni işlevi olarak adlandırdık NewHash.
Yakın zamanda SHA-256'yı seçmeyeNewHash karar verdik .
SHA-256 seçiminin arkasındaki nedenler bu iş parçacığında ve karma işlevi geçiş belgesinin kaydetme geçmişinde özetlenmiştir .

libtomcryptKamu malı olan temel bir SHA-256 temel uygulaması ekleyin .
Optimize edin ve kodlama standartlarımızı karşılayacak şekilde yeniden yapılandırın.
Güncellemeyi ve son işlevleri SHA-1 blok uygulamasından alın, çünkü bunların tüm derleyicilerde doğru çalıştığını biliyoruz. Bu uygulama SHA-1'den daha yavaştır, ancak daha iyi performans gösteren uygulamalar gelecekteki taahhütlerde tanıtılacaktır.

Karma algoritmalar listesinde SHA-256'yı bağlayın ve algoritmanın doğru çalıştığını gösteren bir test ekleyin.

Bu yama ile Git'te SHA-256 kullanmaya geçiş yapmanın hala mümkün olmadığını unutmayın.
Daha büyük bir karma algoritmayı işlemek için kodu hazırlamak için ek yamalara ihtiyaç vardır ve daha fazla test düzeltmesi gereklidir.

hash: OpenSSL kullanarak bir SHA-256 uygulaması ekleyin

SHA-1 için halihazırda mevcut OpenSSL rutinlerimiz var, bu nedenle SHA-256 için de rutinler ekleyin.

Core i7-6600U'da, bu SHA-256 uygulaması, SHA1DC SHA-1 uygulamasına uygun şekilde karşılaştırır:

SHA-1: 157 MiB/s (64 byte chunks); 337 MiB/s (16 KiB chunks)
SHA-256: 165 MiB/s (64 byte chunks); 408 MiB/s (16 KiB chunks)

sha256: kullanarak bir SHA-256 uygulaması ekleyin libgcrypt

Genel olarak, montajda yazılan kriptografik rutinlerden C'den daha iyi performans elde edilir ve bu SHA-256 için de geçerlidir.
Ayrıca, çoğu Linux dağıtımı, lisanslama nedenleriyle OpenSSL'ye bağlı Git'i dağıtamaz.

GnuPG'ye libgcryptbağımlı olduğu için GnuPG'li çoğu sistemde de olacaktır .
libgcryptbirkaç KiB ve daha büyük mesajlar için SHA1DC uygulamasından daha hızlıdır.

Karşılaştırma için, Core i7-6600U'da bu uygulama 355 MiB / s'de 16 KiB parçasını işlerken, SHA1DC 337 MiB / s'de eşdeğer parçaları işler.

Ayrıca libgcrypt, GPL ile uyumlu olan LGPL 2.1 altında lisanslanmıştır. Libgcrypt kullanan bir SHA-256 uygulaması ekleyin.

Yükseltme çalışması Git 2.24 ile devam ediyor (Q4 2019)

Bkz aaa95df işlemek , be8e172 taahhüt , 3f34d70 taahhüt , fc06be3 taahhüt , 69fa337 taahhüt , 3a4d7aa işlemek , e0cb7cd işlemek , 8d4d86b işlemek , f6ca67d işlemek , dd336a5 işlemek , 894c0f6 taahhüt , 4439c7a işlemek , 95518fa taahhüt , e84f357 taahhüt , fe9fec4 işlemek , 976ff7e işlemek , işlemek 703d2d4 , commit 9d958cc , commit 7962e04 , commit ücreti4930(18 Ağu 2019) yazan brian m. carlson ( bk2204) .
^{(Göre Birleştirilmiş - Junio Cı Hamano gitster- içinde 676278f tamamlama 2019 Ekim 11)}

GIT_SHA1_HEXSZSabit kodlanmış sabitleri kullanmak yerine kullanmaya geçin the_hash_algo.

Git 2.26 (Q1 2020) ile, test komut dosyaları , nesne adlarının SHA-256'yı kullanacağı gün için hazırdır.

Bkz 277eb5a işlemek , 44b6c05 taahhüt , 7a868c5 taahhüt , 1b8f39f işlemek , a8c17e3 işlemek , 8320722 taahhüt , 74ad99b işlemek , ba1be1a işlemek , cba472d işlemek , 82d5aeb işlemek , işlemek 3c5e65c , 235d3cd taahhüt , 1d86c8f işlemek , 525a7f1 taahhüt , 7a1bcb2 işlemek , cb78f4f işlemek , işlemek 717c939 , işleme 08a9dd8 , işleme 215b60b , işleme 194264c(21 Ara 2019) Yazanbk2204 : Brian m. carlson ( ) .
^{( Junio ​​C Hamanogitster tarafından birleştirildi - - in commit f52ab33 , 05 Şub 2020)}

Misal:

t4204: karma boyutunu bağımsız yapın

^{İmza: Brian m. Carlson}

$OID_REGEXSabit kodlanmış bir normal ifade yerine kullanın .

Yani, kullanmak yerine:

grep "^[a-f0-9]\{40\} $(git rev-parse HEAD)$" output

Testler kullanıyor

grep "^$OID_REGEX $(git rev-parse HEAD)$" output

Ve brian m tarafından commit bdee9cd'den (13 Mayıs 2018) OID_REGEXgeliyor . carlson ( ) . ^{(Göre Birleştirilmiş Junio Cı Hamano - - içinde 9472b13 tamamlama , 30 May 2018, Git v2.18.0-rc0)}bk2204
gitster

t/test-lib: takdim etmek OID_REGEX

^{İmza: Brian m. Carlson}

Şu anda, $_x40,tam 40 karakterlik onaltılık sabitle eşleşen bir normal ifade içeren bir değişkenimiz var .

Bununla birlikte, ile NewHash40 karakterden uzun nesne kimliklerine sahip olacağız.

Böyle bir durumda $_x40kafa karıştırıcı bir isim olacaktır.

$OID_REGEXGeçerli karmanın uzunluğuna bakılmaksızın, her zaman uygun nesne kimliğiyle eşleşen bir normal ifadeyi yansıtan bir değişken oluşturun .

Ve yine de testler için:

Bkz f303765 işlemek , edf0424 taahhüt , 5db24dc işlemek , d341e08 işlemek , 88ed241 taahhüt , 48c10cc işlemek , f7ae8e6 işlemek , e70649b işlemek , a30f93b işlemek , a79eec2 işlemek , 796d138 taahhüt , 417e45e taahhüt , dfa5f53 işlemek , f743e8f işlemek , 72f936b işlemek , 5df0f11 işlemek , işlemek 07877f3 , 6025e89 işle , 7b1a182 işle , 94db7e3 işle ,commit db12505 (07 Şub 2020) by brian m. carlson ( bk2204) .
^{( Junio ​​C Hamanogitster tarafından birleştirildi - - in commit 5af345a , 17 Şub 2020)}

t5703: testin SHA-256 ile çalışmasını sağlayın

^{İmza: Brian m. Carlson}

Bu test, 40 onaltılık karakter uzunluğunda bir nesne kimliği kullandı ve bu da, karma olarak SHA-256 ile çalıştırıldığında testin yalnızca geçmesine değil, aynı zamanda takılmasına da neden oldu.

Sabit bir kukla nesne ID kullanarak bu değeri değiştirmek test_oid_initve test_oid.

Ayrıca, sabit uzunluk yerine alanlarla kesmeyi kullanarak uygun uzunlukta bir nesne kimliği çıkardığımızdan emin olun.

Bazı the_repositorykod yollarına, depoda çalışmak için bir parametre olarak bir depo örneği verildi, ancak örneği Git 2.26 (Q1 2020) ile temizlenmiş (bir şekilde) olan callees'e geçirdi.

Görmek b98d188 , commit 2dcde20 , commit 7ad5c44 , commit c8123e7 , commit 5ec9b8a , commit a651946 , commit eb999b3 (30 Ocak 2020) by Matheus Tavares ( matheustavares) .
^{( Junio ​​C Hamanogitster tarafından birleştirildi - - in commit 78e67cd , 14 Şub 2020)}

sha1-file: check_object_signature()herhangi bir depoyu işlemeye izin ver

^{İmza: Matheus Tavares}

Arayanlardan bazıları check_object_signature()isteğe bağlı depolar üzerinde çalışabilir, ancak depo bu işleve geçmez. Bunun yerine, the_repositoryher zaman dahili olarak kullanılır.
Olası tutarsızlıkları düzeltmek için, işlevin bir yapı deposu almasına izin verin ve bu arayanların işlenen depoyu iletmesini sağlayın.

Dayalı:

sha1-file: Şifre git_hash_algoiçinhash_object_file()

^{İmza: Matheus Tavares}

hash_object_file()Bir git_hash_algoparametre ekleyerek rastgele depolar üzerinde çalışmaya izin verin . git_hash_algoSöz konusu depodan geçmek için kapsamlarında bir struct depo işaretçisine sahip olan arayanları değiştirin .
Diğer tüm arayanlar için, the_hash_algoadresinde zaten dahili olarak kullanılan iletin hash_object_file().
Bu işlevsellik, aşağıdaki yamada check_object_signature()rasgele depolarda çalışabilmeyi sağlamak için kullanılacaktır (ki bu da object.cparse_object () adresindeki bir tutarsızlığı düzeltmek için kullanılacaktır ).

GÜNCELLEME : Yukarıdaki soru ve bu yanıt 2015 yılına aittir. O zamandan beri Google ilk SHA-1 çarpışmasını duyurdu: https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html

Açıkçası, Git'in neden SHA-1'i kullanmaya devam ettiğini sadece dışarıdan bakarak tahmin edebilirim, ancak bunlar sebeplerden biri olabilir:

1. Git, Linus Torvald'ın eseriydi ve Linus görünüşe göre SHA-1'i şu anda başka bir karma algoritma ile değiştirmek istemiyor.
2. Git'e karşı başarılı SHA-1 çarpışma tabanlı saldırıların, çarpışmaları kendilerinin gerçekleştirmekten çok daha zor olduğunu ve SHA-1'in olması gerekenden daha zayıf olduğunu, tamamen kırılmadığını düşünerek, bu da onu bir en azından bugün uygulanabilir saldırı. Dahası, çarpışan nesne mevcut olandan daha geç gelirse, "başarılı" bir saldırının çok az şey başaracağını, çünkü sonrakinin geçerli olanla aynı olduğu varsayılacağından ve göz ardı edileceğine dikkat çeker (ancak diğerleri şunu belirtmiştir) tersi olabilir).
3. Yazılımın değiştirilmesi, özellikle mevcut altyapı ve taşınması gerekecek mevcut protokollere dayalı veriler olduğunda zaman alıcı ve hataya açıktır. Kriptografik güvenliğin sistemin tek noktası olduğu yazılım ve donanım ürünleri üretenler bile, hala SHA-1 ve diğer zayıf algoritmalardan bazı yerlerde uzaklaşma sürecindedir. Tüm bu sabit kodlu unsigned char[20]arabellekleri hayal edin ;-), kriptografik çeviklik için daha sonra uyarlamaktansa başlangıçta programlamak çok daha kolaydır.
4. SHA-1'in performansı, çeşitli SHA-2 hash'lerinden daha iyidir (muhtemelen şu anda bir anlaşma bozacak kadar değil, ancak belki de 10 yıl önce bir çakışma noktasıydı) ve SHA-2'nin depolama boyutu daha büyüktür .

Bazı bağlantılar:

• Git'te bir çarpışma meydana gelirse ne olacağına dair Stackoverflow sorusu
• Ana SHA-1 zayıflığının 2005 yılında bilinmesinden birkaç ay sonra Linus'tan konuyla ilgili kısa bir yorum gösteren haber grubu gönderisi
• 2006'da zayıflığı ve sha-256'ya olası geçişi (Linus'un yanıtlarıyla) tartışan bir başlık
• SHA-1'in kullanımdan kaldırılmasına ilişkin NIST ifadesi ve "daha güçlü SHA-2 karma işlevi ailesine hızla geçiş yapılmasını" öneren

Benim kişisel görüşüme göre, pratik saldırılar muhtemelen bir süre ara verirken ve meydana geldiklerinde bile, insanlar muhtemelen karma algoritmanın kendisini değiştirmekten başka yollarla onlara karşı hafifletecekler, eğer güvenliği önemsiyorsanız hata yapmanız gerekir. algoritma seçimlerinizde dikkatli olmak ve güvenlik güçlerinizi sürekli olarak yükseltmek, çünkü saldırganların yetenekleri de yalnızca tek bir yönde ilerliyor, bu nedenle Git'i bir rol model olarak almak akıllıca olmayacaktır, özellikle de amacı SHA-1 kullanımı kriptografik güvenlik anlamına gelmez.

Bu, Mercurial için SHA1'den uzaklaşmanın aciliyetinin bir tartışmasıdır, ancak Git için de geçerlidir: https://www.mercurial-scm.org/wiki/mpm/SHA1

Kısaca: Bugün aşırı derecede titiz değilseniz, sha1'den çok daha kötü güvenlik açıklarına sahipsiniz. Ancak buna rağmen, Mercurial 10 yıl önce sha1'den uzaklaşmaya hazırlanmaya başladı.

SHA1'in halefleri için Mercurial'in veri yapılarını ve protokollerini güçlendirmek için çalışmalar yıllardır devam etmektedir. Depolama alanı, revlog yapımızda 10 yılı aşkın bir süre önce RevlogNG'nin piyasaya sürülmesiyle Mercurial 0.9'da daha büyük karmalar için tahsis edildi. Daha yakın zamanda tanıtılan bundle2 formatı, ağ üzerinden farklı hash türlerinin değişimini desteklemektedir. Geriye kalan tek parça, değiştirme işlevi seçimi ve geriye dönük uyumluluk stratejisinin seçilmesidir.

Git, Mercurial'den önce sha1'den uzaklaşmazsa, hg-git ile yerel bir Mercurial aynası bulundurarak her zaman başka bir güvenlik düzeyi ekleyebilirsiniz .

Artık daha güçlü bir hash'e geçiş planı var , bu yüzden gelecekte SHA-1'den daha modern bir hash kullanacak gibi görünüyor. Gönderen akım geçiş planı :

Dikkate alınan bazı karmalar SHA-256, SHA-512/256, SHA-256x16, K12 ve BLAKE2bp-256'dır