Mengapa Git tidak menggunakan SHA yang lebih modern?

Saya membaca tentang bahwa Git menggunakan intisari SHA-1 sebagai ID untuk revisi. Mengapa tidak menggunakan versi SHA yang lebih modern?

Mengapa tidak menggunakan versi SHA yang lebih modern?

Desember 2017: Itu akan. Dan Git 2.16 (Q1 2018) adalah rilis pertama yang mengilustrasikan dan mengimplementasikan maksud tersebut.

Catatan: lihat Git 2.19 di bawah ini: SHA-256 .

Git 2.16 akan mengusulkan infrastruktur untuk mendefinisikan fungsi hash apa yang digunakan di Git, dan akan memulai upaya untuk menyelaraskannya di berbagai jalur kode.

Lihat commit c250e02 (28 Nov 2017) oleh Ramsay Jones (``) .
Lihat commit eb0ccfd , commit 78a6766 , commit f50e766 , commit abade65 (12 Nov 2017) oleh brian m. carlson ( bk2204) .
^{(Digabung oleh Junio ​​C Hamano - gitster- di commit 721cc43 , 13 Des 2017)}

Tambahkan struktur yang mewakili algoritme hash

Karena di masa mendatang kami ingin mendukung algoritme hash tambahan, tambahkan struktur yang mewakili algoritme hash dan semua data yang harus disertakan dengannya .
Tambahkan konstanta untuk memudahkan penghitungan algoritme hash .
Menerapkan fungsitypedefs untuk membuat API abstrak yang dapat digunakan oleh algoritme hash apa pun, dan pembungkus untuk fungsi SHA1 yang ada yang sesuai dengan API ini.

Paparkan nilai untuk ukuran hex serta ukuran biner .
Meskipun yang satu akan selalu dua kali yang lain, kedua nilai tersebut digunakan secara sangat umum di seluruh basis kode dan menyediakan keduanya untuk meningkatkan keterbacaan.

Jangan menyertakan entri dalam struktur algoritme hash untuk ID objek null.
Karena nilai ini semuanya nol, ID objek semua-nol yang berukuran sesuai dapat digunakan, dan tidak perlu menyimpan yang diberikan pada basis per-hash.

Rencana transisi fungsi hash saat ini membayangkan waktu ketika kami akan menerima masukan dari pengguna yang mungkin dalam SHA-1 atau dalam format NewHash.
Karena kami tidak dapat mengetahui pengguna mana yang telah menyediakan, tambahkan konstanta yang mewakili algoritme yang tidak diketahui untuk memungkinkan kami menunjukkan bahwa kami harus mencari nilai yang benar.

Integrasikan dukungan algoritma hash dengan penyiapan repo

Di versi Git yang akan datang, kami berencana untuk mendukung algoritme hash tambahan.
Integrasikan pencacahan algoritme hash dengan penyiapan repositori, dan simpan penunjuk ke data yang disebutkan di repositori struct .
Tentu saja, saat ini kami hanya mendukung SHA-1, jadi hard-code nilai ini read_repository_format .
Nantinya, kami akan menghitung nilai ini dari konfigurasi.

Tambahkan konstanta,the_hash_algo yang menunjuk ke hash_algopenunjuk struktur di repositori global.
Perhatikan bahwa ini adalah hash yang digunakan untuk membuat serial data ke disk, bukan hash yang digunakan untuk menampilkan item kepada pengguna.
Rencana transisi mengantisipasi bahwa ini mungkin berbeda.
Kita bisa menambahkan elemen tambahan di masa depan (katakanlah, ui_hash_algo) untuk menyediakan kasus ini.

Update Agustus 2018, untuk Git 2.19 (Q3 2018), Git sepertinya memilih SHA-256 sebagai NewHash.

Lihat commit 0ed8d8d (04 Agustus 2018) oleh Jonathan Nieder ( artagnon) .
Lihat commit 13f5e09 (25 Jul 2018) oleh Ævar Arnfjörð Bjarmason ( avar) .
^{(Digabung oleh Junio ​​C Hamano - gitster- di commit 34f2297 , 20 Agustus 2018)}

dochash-function-transition : pilih SHA-256 sebagai NewHash

Dari perspektif keamanan, tampaknya SHA-256, BLAKE2, SHA3-256, K12, dan seterusnya diyakini memiliki properti keamanan yang serupa.
Semuanya adalah opsi yang bagus dari sudut pandang keamanan.

SHA-256 memiliki sejumlah keunggulan:

• Ini telah ada untuk sementara waktu, digunakan secara luas, dan didukung oleh hampir semua pustaka kripto (OpenSSL, mbedTLS, CryptoNG, SecureTransport, dll).

• Jika Anda membandingkan dengan SHA1DC, sebagian besar implementasi SHA-256 vektor memang lebih cepat, bahkan tanpa akselerasi.

• Jika kita membuat tanda tangan dengan OpenPGP (atau bahkan, saya kira, CMS), kita akan menggunakan SHA-2, jadi tidak masuk akal jika keamanan kita bergantung pada dua algoritma terpisah ketika salah satu dari mereka sendirian bisa merusak keamanan ketika kita hanya bisa bergantung pada satu.

Jadi SHA-256 itu .
Perbarui dokumen desain transisi fungsi hash untuk mengatakannya.

Setelah tambalan ini, tidak ada contoh string " NewHash" yang tersisa , kecuali untuk penggunaan yang tidak terkait dari tahun 2008 sebagai nama variabel di t/t9700/test.pl .

Anda dapat melihat transisi ke SHA 256 ini sedang berlangsung dengan Git 2.20 (K4 2018):

Lihat komit 0d7c419 , komit dda6346 , komit eccb5a5 , komit 93eb00f , komit d8a3a69 , komit fbd0e37 , komit f690b6b , komit 49d1660 , komit 268babd , komit fa13080 , komit 7b5e614 , komit 58ce21b , komit 2f0c9e9 , komit 825544a (15 Oktober 2018) oleh brian m . carlson ( bk2204) .
Lihat commit 6afedba (15 Okt 2018) oleh SZEDER Gábor ( szeder) .
^{(Digabung olehJunio ​​C Hamano - gitster- di commit d829d49 , 30 Okt 2018)}

ganti konstanta hard-code

Ganti beberapa konstanta berbasis 40 dengan referensi ke GIT_MAX_HEXSZatau the_hash_algo, jika sesuai.
Ubah semua penggunaan yang GIT_SHA1_HEXSZakan digunakan the_hash_algosehingga sesuai untuk setiap panjang hash yang diberikan.
Alih-alih menggunakan konstanta hard-code untuk ukuran ID objek hex, alihkan untuk menggunakan penunjuk yang dihitung dari parse_oid_hextitik itu setelah ID objek yang diurai.

GIT_SHA1_HEXSZselanjutnya dihapus / diganti dengan Git 2.22 (Kuartal 2 2019) dan lakukan d4e568b .

Transisi itu berlanjut dengan Git 2.21 (Kuartal 1 2019), yang menambahkan hash sha-256 dan menghubungkannya melalui kode untuk memungkinkan pembuatan Git dengan "NewHash".

Lihat komit 4b4e291 , komit 27dc04c , komit 13eeedb , komit c166599 , komit 37649b7 , komit a2ce0a7 , komit 50c817e , komit 9a3a0ff , komit 0dab712 , komit 47edb64 (14 Nov 2018), dan komit 2f90b9d , komit 1ccf07c (22 Oktober 2018) oleh brian m . carlson ( bk2204) .
^{(Digabung oleh Junio ​​C Hamano - gitster- di commit 33e4ae9 , 29 Jan 2019)}

Tambahkan implementasi dasar dukungan SHA-256 (Feb. 2019)

SHA-1 lemah dan kita perlu beralih ke fungsi hash baru.
Untuk beberapa waktu, kami menyebut fungsi baru ini sebagai NewHash.
Baru-baru ini, kami memutuskan untuk memilih SHA-256 sebagaiNewHash .
Alasan di balik pilihan SHA-256 diuraikan di utas ini dan dalam riwayat komit untuk dokumen transisi fungsi hash.

Tambahkan implementasi dasar berbasis SHA-256 libtomcrypt, yang berada di domain publik.
Optimalkan dan atur ulang untuk memenuhi standar pengkodean kami.
Tarik pembaruan dan fungsi terakhir dari implementasi blok SHA-1, seperti yang kita ketahui fungsi ini dengan benar dengan semua kompiler. Implementasi ini lebih lambat daripada SHA-1, tetapi implementasi yang lebih berperforma akan diperkenalkan di commit mendatang.

Hubungkan SHA-256 dalam daftar algoritme hash, dan tambahkan pengujian bahwa algoritme tersebut berfungsi dengan benar.

Perhatikan bahwa dengan tambalan ini, masih tidak memungkinkan untuk beralih menggunakan SHA-256 di Git.
Tambalan tambahan diperlukan untuk menyiapkan kode guna menangani algoritme hash yang lebih besar dan diperlukan perbaikan uji lebih lanjut.

hash: tambahkan implementasi SHA-256 menggunakan OpenSSL

Kami sudah memiliki rutinitas OpenSSL yang tersedia untuk SHA-1, jadi tambahkan juga rutinitas untuk SHA-256.

Pada Core i7-6600U, implementasi SHA-256 ini lebih baik dibandingkan dengan implementasi SHA1DC SHA-1:

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: tambahkan implementasi SHA-256 menggunakan libgcrypt

Secara umum, seseorang mendapatkan kinerja yang lebih baik dari rutinitas kriptografi yang ditulis dalam rakitan daripada C, dan ini juga berlaku untuk SHA-256.
Selain itu, sebagian besar distribusi Linux tidak dapat mendistribusikan Git yang ditautkan ke OpenSSL karena alasan lisensi.

Kebanyakan sistem dengan GnuPG juga akan memilikinya libgcrypt, karena ini merupakan ketergantungan GnuPG.
libgcryptjuga lebih cepat daripada implementasi SHA1DC untuk pesan berukuran beberapa KiB dan lebih besar.

Sebagai perbandingan, pada Core i7-6600U, implementasi ini memproses 16 potongan KiB pada 355 MiB / s sementara SHA1DC memproses potongan yang setara pada 337 MiB / s.

Selain itu, libgcrypt dilisensikan di bawah LGPL 2.1, yang kompatibel dengan GPL. Tambahkan implementasi SHA-256 yang menggunakan libgcrypt.

Upaya peningkatan terus berlanjut dengan Git 2.24 (Q4 2019)

Lihat komit aaa95df , komit be8e172 , komit 3f34d70 , komit fc06be3 , komit 69fa337 , komit 3a4d7aa , komit e0cb7cd , komit 8d4d86b , komit f6ca67d , komit dd336a5 , komit 894c0f6 , komit 4439c7a , komit 95518fa , komit e84f357 , komit fe9fec4 , komit 976ff7e , komit 703d2d4 , commit 9d958cc , commit 7962e04 , commit fee4930(18 Aug 2019) oleh Brian m. carlson ( bk2204) .
^{(Digabung oleh Junio ​​C Hamano - gitster- di commit 676278f , 11 Okt 2019)}

Alih-alih menggunakan GIT_SHA1_HEXSZdan konstanta hard-coded, alihkan ke menggunakan the_hash_algo.

Dengan Git 2.26 (K1 2020), skrip pengujian siap untuk hari ketika nama objek akan menggunakan SHA-256.

Lihat komit 277eb5a , komit 44b6c05 , komit 7a868c5 , komit 1b8f39f , komit a8c17e3 , komit 8.320.722 , komit 74ad99b , komit ba1be1a , komit cba472d , komit 82d5aeb , komit 3c5e65c , komit 235d3cd , komit 1d86c8f , komit 525a7f1 , komit 7a1bcb2 , komit cb78f4f , komit 717c939 , commit 08a9dd8 , commit 215b60b , commit 194264c(21 Dec 2019) oleh Brian m. carlson ( bk2204) .
^{(Digabung oleh Junio ​​C Hamano - gitster- di commit f52ab33 , 05 Feb 2020)}

Contoh:

t4204: buat ukuran hash independen

^{Ditandatangani oleh: brian m. carlson}

Gunakan $OID_REGEXsebagai ganti ekspresi reguler hard code.

Jadi, daripada menggunakan:

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

Tes menggunakan

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

Dan OID_REGEXberasal dari commit bdee9cd (13 Mei 2018) oleh Brian m. carlson ( bk2204) .
^{(Digabung oleh Junio ​​C Hamano - gitster- di commit 9472b13 , 30 Mei 2018, Git v2.18.0-rc0)}

t/test-lib: perkenalkan OID_REGEX

^{Ditandatangani oleh: brian m. carlson}

Saat ini kami memiliki variabel, $_x40,yang berisi regex yang cocok dengan konstanta hex 40 karakter penuh.

Namun, dengan NewHash, kita akan memiliki ID objek yang lebih dari 40 karakter.

Dalam kasus seperti itu, $_x40akan menjadi nama yang membingungkan.

Buat $OID_REGEXvariabel yang akan selalu mencerminkan regex yang cocok dengan ID objek yang sesuai, terlepas dari panjang hash saat ini.

Dan, masih untuk tes:

Lihat komit f303765 , komit edf0424 , komit 5db24dc , komit d341e08 , komit 88ed241 , komit 48c10cc , komit f7ae8e6 , komit e70649b , komit a30f93b , komit a79eec2 , komit 796d138 , komit 417e45e , komit dfa5f53 , komit f743e8f , komit 72f936b , komit 5df0f11 , komit 07877f3 , lakukan 6025e89 , lakukan 7b1a182 , lakukan 94db7e3 ,commit db12505 (07 Feb 2020) oleh brian m. carlson ( bk2204) .
^{(Digabung oleh Junio ​​C Hamano - gitster- di commit 5af345a , 17 Feb 2020)}

t5703: buat uji coba dengan SHA-256

^{Ditandatangani oleh: brian m. carlson}

Tes ini menggunakan ID objek yang panjangnya 40 karakter hex, menyebabkan tes tidak hanya lulus, tetapi juga hang, ketika dijalankan dengan SHA-256 sebagai hash.

Ubah nilai ini menjadi ID objek dummy tetap menggunakan test_oid_initdan test_oid.

Selanjutnya, pastikan kami mengekstrak ID objek dengan panjang yang sesuai menggunakan potongan dengan bidang, bukan dengan panjang tetap.

Beberapa jalur kode diberi instance repositori sebagai parameter untuk bekerja di repositori, tetapi meneruskan the_repositoryinstance ke kalendernya, yang telah dibersihkan (agak) dengan Git 2.26 (Q1 2020).

Lihat commit b98d188 , commit 2dcde20 , commit 7ad5c44 , commit c8123e7 , commit 5ec9b8a , commit a651946 , commit eb999b3 (30 Jan 2020) oleh Matheus Tavares ( matheustavares) .
^{(Digabung oleh Junio ​​C Hamano - gitster- di commit 78e67cd , 14 Feb 2020)}

sha1-file: memungkinkan check_object_signature()untuk menangani repo apa pun

^{Ditandatangani oleh: Matheus Tavares}

Beberapa pemanggil check_object_signature()dapat bekerja pada repositori arbitrer, tetapi repo tidak diteruskan ke fungsi ini. Sebaliknya, the_repositoryselalu digunakan secara internal.
Untuk memperbaiki kemungkinan inkonsistensi, izinkan fungsi untuk menerima repositori struct dan membuat pemanggil tersebut meneruskan repo yang sedang ditangani.

Berdasarkan:

sha1-file: lolos git_hash_algokehash_object_file()

^{Ditandatangani oleh: Matheus Tavares}

Izinkan hash_object_file()bekerja pada repositori sewenang-wenang dengan memasukkan git_hash_algoparameter. Ubah pemanggil yang memiliki penunjuk repositori struct dalam ruang lingkup mereka untuk meneruskan git_hash_algodari repo tersebut.
Untuk semua penelepon lainnya, teruskan the_hash_algo, yang sudah digunakan secara internal di hash_object_file().
Fungsionalitas ini akan digunakan dalam tambalan berikut agar check_object_signature()dapat bekerja pada repo sembarang (yang, pada gilirannya, akan digunakan untuk memperbaiki ketidakkonsistenan di object.c: parse_object ()).

PEMBARUAN : Pertanyaan di atas dan jawaban ini berasal dari 2015. Sejak itu Google telah mengumumkan tabrakan SHA-1 pertama: https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html

Jelas saya hanya bisa berspekulasi dari luar mencari tahu mengapa Git terus menggunakan SHA-1, tetapi ini mungkin di antara alasannya:

1. Git adalah kreasi Linus Torvald, dan Linus tampaknya tidak ingin mengganti SHA-1 dengan algoritma hashing lain saat ini.
2. Dia membuat klaim yang masuk akal bahwa serangan berbasis tabrakan SHA-1 yang berhasil terhadap Git jauh lebih sulit daripada mencapai tabrakan itu sendiri, dan mengingat bahwa SHA-1 lebih lemah dari yang seharusnya, tidak sepenuhnya rusak, yang membuatnya jauh dari a serangan yang bisa diterapkan setidaknya hari ini. Selain itu, ia mencatat bahwa serangan "berhasil" akan mencapai sangat sedikit jika objek yang bertabrakan datang lebih lambat dari yang sudah ada, karena yang kemudian hanya akan dianggap sama dengan yang valid dan diabaikan (meskipun yang lain telah menunjukkan bahwa kebalikannya bisa terjadi).
3. Mengubah perangkat lunak memakan waktu dan rawan kesalahan terutama bila ada infrastruktur yang ada dan data berbasis di sekitar protokol yang ada yang harus dimigrasi. Bahkan mereka yang menghasilkan produk perangkat lunak dan perangkat keras di mana keamanan kriptografi adalah satu-satunya titik sistem masih dalam proses migrasi dari SHA-1 dan algoritme lemah lainnya di beberapa tempat. Bayangkan saja semua unsigned char[20]buffer yang di -hardcode itu ada di mana-mana ;-), jauh lebih mudah untuk memprogram kelincahan kriptografi di awal, daripada memperbaikinya nanti.
4. Performa SHA-1 lebih baik daripada berbagai hash SHA-2 (mungkin tidak terlalu menjadi pemecah kesepakatan sekarang, tapi mungkin merupakan poin penting 10 tahun yang lalu), dan ukuran penyimpanan SHA-2 lebih besar .

Beberapa link:

• Stackoverflow mempertanyakan apa yang akan terjadi jika tabrakan memang terjadi di Git
• Postingan grup berita menunjukkan komentar singkat dari Linus tentang masalah ini beberapa bulan setelah kelemahan utama SHA-1 diketahui pada tahun 2005
• Sebuah utas membahas kelemahan dan kemungkinan perpindahan ke sha-256 (dengan balasan dari Linus) pada tahun 2006
• Pernyataan NIST tentang penghentian SHA-1 dan merekomendasikan "untuk beralih dengan cepat ke kelompok SHA-2 yang lebih kuat dari fungsi hash"

Pandangan pribadi saya adalah bahwa sementara serangan praktis mungkin beberapa waktu istirahat, dan bahkan ketika itu terjadi, orang mungkin pada awalnya akan mengurangi terhadap mereka dengan cara selain mengubah algoritma hash itu sendiri, bahwa jika Anda benar-benar peduli dengan keamanan yang seharusnya Anda lakukan. di sisi hati-hati dengan pilihan algoritme Anda, dan terus merevisi ke atas kekuatan keamanan Anda, karena kapabilitas penyerang juga hanya mengarah ke satu arah, jadi tidak bijaksana untuk mengambil Git sebagai model peran, terutama sebagai tujuannya dalam menggunakan SHA-1 tidak dimaksudkan sebagai keamanan kriptografi.

Ini adalah diskusi tentang urgensi migrasi keluar dari SHA1 untuk Mercurial, tetapi juga berlaku untuk Git: https://www.mercurial-scm.org/wiki/mpm/SHA1

Singkatnya: Jika Anda tidak terlalu rajin hari ini, Anda memiliki kerentanan yang jauh lebih buruk daripada sha1. Namun terlepas dari itu, Mercurial memulai lebih dari 10 tahun yang lalu untuk bersiap-siap bermigrasi dari sha1.

pekerjaan telah dilakukan selama bertahun-tahun untuk memperbaiki struktur data dan protokol Mercurial untuk penerus SHA1. Ruang penyimpanan dialokasikan untuk hash yang lebih besar dalam struktur revlog kami lebih dari 10 tahun yang lalu di Mercurial 0.9 dengan diperkenalkannya RevlogNG. Format bundle2 yang diperkenalkan baru-baru ini mendukung pertukaran jenis hash yang berbeda melalui jaringan. Bagian yang tersisa hanyalah pilihan fungsi pengganti dan memilih strategi kompatibilitas mundur.

Jika git tidak bermigrasi dari sha1 sebelum Mercurial melakukannya, Anda selalu dapat menambahkan tingkat keamanan lain dengan menyimpan mirror Mercurial lokal dengan hg-git .

Sekarang sudah ada rencana transisi ke hash yang lebih kuat, jadi sepertinya kedepannya akan menggunakan hash yang lebih modern dari SHA-1. Dari rencana transisi saat ini :

Beberapa hash yang dipertimbangkan adalah SHA-256, SHA-512/256, SHA-256x16, K12, dan BLAKE2bp-256