เหตุใด Git จึงใช้ฟังก์ชั่นแฮชเข้ารหัส

ทำไม Git ถึงใช้ SHA-1ซึ่งเป็นฟังก์ชันแฮชการเข้ารหัสแทนที่จะใช้ฟังก์ชันแฮชที่ไม่ใช่การเข้ารหัสที่เร็วกว่า

คำถามที่เกี่ยวข้อง:

คำถาม Stack Overflow ทำไม Git จึงใช้ SHA-1 เป็นหมายเลขเวอร์ชัน ถามว่าทำไม Git ใช้ SHA-1 ซึ่งต่างจากตัวเลขที่เรียงตามลำดับเพื่อคอมมิท

TLDR;

• ตั้งแต่ปี 2005 ถึงปี 2018 / Git 2.18: SHA-1 (ดูด้านล่าง)
• 2019 จะเปลี่ยนเป็นSHA-256

คุณสามารถตรวจสอบได้จากLinus Torvalds เองเมื่อเขามอบ Git ให้กับ Google ในปี 2550 :
(เน้นที่เหมือง)

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

การมีแฮชที่ดีนั้นดีสำหรับการเชื่อถือข้อมูลของคุณมันมีคุณสมบัติที่ดีอื่น ๆ เช่นกันเมื่อมันหมายถึงเมื่อเราแฮชวัตถุเรารู้ว่าแฮชนั้นมีการกระจายอย่างดีและเราไม่ต้องกังวลกับปัญหาการแจกจ่าย .

ภายในนั้นหมายถึงจุดยืนในการติดตั้งเราสามารถมั่นใจได้ว่าแฮชนั้นดีมากที่เราสามารถใช้อัลกอริทึมการแฮชและรู้ว่าไม่มีกรณีเลวร้าย

ดังนั้นมีเหตุผลบางอย่างที่ชอบด้านการเข้ารหัสเช่นกัน แต่มันเกี่ยวกับความสามารถในการเชื่อถือข้อมูลของคุณ
ฉันรับประกันคุณถ้าคุณใส่ข้อมูลของคุณในคอมไพล์คุณสามารถเชื่อถือได้ว่าห้าปีต่อมาหลังจากที่มันถูกแปลงจาก harddisc ของคุณเป็น DVD เป็นเทคโนโลยีใหม่ ๆ และคุณคัดลอกไปแล้วห้าปีต่อมาคุณสามารถตรวจสอบข้อมูลของคุณได้ ได้รับกลับออกมาเป็นข้อมูลเดียวกันที่แน่นอนที่คุณใส่ใน. และนั่นคือสิ่งที่คุณควรมองหาในแหล่งระบบการจัดการรหัส

อัปเดตธันวาคม 2560 ด้วย Git 2.16 (ไตรมาสที่ 1 ปี 2561): ความพยายามนี้เพื่อสนับสนุน SHA ทางเลือกกำลังดำเนินการอยู่: ดูที่ " ทำไม Git จึงไม่ใช้ SHA ที่ทันสมัยกว่านี้ "

ฉันพูดถึงใน " วิธีคอมไพล์จะจัดการ SHA-1 ชนในหยด? " ที่คุณสามารถสร้างการกระทำด้วยคำนำหน้า SHA1 โดยเฉพาะ(ยังคงพยายามอย่างมากราคาแพง)
แต่ประเด็นก็ยังคงอยู่ตามที่Eric Sinkกล่าวไว้ในหนังสือ " Git: Cryptographic HASH " ( การควบคุมเวอร์ชันตามตัวอย่าง (2011) :

มันค่อนข้างสำคัญที่ DVCS ไม่เคยพบข้อมูลที่แตกต่างกันสองชิ้นที่มีไดเจสต์เดียวกัน โชคดีที่ฟังก์ชันแฮ็คการเข้ารหัสที่ดีได้รับการออกแบบมาเพื่อให้การชนดังกล่าวไม่น่าเกิดขึ้นอย่างมาก

เป็นการยากที่จะค้นหาแฮชที่ไม่ใช่การเข้ารหัสที่ดีด้วยอัตราการชนที่ต่ำเว้นแต่คุณจะพิจารณาการวิจัยเช่น "การค้นหาแฮชที่ไม่ใช่การเข้ารหัสที่ทันสมัยด้วยการเขียนโปรแกรมทางพันธุกรรม "

นอกจากนี้คุณยังสามารถอ่าน " พิจารณาการใช้อัลกอริทึมแฮชที่ไม่ใช่การเข้ารหัสลับสำหรับการเพิ่มความเร็วการแฮช " ซึ่งกล่าวถึงเช่น " xxhash " อัลกอริทึมแฮชที่ไม่ใช่การเข้ารหัสที่รวดเร็วมากทำงานด้วยความเร็วใกล้เคียงกับขีด จำกัด RAM

การสนทนาเกี่ยวกับการเปลี่ยนแฮชใน Git ไม่ใช่เรื่องใหม่:

• อย่างใดอย่างหนึ่งที่จะเพิ่มประสิทธิภาพของมัน (สิงหาคม 2009)แต่คุณต้องใช้เวลาออกใบอนุญาต:

(Linus Torvalds)

ไม่มีอะไรเหลืออยู่ของรหัสโมซิลล่า แต่เดี๋ยวก่อนฉันเริ่มจากมัน เมื่อมองย้อนกลับไปฉันควรเริ่มต้นจากรหัส asm ของ PPC ที่ทำการบล็อกอย่างเรียบร้อยแล้ว - แต่นั่นคือ "20/20 hindsight"

นอกจากนี้เฮ้รหัสโมซิลลาเป็นกองที่น่าสยดสยองก็เป็นสาเหตุที่ทำให้ฉันเชื่อมั่นว่าฉันจะปรับปรุงสิ่งต่าง ๆ ได้ นั่นคือแหล่งที่มาของมันแม้ว่าจะเป็นเรื่องเกี่ยวกับแรงจูงใจมากกว่าโค้ดที่เหลืออยู่จริงก็ตาม)

และคุณต้องระวังเกี่ยวกับวิธีการวัดการเพิ่มประสิทธิภาพที่เกิดขึ้นจริง

(Linus Torvalds)

ฉันสวยมากสามารถรับประกันคุณว่ามันปรับปรุงสิ่งต่าง ๆ เพียงเพราะมันทำให้ gcc สร้างรหัสอึซึ่งจะซ่อนปัญหา P4 บางส่วน

• หรือเปลี่ยนทั้งหมด (มกราคม 2010)
  (เช่น SHA-3 แต่จะใช้กับแฮชอื่น ๆ ):

(John Tapsell - johnflux)

ต้นทุนทางวิศวกรรมสำหรับการอัพเกรด git จาก SHA-1 เป็นอัลกอริทึมใหม่นั้นสูงกว่ามาก ฉันไม่แน่ใจว่าจะทำได้ดีแค่ไหน

ก่อนอื่นเราอาจจำเป็นต้องปรับใช้เวอร์ชันของ git (เรียกว่าเวอร์ชัน 2 สำหรับการสนทนานี้) ซึ่งอนุญาตให้มีสล็อตสำหรับค่าแฮชใหม่แม้ว่าจะไม่ได้อ่านหรือใช้พื้นที่นั้น - มันใช้ ค่าแฮช SHA-1 ซึ่งอยู่ในช่องอื่น

ด้วยวิธีนี้เมื่อเราปรับใช้ในที่สุดยังเป็น git เวอร์ชันใหม่ลองเรียกมันว่าเวอร์ชัน 3 ซึ่งสร้างแฮช SHA-3 นอกเหนือจากแฮช SHA-1 ผู้ที่ใช้ git เวอร์ชัน 2 จะสามารถทำงานร่วมกันได้ต่อไป
(แม้ว่าตามการสนทนานี้พวกเขาอาจมีช่องโหว่และผู้ที่พึ่งพา SHA-1-patches เท่านั้นอาจมีช่องโหว่)

ในระยะสั้นการสลับไปใช้แฮชนั้นไม่ใช่เรื่องง่าย

อัปเดตกุมภาพันธ์ 2560: ใช่เป็นไปได้ในทางทฤษฎีในการคำนวณการชน SHA1: shattered.io

GIT ได้รับผลกระทบอย่างไร

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

แต่:

การโจมตีครั้งนี้ต้องการการคำนวณ SHA1 มากกว่า 9,223,372,036,854,775,808 การคำนวณ สิ่งนี้ใช้พลังการประมวลผลเทียบเท่ากับการคำนวณด้วย CPU เดี่ยว 6,500 ปีและการคำนวณ GPU เดี่ยว 110 ปี

ดังนั้นอย่าเพิ่งตกใจเลย
ดูเพิ่มเติมที่ " วิธี Git จะจัดการ SHA-1 ชนบนหยดได้อย่างไร "