ทำไม Git ไม่ใช้ SHA ที่ทันสมัยกว่านี้?

ฉันอ่านเกี่ยวกับว่า Git ใช้การย่อย SHA-1 เป็น ID สำหรับการแก้ไข เหตุใดจึงไม่ใช้ SHA เวอร์ชันที่ทันสมัยกว่า

เหตุใดจึงไม่ใช้ SHA เวอร์ชันที่ทันสมัยกว่า

ธันวาคม 2017: มันจะ และ Git 2.16 (Q1 2018) เป็นรุ่นแรกที่แสดงให้เห็นและดำเนินการตามเจตนานั้น

หมายเหตุ: ดู Git 2.19 ด้านล่าง: มันจะเป็นSHA-256

Git 2.16 จะเสนอโครงสร้างพื้นฐานเพื่อกำหนดฟังก์ชันแฮชที่ใช้ใน Git และจะเริ่มต้นความพยายามที่จะดิ่งลงไปใน codepath ต่างๆ

ดูกระทำ c250e02 (28 พฤศจิกายน 2017) โดยRamsay โจนส์ ( ``)
ดูการกระทำ eb0ccfd , กระทำ 78a6766 , กระทำ f50e766 , กระทำ abade65 (12 พ.ย. 2017) โดยbrian m. คาร์ลสัน ( bk2204) .
^{(รวมโดยJunio C Hamano - gitster-ในการกระทำ 721cc43 , 13 ธันวาคม 2017)}

เพิ่มโครงสร้างที่แสดงอัลกอริทึมแฮช

เนื่องจากในอนาคตเราต้องการให้การสนับสนุนอัลกอริทึมกัญชาเพิ่มเติมให้เพิ่มโครงสร้างที่แสดงถึงขั้นตอนวิธีกัญชาและข้อมูลทั้งหมดที่จะต้องไปพร้อมกับมัน
เพิ่มค่าคงที่เพื่อให้สามารถระบุอัลกอริทึมแฮชได้ง่าย
ใช้ฟังก์ชันtypedefsเพื่อสร้างนามธรรม API ที่สามารถใช้โดยอัลกอริธึมแฮชใดก็ได้และ Wrapper สำหรับฟังก์ชัน SHA1 ที่มีอยู่ซึ่งสอดคล้องกับ API นี้

เปิดเผยค่าสำหรับขนาดฐานสิบหกเช่นเดียวกับขนาดไบนารี
แม้ว่าค่าหนึ่งจะเป็นสองเท่าของค่าอื่น ๆ เสมอ แต่ทั้งสองค่าจะถูกใช้โดยทั่วไปอย่างมากตลอดทั้ง codebase และให้โอกาสในการอ่านที่ดีขึ้น

อย่ารวมรายการในโครงสร้างอัลกอริทึมแฮชสำหรับ ID อ็อบเจ็กต์ null
เนื่องจากค่านี้เป็นศูนย์ทั้งหมดจึงสามารถใช้ ID อ็อบเจ็กต์ที่เป็นศูนย์ทั้งหมดที่มีขนาดเหมาะสมและไม่จำเป็นต้องจัดเก็บค่าใดรายการหนึ่งตามจำนวนแฮช

แผนการเปลี่ยนฟังก์ชันแฮชปัจจุบันจะวาดภาพช่วงเวลาที่เราจะยอมรับข้อมูลจากผู้ใช้ซึ่งอาจอยู่ใน SHA-1 หรือในรูปแบบ NewHash
เนื่องจากเราไม่สามารถทราบได้ว่าผู้ใช้ระบุไว้ใดให้เพิ่มค่าคงที่ที่แสดงถึงอัลกอริทึมที่ไม่รู้จักเพื่อให้เราระบุว่าเราต้องค้นหาค่าที่ถูกต้อง

รวมการสนับสนุนอัลกอริทึมแฮชกับการตั้งค่า repo

ใน Git เวอร์ชันต่อ ๆ ไปเราวางแผนที่จะรองรับอัลกอริทึมแฮชเพิ่มเติม
บูรณาการแจงนับของอัลกอริทึมกัญชากับการตั้งค่าพื้นที่เก็บข้อมูลและจัดเก็บชี้ไปยังข้อมูลที่ระบุในพื้นที่เก็บข้อมูล struct
แน่นอนว่าขณะนี้เรารองรับเฉพาะ SHA-1 เท่านั้นดังนั้นจึงฮาร์ดโค้ดค่านี้ในรูปแบบ read_repository_format .
ในอนาคตเราจะแจกแจงค่านี้จากการกำหนดค่า

เพิ่มค่าคงthe_hash_algoที่ซึ่งชี้ไปที่hash_algoตัวชี้โครงสร้างในที่เก็บส่วนกลาง
โปรดทราบว่านี่คือแฮชที่ใช้เพื่อทำให้ข้อมูลเป็นอนุกรมลงในดิสก์ไม่ใช่แฮชที่ใช้เพื่อแสดงรายการต่อผู้ใช้
แผนการเปลี่ยนแปลงคาดว่าสิ่งเหล่านี้อาจแตกต่างกัน
เราสามารถเพิ่มองค์ประกอบเพิ่มเติมในอนาคต (พูดui_hash_algo) เพื่อให้สำหรับกรณีนี้

อัปเดตเดือนสิงหาคม 2018 สำหรับ Git 2.19 (Q3 2018) ดูเหมือนว่า Git จะเลือกSHA-256เป็น NewHash

ดูกระทำ 0ed8d8d (4 สิงหาคม 2018) โดยโจนาธาน Nieder (artagnon )
ดูกระทำ 13f5e09 (25 กรกฎาคม 2018) โดยÆvar Arnfjord Bjarmason (avar )
^{(รวมโดยJunio C Hamano - gitster-ในการกระทำ 34f2297 , 20 สิงหาคม 2018)}

dochash-function-transition : เลือก SHA-256 เป็น NewHash

จากมุมมองด้านความปลอดภัยดูเหมือนว่า SHA-256, BLAKE2, SHA3-256, K12 และอื่น ๆ ล้วนเชื่อว่ามีคุณสมบัติด้านความปลอดภัยที่คล้ายคลึงกัน
ทั้งหมดเป็นตัวเลือกที่ดีจากมุมมองด้านความปลอดภัย

SHA-256 มีข้อดีหลายประการ:

• มีมาระยะหนึ่งแล้วมีการใช้กันอย่างแพร่หลายและได้รับการสนับสนุนโดยไลบรารีการเข้ารหัสลับทุกอัน (OpenSSL, mbedTLS, CryptoNG, SecureTransport ฯลฯ )

• เมื่อคุณเปรียบเทียบกับ SHA1DC การใช้งาน SHA-256 แบบเวกเตอร์ส่วนใหญ่นั้นเร็วกว่าแม้ว่าจะไม่มีการเร่งความเร็วก็ตาม

• หากเรากำลังทำลายเซ็นด้วย OpenPGP (หรือแม้กระทั่งฉันคิดว่า CMS) เราจะใช้ SHA-2 ดังนั้นจึงไม่สมเหตุสมผลที่การรักษาความปลอดภัยของเราจะขึ้นอยู่กับอัลกอริทึมที่แยกจากกันสองแบบเมื่อหนึ่งในนั้น เพียงอย่างเดียวอาจทำลายความปลอดภัยได้เมื่อเราพึ่งพิงได้

ดังนั้น SHA-256 มันเป็น
อัปเดตเอกสารการออกแบบการเปลี่ยนแปลงฟังก์ชันแฮชเพื่อแจ้งให้ทราบ

หลังจากที่แพทช์นี้จะไม่มีกรณีที่เหลืออยู่ของสตริง " NewHash" ยกเว้นสำหรับการใช้งานที่ไม่เกี่ยวข้องจากปี 2008 เป็นชื่อตัวแปรใน t/t9700/test.pl

คุณสามารถเห็นการเปลี่ยนไปใช้ SHA 256 นี้ด้วย Git 2.20 (ไตรมาสที่ 4 ปี 2018):

ดูกระทำ 0d7c419 , กระทำ dda6346 , กระทำ eccb5a5 , กระทำ 93eb00f , กระทำ d8a3a69 , กระทำ fbd0e37 , กระทำ f690b6b , กระทำ 49d1660 , กระทำ 268babd , กระทำ fa13080 , กระทำ 7b5e614 , กระทำ 58ce21b , กระทำ 2f0c9e9 , กระทำ 825544a (15 ตุลาคม 2018) โดยไบรอันเมตร . คาร์ลสัน ( bk2204) .
ดูกระทำ 6afedba (15 ตุลาคม 2018) โดยSzeder Gábor (szeder )
^{(รวมโดยJunio ​​C Hamano - gitster-ในการกระทำ d829d49 , 30 ต.ค. 2018)}

แทนที่ค่าคงที่ฮาร์ดโค้ด

แทนที่ค่าคงที่ฐาน 40 หลายค่าด้วยการอ้างอิงถึงGIT_MAX_HEXSZหรือ the_hash_algoตามความเหมาะสม
แปลงการใช้งานทั้งหมดที่GIT_SHA1_HEXSZจะใช้the_hash_algoเพื่อให้เหมาะสมกับความยาวแฮชที่กำหนด
แทนที่จะใช้ค่าคงที่ฮาร์ดโค้ดสำหรับขนาดของรหัสอ็อบเจ็กต์ฐานสิบหกให้เปลี่ยนไปใช้ตัวชี้ที่คำนวณจากparse_oid_hexจุดนั้นหลังจาก ID อ็อบเจ็กต์ที่แยกวิเคราะห์

GIT_SHA1_HEXSZจะเพิ่มเติมลบ / แทนที่ด้วย Git 2.22 (Q2 2019) และการกระทำ d4e568b

การเปลี่ยนแปลงนั้นดำเนินต่อไปด้วย Git 2.21 (Q1 2019) ซึ่งเพิ่มแฮช sha-256 และเสียบผ่านโค้ดเพื่ออนุญาตให้สร้าง Git ด้วย "NewHash"

ดูกระทำ 4b4e291 , กระทำ 27dc04c , กระทำ 13eeedb , กระทำ c166599 , กระทำ 37649b7 , กระทำ a2ce0a7 , กระทำ 50c817e , กระทำ 9a3a0ff , กระทำ 0dab712 , กระทำ 47edb64 (14 พฤศจิกายน 2018) และกระทำ 2f90b9d , กระทำ 1ccf07c (22 ตุลาคม 2018) โดยไบรอันเมตร . คาร์ลสัน ( bk2204) .
^{(รวมโดยJunio C Hamano - gitster-ในการกระทำ 33e4ae9 , 29 มกราคม 2019)}

เพิ่มการใช้งานฐานของการสนับสนุน SHA-256 (ก.พ. 2019)

SHA-1 อ่อนแอและเราจำเป็นต้องเปลี่ยนไปใช้ฟังก์ชันแฮชใหม่ บางครั้งที่เราได้อ้างถึงฟังก์ชั่นใหม่นี้เป็น
เมื่อเร็ว ๆ นี้เราตัดสินใจเลือก SHA-256 เป็น . เหตุผลเบื้องหลังการเลือก SHA-256 มีระบุไว้ในเธรดนี้และในประวัติการคอมมิตสำหรับเอกสารการเปลี่ยนฟังก์ชันแฮชNewHash
NewHash

เพิ่มการใช้งานพื้นฐานของ SHA-256 ที่ใช้ off libtomcryptซึ่งเป็นสาธารณสมบัติ
เพิ่มประสิทธิภาพและปรับโครงสร้างใหม่เพื่อให้เป็นไปตามมาตรฐานการเข้ารหัสของเรา
ดึงการอัปเดตและฟังก์ชันสุดท้ายจากการใช้งานบล็อก SHA-1 เนื่องจากเราทราบว่าฟังก์ชันเหล่านี้ถูกต้องกับคอมไพเลอร์ทั้งหมด การใช้งานนี้ช้ากว่า SHA-1 แต่จะมีการนำการใช้งานที่มีประสิทธิภาพมากขึ้นมาใช้ในอนาคต

วางสาย SHA-256 ในรายการอัลกอริทึมแฮชและเพิ่มการทดสอบว่าอัลกอริทึมทำงานได้อย่างถูกต้อง

โปรดทราบว่าด้วยแพตช์นี้จะยังไม่สามารถเปลี่ยนไปใช้ SHA-256 ใน Git ได้
จำเป็นต้องมีแพตช์เพิ่มเติมเพื่อเตรียมโค้ดเพื่อจัดการอัลกอริทึมแฮชที่ใหญ่ขึ้นและจำเป็นต้องมีการแก้ไขการทดสอบเพิ่มเติม

hash: เพิ่มการใช้งาน SHA-256 โดยใช้ OpenSSL

เรามีรูทีน OpenSSL สำหรับ SHA-1 อยู่แล้วดังนั้นให้เพิ่มรูทีนสำหรับ SHA-256 ด้วย

บน Core i7-6600U การใช้งาน SHA-256 นี้เปรียบเทียบได้ดีกับการใช้งาน 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: เพิ่มการใช้งาน SHA-256 โดยใช้ libgcrypt

โดยทั่วไปหนึ่งจะได้รับประสิทธิภาพที่ดีขึ้นจากกิจวัตรการเข้ารหัสที่เขียนในแอสเซมบลีมากกว่า C และนี่ก็เป็นจริงสำหรับ SHA-256
นอกจากนี้ลีนุกซ์ส่วนใหญ่ไม่สามารถแจกจ่าย Git ที่เชื่อมโยงกับ OpenSSL ได้ด้วยเหตุผลด้านลิขสิทธิ์

ระบบส่วนใหญ่ที่มี GnuPG ก็จะมีlibgcryptเช่นกันเนื่องจากเป็นการพึ่งพา GnuPG
libgcryptยังเร็วกว่าการใช้งาน SHA1DC สำหรับข้อความที่มีขนาดไม่กี่ KiB ขึ้นไป

สำหรับการเปรียบเทียบบน Core i7-6600U การใช้งานนี้จะประมวลผลชิ้นส่วน 16 KiB ที่ 355 MiB / s ในขณะที่ SHA1DC ประมวลผลชิ้นส่วนที่เท่ากันที่ 337 MiB / s

นอกจากนี้ libgcrypt ยังได้รับอนุญาตภายใต้ LGPL 2.1 ซึ่งเข้ากันได้กับ GPL เพิ่มการใช้งาน SHA-256 ที่ใช้ libgcrypt

ความพยายามในการอัปเกรดดำเนินต่อไปด้วย Git 2.24 (Q4 2019)

ดูกระทำ aaa95df , กระทำ be8e172 , กระทำ 3f34d70 , กระทำ fc06be3 , กระทำ 69fa337 , กระทำ 3a4d7aa , กระทำ e0cb7cd , กระทำ 8d4d86b , กระทำ f6ca67d , กระทำ dd336a5 , กระทำ 894c0f6 , กระทำ 4439c7a , กระทำ 95518fa , กระทำ e84f357 , กระทำ fe9fec4 , กระทำ 976ff7e , กระทำ 703d2d4 , กระทำ 9d958cc , กระทำ 7962e04 , กระทำ fee4930(18 ส.ค. 2562) โดยbrian m. คาร์ลสัน ( bk2204) .
^{(รวมโดยJunio C Hamano - gitster-ในการกระทำ 676278f , 11 ตุลาคม 2019)}

แทนการใช้และค่าคงที่ยากรหัสสลับไปใช้GIT_SHA1_HEXSZthe_hash_algo

ด้วย Git 2.26 (Q1 2020) สคริปต์ทดสอบจะพร้อมสำหรับวันที่ชื่อวัตถุจะใช้ SHA-256

ดูกระทำ 277eb5a , กระทำ 44b6c05 , กระทำ 7a868c5 , กระทำ 1b8f39f , กระทำ a8c17e3 , กระทำ 8320722 , กระทำ 74ad99b , กระทำ ba1be1a , กระทำ cba472d , กระทำ 82d5aeb , กระทำ 3c5e65c , กระทำ 235d3cd , กระทำ 1d86c8f , กระทำ 525a7f1 , กระทำ 7a1bcb2 , กระทำ cb78f4f , กระทำ 717c939 , กระทำ 08a9dd8 , กระทำ 215b60b , กระทำ 194264c(21 ธ.ค. 2562) โดยbrian m. คาร์ลสัน ( bk2204) .
^{(ผสานโดยJunio ​​C Hamano - gitster-ในการกระทำ f52ab33 , 05 ก.พ. 2020)}

ตัวอย่าง:

t4204: ทำให้ขนาดแฮชเป็นอิสระ

^{ลงนามโดย: brian m. คาร์ลสัน}

ใช้$OID_REGEXแทนนิพจน์ทั่วไปแบบฮาร์ดโค้ด

ดังนั้นแทนที่จะใช้:

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

กำลังใช้การทดสอบ

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

และOID_REGEXมาจากการกระทำ bdee9cd (13 พฤษภาคม 2018) โดยbrian m. คาร์ลสัน ( bk2204) .
^{(รวมโดยJunio C Hamano - gitster-ในการกระทำ 9472b13ที่ 30 พฤษภาคม 2018 Git-v2.18.0 RC0)}

t/test-lib: แนะนำ OID_REGEX

^{ลงนามโดย: brian m. คาร์ลสัน}

ขณะนี้เรามีตัวแปร$_x40,ซึ่งมี regex ที่ตรงกับค่าคงที่ฐานสิบหกเต็ม 40 อักขระ

อย่างไรก็ตามด้วยNewHashเราจะมีรหัสออบเจ็กต์ที่ยาวเกิน 40 อักขระ

ในกรณีเช่นนี้$_x40จะเป็นชื่อที่สับสน

สร้าง$OID_REGEXตัวแปรซึ่งจะแสดง regex ที่ตรงกับ ID อ็อบเจ็กต์ที่เหมาะสมเสมอโดยไม่คำนึงถึงความยาวของแฮชปัจจุบัน

และสำหรับการทดสอบ:

ดูกระทำ f303765 , กระทำ edf0424 , กระทำ 5db24dc , กระทำ d341e08 , กระทำ 88ed241 , กระทำ 48c10cc , กระทำ f7ae8e6 , กระทำ e70649b , กระทำ a30f93b , กระทำ a79eec2 , กระทำ 796d138 , กระทำ 417e45e , กระทำ dfa5f53 , กระทำ f743e8f , กระทำ 72f936b , กระทำ 5df0f11 , กระทำ 07877f3 , กระทำ 6025e89 , กระทำ 7b1a182 , กระทำ 94db7e3 ,กระทำ db12505 (07 ก.พ. 2020) โดยbrian m. คาร์ลสัน ( bk2204) .
^{(รวมโดยJunio C Hamano - gitster-ในการกระทำ 5af345a , 17 กุมภาพันธ์ 2020)}

t5703: ทำการทดสอบกับ SHA-256

^{ลงนามโดย: brian m. คาร์ลสัน}

การทดสอบนี้ใช้ ID ออบเจ็กต์ซึ่งมีความยาว 40 อักขระฐานสิบหกทำให้การทดสอบไม่เพียง แต่ไม่ผ่าน แต่จะหยุดทำงานเมื่อรันด้วย SHA-256 เป็นแฮช

เปลี่ยนค่านี้เป็นรหัสวัตถุคงหุ่นใช้และtest_oid_inittest_oid

นอกจากนี้ตรวจสอบให้แน่ใจว่าเราแยก ID ออบเจ็กต์ที่มีความยาวที่เหมาะสมโดยใช้การตัดด้วยฟิลด์แทนความยาวคงที่

codepath บางตัวได้รับอินสแตนซ์ที่เก็บเป็นพารามิเตอร์เพื่อทำงานในที่เก็บ แต่ส่งต่อthe_repositoryอินสแตนซ์ไปยัง callees ซึ่งได้รับการล้างข้อมูล (บ้าง) ด้วย Git 2.26 (Q1 2020)

ดูกระทำ b98d188 , กระทำ 2dcde20 , กระทำ 7ad5c44 , กระทำ c8123e7 , กระทำ 5ec9b8a , กระทำ a651946 , กระทำ eb999b3 (30 มกราคม 2020) โดยMatheus ทาวาเรส (matheustavares )
^{(รวมโดยJunio C Hamano - gitster-ในการกระทำ 78e67cd , 14 กุมภาพันธ์ 2020)}

sha1-file: อนุญาตให้check_object_signature()จัดการ repo ใด ๆ

^{ลงนามโดย: Matheus Tavares}

ผู้โทรบางรายcheck_object_signature()สามารถทำงานบนที่เก็บได้ตามอำเภอใจ แต่ repo ไม่ถูกส่งต่อไปยังฟังก์ชันนี้ แต่the_repositoryจะใช้ภายในเสมอ
ในการแก้ไขความไม่สอดคล้องที่เป็นไปได้ให้อนุญาตให้ฟังก์ชันรับที่เก็บโครงสร้างและกำหนดให้ผู้โทรเหล่านั้นส่งต่อไปยัง repo ที่กำลังจัดการ

ขึ้นอยู่กับ:

sha1-file: ผ่านgit_hash_algoไปยังhash_object_file()

^{ลงนามโดย: Matheus Tavares}

อนุญาตให้hash_object_file()ทำงานกับ repos ตามอำเภอใจโดยการแนะนำgit_hash_algoพารามิเตอร์ เปลี่ยนผู้โทรที่มีตัวชี้ที่เก็บโครงสร้างในขอบเขตเพื่อส่งต่อgit_hash_algoจากที่เก็บดังกล่าว
สำหรับผู้โทรอื่น ๆ ทั้งหมดให้ส่งต่อthe_hash_algoซึ่งมีการใช้งานภายในอยู่hash_object_file()แล้วที่
ฟังก์ชันนี้จะถูกใช้ในแพตช์ต่อไปนี้เพื่อให้check_object_signature()สามารถทำงานกับ repos ตามอำเภอใจ (ซึ่งในทางกลับกันจะถูกใช้เพื่อแก้ไขความไม่สอดคล้องกันที่object.c: parse_object ())

อัปเดต : คำถามข้างต้นและคำตอบนี้มาจากปี 2015 ตั้งแต่นั้นเป็นต้นมา Google ได้ประกาศการชนกันของ SHA-1 ครั้งแรก: https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html

เห็นได้ชัดว่าฉันสามารถคาดเดาได้จากภายนอกเท่านั้นที่มองหาสาเหตุที่ Git ยังคงใช้ SHA-1 ต่อไป แต่สิ่งเหล่านี้อาจเป็นสาเหตุ:

1. Git เป็นการสร้างของ Linus Torvald และ Linus ไม่ต้องการแทนที่ SHA-1 ด้วยอัลกอริธึมการแฮชอื่นในขณะนี้
2. เขากล่าวอ้างที่เป็นไปได้ว่าการโจมตีด้วยการชนกันของ SHA-1 ที่ประสบความสำเร็จกับ Git นั้นยากกว่าการชนกันเองและการพิจารณาว่า SHA-1 นั้นอ่อนแอกว่าที่ควรจะเป็นไม่ใช่หักทั้งหมดซึ่งทำให้มันอยู่ไกลจาก a โจมตีได้อย่างน้อยวันนี้ ยิ่งไปกว่านั้นเขาตั้งข้อสังเกตว่าการโจมตีที่ "ประสบความสำเร็จ" จะเกิดขึ้นน้อยมากหากวัตถุที่ชนกันมาถึงช้ากว่าที่มีอยู่เนื่องจากสิ่งที่เกิดขึ้นในภายหลังจะถือว่าเหมือนกับการโจมตีที่ถูกต้องและถูกเพิกเฉย (แม้ว่าคนอื่น ๆ จะชี้ให้เห็นว่า การย้อนกลับอาจเกิดขึ้นได้)
3. การเปลี่ยนซอฟต์แวร์ใช้เวลานานและเกิดข้อผิดพลาดได้ง่ายโดยเฉพาะอย่างยิ่งเมื่อมีโครงสร้างพื้นฐานและข้อมูลที่มีอยู่ตามโปรโตคอลที่มีอยู่ซึ่งจะต้องถูกโยกย้าย แม้แต่ผู้ที่ผลิตซอฟต์แวร์และผลิตภัณฑ์ฮาร์ดแวร์ที่ความปลอดภัยในการเข้ารหัสเป็นจุดเดียวของระบบก็ยังอยู่ในขั้นตอนการโยกย้ายออกจาก SHA-1 และอัลกอริทึมที่อ่อนแออื่น ๆ ลองนึกภาพunsigned char[20]บัฟเฟอร์ฮาร์ดโค้ดเหล่านี้ทั้งหมดในสถานที่ ;-) มันง่ายกว่ามากในการตั้งโปรแกรมสำหรับความคล่องตัวในการเข้ารหัสตั้งแต่เริ่มต้นแทนที่จะติดตั้งเพิ่มเติมในภายหลัง
4. ประสิทธิภาพของ SHA-1 ดีกว่าแฮช SHA-2 ต่างๆ (อาจจะไม่มากเท่าที่จะเป็นตัวทำลายข้อตกลงในตอนนี้ แต่อาจเป็นจุดยึดเมื่อ 10 ปีก่อน) และขนาดพื้นที่จัดเก็บของ SHA-2 นั้นใหญ่กว่า .

ลิงค์บางส่วน:

• คำถาม Stackoverflow เกี่ยวกับสิ่งที่จะเกิดขึ้นหากเกิดการชนกันใน Git
• โพสต์กลุ่มข่าวแสดงความคิดเห็นสั้น ๆ จาก Linus ในเรื่องนี้สองสามเดือนหลังจากที่จุดอ่อนหลักของ SHA-1 เป็นที่รู้จักในปี 2548
• กระทู้ที่พูดถึงจุดอ่อนและการย้ายไปยัง sha-256 (พร้อมคำตอบจาก Linus) ในปี 2549
• คำสั่ง NIST เกี่ยวกับการเลิกใช้งาน SHA-1 และแนะนำ "ให้เปลี่ยนไปใช้ฟังก์ชันแฮชตระกูล SHA-2 ที่แข็งแกร่งกว่าอย่างรวดเร็ว"

มุมมองส่วนตัวของฉันน่าจะเป็นไปได้ว่าในขณะที่การโจมตีในทางปฏิบัติอาจเป็นช่วงเวลาหนึ่งและแม้ว่าจะเกิดขึ้นในตอนแรกผู้คนก็อาจลดการต่อต้านพวกเขาด้วยวิธีการอื่นนอกเหนือจากการเปลี่ยนอัลกอริทึมการแฮชด้วยตัวเองว่าหากคุณใส่ใจเรื่องความปลอดภัยที่คุณควรทำผิดพลาด ระมัดระวังในการเลือกอัลกอริทึมของคุณและแก้ไขจุดแข็งด้านความปลอดภัยของคุณอย่างต่อเนื่องเนื่องจากความสามารถของผู้โจมตียังดำเนินไปในทิศทางเดียวดังนั้นจึงไม่ควรใช้ Git เป็นแบบอย่างโดยเฉพาะอย่างยิ่งเมื่อมีวัตถุประสงค์ การใช้ SHA-1 ไม่ได้อ้างว่าเป็นการรักษาความปลอดภัยในการเข้ารหัส

นี่คือการอภิปรายเกี่ยวกับความเร่งด่วนในการย้ายออกจาก SHA1 สำหรับ Mercurial แต่จะใช้กับ Git ด้วยเช่นกัน: https://www.mercurial-scm.org/wiki/mpm/SHA1

กล่าวโดยย่อ: หากวันนี้คุณไม่ได้ขี้เกียจมากนักแสดงว่าคุณมีช่องโหว่ที่แย่กว่า sha1 มาก แต่ถึงอย่างนั้น Mercurial ก็เริ่มต้นเมื่อ 10 ปีที่แล้วเพื่อเตรียมพร้อมสำหรับการอพยพออกจาก sha1

งานได้ดำเนินการมาหลายปีเพื่อติดตั้งโครงสร้างข้อมูลและโปรโตคอลของ Mercurial สำหรับผู้สืบทอดของ SHA1 พื้นที่จัดเก็บได้รับการจัดสรรสำหรับแฮชขนาดใหญ่ในโครงสร้าง revlog ของเราเมื่อ 10 ปีก่อนใน Mercurial 0.9 ด้วยการเปิดตัว RevlogNG รูปแบบ Bundle2 ที่เปิดตัวเมื่อเร็ว ๆ นี้สนับสนุนการแลกเปลี่ยนแฮชประเภทต่างๆผ่านเครือข่าย ชิ้นส่วนที่เหลือเพียงชิ้นเดียวคือทางเลือกของฟังก์ชันทดแทนและการเลือกกลยุทธ์ที่เข้ากันได้แบบย้อนกลับ

ถ้าคอมไพล์ไม่ย้ายออกไปจาก sha1 ก่อน Mercurial ไม่คุณก็สามารถเพิ่มระดับการรักษาความปลอดภัยอื่นโดยการรักษากระจก Mercurial ท้องถิ่นที่มีHG-คอมไพล์

ขณะนี้มีแผนการเปลี่ยนแปลงไปสู่แฮชที่แข็งแกร่งขึ้นดังนั้นในอนาคตจะมีการใช้แฮชที่ทันสมัยกว่า SHA-1 จากแผนการเปลี่ยนแปลงปัจจุบัน :

แฮชบางตัวที่อยู่ระหว่างการพิจารณา ได้แก่ SHA-256, SHA-512/256, SHA-256x16, K12 และ BLAKE2bp-256