175

จะเกิดอะไรขึ้นถ้าฉันมีการชนกันระหว่างการแฮชในขณะที่ใช้คอมไพล์

เช่นฉันจัดการส่งสองไฟล์ด้วย sha1 checksum เดียวกัน git จะสังเกตเห็นมันหรือไฟล์ใดไฟล์หนึ่งเสียหาย?

สามารถปรับปรุง git ให้อยู่กับสิ่งนั้นได้หรือฉันจะต้องเปลี่ยนเป็นอัลกอริธึมการแฮชใหม่หรือไม่?

(โปรดอย่าเบี่ยงเบนคำถามนี้ด้วยการอภิปรายว่าเป็นไปได้ยากเพียงใด - ขอบคุณ)

26

I've been informed by the git Gods that the chances of a SHA1 collision is the same as the Earth being sucked up into the black hole created by the CERN accelerator. If this is indeed true, then there's no need for that extra memcmp.

แหล่งที่มา: lwn.net/Articles/307281

— KurzedMetal

16

อย่างแน่นอนไม่เป็นเช่นนั้น เพื่ออ้างอิง Dan Bernstein: "ความจริงที่ว่านักวิชาการยังไม่ได้ทำการโจมตี SHA-1 ชน แต่เป็นอุบัติเหตุทางประวัติศาสตร์เล็กน้อย" - ตอนนี้การแข่งขัน SHA-3 สิ้นสุดลงแล้วมีโอกาสดีที่ผู้คนที่เกี่ยวข้องจะหันมาสนใจ เพื่อใช้การโจมตีที่รู้จักในการสร้างการชน Marc Stevens ประมาณความยากลำบากในการดำเนินงานเพียง 2 ^ 61 มีแนวโน้มว่าจะมีการปะทะกันของ SHA-1 เร็ว ๆ นี้ มันแปลกที่มันไม่ได้เกิดขึ้นแล้ว

— Paul Crowley

27

@KurzedMetal: มีโอกาสสร้างหลุมดำใน CERN (โปรตอนสองอันจะชนกันอย่างถูกต้อง (10 ^ -15m)) แต่หลุมดำนี้จะไม่ดูดโลกขึ้นมันจะระเหยทันทีเนื่องจากรังสีฮอว์คิง ... โอกาสของการปะทะของ SHA1 นั้นใหญ่กว่าการถูกดูด ... แค่พูดว่า ...

— Jaa-c

9

ความเป็นไปได้ที่ซ้ำกันของคอมไพล์จะจัดการ SHA-1 collision บน blob ได้อย่างไร

— meagar

17

เป็นเรื่องน่าประหลาดใจที่คุณขอให้คนอื่นไม่พูดถึงความไม่ชอบของการปะทะกันของ Git และเกือบทุกคนพูดถึงความไม่ชอบของ Git collision คนเหล่านี้ควรถูกแบนจาก stackoverflow ตลอดชีวิต!

— Yukio Fukuzawa

108

เลือกอะตอมใน 10 ดวงจันทร์

แฮช SHA-1 เป็นสตริงอักขระฐานสิบหก 40 ... นั่นคือ 4 บิตต่อตัวอักษรคูณ 40 ... 160 บิต ตอนนี้เรารู้ 10 บิตจะอยู่ที่ประมาณ 1000 (1024 ถึงเป็นที่แน่นอน) มีความหมายว่ามี 000 000 1 000 000 000 000 000 000 000 000 000 000 000 000 000 000 ที่แตกต่างกัน SHA-1 hashes ... 10 48

สิ่งนี้เทียบเท่าหรือไม่ ดวงจันทร์ประกอบด้วยอะตอม10 ⁴⁷อะตอม ดังนั้นถ้าเรามี 10 ดวงจันทร์ ... และคุณสุ่มเลือกหนึ่งอะตอมบนหนึ่งในดวงจันทร์เหล่านี้ ... จากนั้นไปข้างหน้าและเลือกอะตอมสุ่มกับพวกเขาอีกครั้ง ... แล้วโอกาสที่คุณจะเลือกอะตอมเดียวกันสองครั้ง เป็นโอกาสที่สองคอมไพล์ที่ได้รับมอบหมายจะมีแฮช SHA-1 เหมือนกัน

เมื่อขยายออกไปเราสามารถถามคำถาม ...

คุณต้องการคอมมิทกี่ครั้งในที่เก็บก่อนที่คุณจะเริ่มกังวลเกี่ยวกับการชน

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

วิกิพีเดียมีตารางบนน่าจะเป็นของชนวันเกิดความขัดแย้ง ไม่มีรายการสำหรับแฮช 40 อักขระ แต่การแก้ไขของรายการสำหรับ 32 และ 48 ตัวอักษรทำให้เราอยู่ในช่วง 5 * 10 ²² git ให้โอกาส 0.1% ของการชน นั่นคือความมุ่งมั่นที่แตกต่างกันห้าหมื่นล้านล้านหรือห้าZettacommitsก่อนที่คุณจะมีโอกาสถึง 0.1% ที่คุณมีการปะทะกัน

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

ประเด็นของเรื่องนี้ก็คือว่าถ้าใครบางคนจงใจทำให้เกิดการชนกันความน่าจะเป็นที่เกิดขึ้นโดยบังเอิญนั้นมีขนาดเล็กมากจนทำให้คุณไม่สนใจปัญหานี้

"แต่เมื่อการปะทะกันไม่เกิดขึ้นแล้วสิ่งที่เกิดขึ้นจริง?"

ตกลงคิดว่าไม่น่าจะเกิดขึ้นไม่หรือคิดว่าคนที่มีการจัดการเพื่อตัดโดยเจตนา SHA-1 กัญชาชน จะเกิดอะไรขึ้น?

ในกรณีที่มีคำตอบที่ดีที่มีคนทดลองกับมัน ฉันจะอ้างอิงจากคำตอบนั้น:

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

หากวัตถุต้นไม้มีอยู่แล้วและคุณสร้างหยดที่มีแฮชเดียวกัน: ทุกอย่างดูเหมือนจะเป็นเรื่องปกติจนกว่าคุณจะพยายามที่จะผลักดันหรือบางคนโคลนที่เก็บของคุณ จากนั้นคุณจะเห็นว่าธุรกรรมซื้อคืนเสียหาย

หากมีวัตถุกระทำอยู่แล้วและคุณสร้างหยดที่มีแฮชเดียวกันนั่นคือ # 2

หากมี Blob อยู่แล้วและคุณสร้างวัตถุที่มีแฮชเดียวกันมันจะล้มเหลวเมื่อทำการอัพเดท "ref"

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

หากวัตถุต้นไม้มีอยู่แล้วและคุณทำการกระทำวัตถุที่มีแฮชเดียวกันวัตถุนั้นจะล้มเหลวเมื่อทำการอัพเดท "ref"

หากวัตถุต้นไม้มีอยู่แล้วและคุณสร้างวัตถุต้นไม้ที่มีแฮชเดียวกันทุกอย่างจะดูโอเค แต่เมื่อคุณส่งมอบพื้นที่เก็บข้อมูลทั้งหมดจะอ้างอิงต้นไม้ที่ไม่ถูกต้อง

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

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

ในขณะที่คุณสามารถดูบางกรณีไม่ดี โดยเฉพาะอย่างยิ่งกรณีที่ # 2 และ # 3 ทำให้พื้นที่เก็บข้อมูลของคุณยุ่งเหยิง อย่างไรก็ตามดูเหมือนว่าข้อผิดพลาดจะยังคงอยู่ในพื้นที่เก็บข้อมูลนั้นและความน่าจะเป็นที่การโจมตี / แปลกประหลาดไม่ได้แพร่กระจายไปยัง reposistories อื่น ๆ

นอกจากนี้ยังดูเหมือนว่าปัญหาของการชนโดยเจตนาจะถูกยอมรับว่าเป็นภัยคุกคามที่แท้จริงและอื่น ๆ เช่นGitHub เป็นมาตรการเพื่อป้องกันไม่ให้

— MichaelK
แหล่งที่มา

22

ผมไม่ทราบว่าตัวเลขที่มีความถูกต้อง แต่เอ้นี้เป็นวิธีแบบกราฟิกที่ดีที่จะอธิบาย unlikelihood และตลก :)

— mimoralea

4

ตอนนี้ฉันกำลังติดต่อกับองค์การนาซ่าเพื่อหาดวงจันทร์ 10 ดวงแล้วลองใช้ดู ถ้าเราไม่มีดวงจันทร์ 10 ดวงก็ไม่มีใครบอกได้ว่ามันใช้ได้ผล)

— Utkarsh Kumar

2

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

— Maarten Bodewes

7

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

— Yukio Fukuzawa

3

@FukuzawaYukio ยังไม่ได้พิมพ์สลากกินแบ่ง 2 ^ 48 แต่มีเพียงล้านเท่านั้น (อาจรวม 200 ล้านต่อปี .. ใครจะรู้?) และมีลอตเตอรี่ที่ชนะ ความน่าจะเป็นนั้นสูงขึ้นมากและสำหรับตั๋วลอตเตอรีบางใบตั๋วที่ชนะจะถูกพิมพ์เสมอ ดังนั้นผู้ชนะจะหลีกเลี่ยงไม่ได้ (ยกเว้นว่าตั๋วที่ชนะนั้นถูกใส่ผิดที่โดยไม่ได้ตั้งใจ) นอกจากนี้ผมทำหลอกจริงจับสลากเกมตั๋วหลายปีที่ผ่านมา: lottery.py ไม่จำเป็นต้องพูดว่าคุณจะเสียเวลาไป 99%

— dylnmc

67

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

ดูโพสต์ของ Linus Torvalds ในชุดข้อความ“ เริ่มคิดเกี่ยวกับ sha-256?” ในคอมไพล์รายชื่อผู้รับจดหมาย

— klaustopher
แหล่งที่มา

4

"หากไฟล์สองไฟล์มีผลรวมแฮชเดียวกันในคอมไพล์มันจะถือว่าไฟล์เหล่านั้นเหมือนกัน" นี่เป็นคำตอบที่เหมาะสม อย่างไรก็ตามคุณมีแหล่งที่มาสำหรับคำสั่ง klaustopher นี้ไหม? ลิงก์ของคุณไม่ทำงานสำหรับฉัน

— Tiago

3

แต่นี่ไม่น่าเป็นไปได้อย่างแน่นอนถ้าคุณทำงานในโครงการที่มีกลุ่มตัวอย่างของการชนกันของแฮช

— Doomjunky

6

@JBishop ไม่มันไม่ได้เป็นอย่างนั้น หากคุณมีหลักฐานการชนกันของแฮชคุณจะมีชื่อเสียงในทันที อย่าลืมโพสต์มัน! ฉันจะส่งลังเบียร์ Haarlem ที่ดีอย่างแท้จริงถ้าคุณแสดงให้ฉันเห็นแฮช SHA-1 ขนาดเต็มที่สร้างขึ้นภายใน Git ภายในหนึ่งสัปดาห์ โปรดทราบว่ามันจะต้องเป็นการชนกันของแฮชที่แยกจากกันไม่ได้มีการอ้างถึงในที่อื่น (ไม่ใช่ว่ามีใครโพสต์ไว้

— Maarten Bodewes

7

+1 คำตอบเดียวที่ตอบคำถามได้จริง ส่วนที่เหลือทั้งหมดเป็นเพียงการพูดพล่ามเกี่ยวกับ "โอกาสเล็กน้อย" ที่อาจเกิดขึ้นซึ่งนักพัฒนาซอฟต์แวร์ทุกคนรู้แล้ว

— Yukio Fukuzawa

2

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

— DomQ

26

มันเป็นไปไม่ได้จริงๆที่จะตอบคำถามนี้ด้วยความถูกต้อง "แต่" โดยไม่ต้องอธิบายด้วยว่าทำไมมันจึงไม่ใช่ปัญหา เป็นไปไม่ได้ที่จะทำเช่นนั้นโดยที่ไม่ได้ยึดเกาะกับแฮชจริง ๆ มันซับซ้อนกว่ากรณีง่าย ๆ ที่คุณอาจเคยเห็นในโปรแกรม CS

มีความเข้าใจผิดพื้นฐานของทฤษฎีสารสนเทศที่นี่ หากคุณลดจำนวนข้อมูลลงในจำนวนที่น้อยลงโดยการทิ้งบางส่วน (เช่นแฮช) จะมีโอกาสเกิดการชนที่เกี่ยวข้องโดยตรงกับความยาวของข้อมูล ยิ่งข้อมูลน้อยลงเท่าใดโอกาสจะน้อยลง ตอนนี้การชนส่วนใหญ่จะเป็นการพูดพล่อยๆทำให้พวกเขามีแนวโน้มที่จะเกิดขึ้นจริงมากขึ้น (คุณจะไม่ตรวจสอบซึ่งพูดพล่อยๆ ... แม้กระทั่งภาพไบนารีที่มีโครงสร้างค่อนข้าง) ในที่สุดโอกาสที่จะห่างไกล เพื่อตอบคำถามของคุณใช่ git จะปฏิบัติต่อพวกเขาเหมือนกันการเปลี่ยนอัลกอริธึมแฮชจะไม่ช่วยมันจะใช้ "การตรวจสอบครั้งที่สอง" ของการเรียงลำดับบางอย่าง แต่ในที่สุดคุณจะต้องใช้ข้อมูล "การตรวจสอบเพิ่มเติม" มากขึ้น ตามความยาวของข้อมูลที่จะแน่ใจ 100% ... โปรดทราบว่าคุณจะ 99.99999 .... เป็นตัวเลขที่ยาวจริง ๆ .... แน่นอนด้วยการตรวจสอบที่ง่ายเหมือนที่คุณอธิบาย SHA-x เป็นแฮชที่มีการเข้ารหัสลับซึ่งหมายความว่าโดยทั่วไปไม่ยากที่จะสร้างชุดข้อมูลสองชุดที่มีความคล้ายคลึงกันมากและจงมีแฮชเดียวกัน การเปลี่ยนแปลงข้อมูลหนึ่งบิตควรสร้างบิตการเปลี่ยนแปลงมากกว่าหนึ่ง (โดยเฉพาะมากที่สุด) ในเอาต์พุตแฮชซึ่งหมายความว่ามันยากมาก (แต่ไม่ค่อยเป็นไปไม่ได้) ที่จะทำงานจากแฮชไปจนครบชุด การชนกันและดึงข้อความต้นฉบับออกมาจากชุดการชน - แต่จะมีเพียงไม่กี่คนที่พูดพล่อยๆและสิ่งที่ไม่ได้มีอยู่มากมายที่จะลอดผ่านหากความยาวของข้อความยาวมากพอสมควร ข้อเสียของแฮชเข้ารหัสคือพวกเขาช้าในการคำนวณ ... โดยทั่วไป

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

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

— สตีฟ
แหล่งที่มา

4

you'll almost certainly get a different hash because of the time change, which also feeds the hash in gitแฮชใช้เนื้อหาของไฟล์เพียงอย่างเดียวไม่ใช่หรือ

— fredoverflow

4

แฮชของหยดจะขึ้นอยู่กับเนื้อหาของไฟล์ (ที่มีข้อมูลเมตาเล็กน้อย) อย่างไรก็ตามแฮชของคอมมิท (ซึ่งในทางทฤษฎีสามารถชนกัน) มีเวลาปัจจุบันเช่นเดียวกับแฮชของต้นไม้ ผู้เขียน, แฮชของพาเรนต์พาเรนต์เป็นต้นอย่างไรก็ตามเมื่อ @Steve ชี้ให้เห็นสิ่งเล็ก ๆ น้อย ๆ ที่จะชนกันและการคอมมิชชันก็เป็นเรื่องเล็ก

— cdyson37

1

อย่าคิดว่าฉันเห็นด้วยกับ "ยิ่งข้อมูลมีขนาดสั้นลงเท่าใดโอกาสที่จะมี [การชน] น้อยลง" หากคุณหมายถึงแฮชที่สั้นลงคุณจะลดชุดของแฮชที่เป็นไปได้ = เพิ่มอินพุตของแผนที่ให้กับแต่ละแฮช = โอกาสในการชนที่สูงขึ้น หากคุณหมายถึงข้อความที่สั้นลงคุณกำลังแฮ็กข้อมูลนี้จะเป็นจริงในแง่ที่ว่าจำนวนอินพุตที่เป็นไปได้นั้นถูก จำกัด ด้วยจำนวนอักขระที่ใช้ซึ่งดูเหมือนว่าชัดเจนดังนั้นฉันจึงรู้สึกว่าคุณต้องพลาดจุดของคุณ?

— พื้นฐาน

ฉันไม่เคยคิดถึงจุดที่ "คล้ายกันมาก" ซึ่งเป็นจุดที่ดีจริงๆ โดยทั่วไปหมายความว่าเพื่อให้มี 2 การกระทำที่มีแฮชเดียวกันคุณจะต้องเปลี่ยนส่วนสำคัญของตัวละครในไฟล์ทุกไฟล์ (ไม่ต้องพูดถึงชื่อไฟล์พา ธ และจำนวนไฟล์)

— PieterNuyts

1

@PieterNuyts ไม่เพื่อรับแฮชที่เฉพาะเจาะจงจากไฟล์เริ่มต้นโดยพลการคุณจะต้องเปลี่ยนข้อมูลในไฟล์ด้วยจำนวนที่คล้ายกับจำนวนบิตของข้อมูลในแฮชเช่นประมาณ 160 บิตสำหรับ SHA-1 อย่างไรก็ตามข้อมูลเกี่ยวกับบิตที่จะเปลี่ยนจะนับที่นี่ด้วยดังนั้นยิ่งไฟล์ยาวเท่าไหร่คุณต้องเปลี่ยนบิตให้น้อยลงหากคุณเลือกบิตที่ถูกต้อง สมมุติฐานหากไฟล์ที่มีความยาวมากกว่า 2 ^ 160 ไบต์คุณสามารถแฮชได้เกือบทั้งหมดโดยการเปลี่ยนบิตเดียวเนื่องจากตำแหน่งของบิตนั้นมีข้อมูลมากกว่า 160 บิต!

— M Kloster

10

สามารถปรับปรุง git ให้อยู่กับสิ่งนั้นได้หรือฉันจะต้องเปลี่ยนเป็นอัลกอริธึมการแฮชใหม่หรือไม่?

การชนกันนั้นเป็นไปได้สำหรับอัลกอริธึมการแฮชดังนั้นการเปลี่ยนฟังก์ชันแฮชจะไม่ทำให้เกิดปัญหา แต่ก็ทำให้โอกาสเกิดขึ้นน้อยลง ดังนั้นคุณควรเลือกฟังก์ชั่นแฮชที่ดีจริงๆ (SHA-1 เป็นแล้ว แต่คุณขอไม่ให้บอก :)

— Roberto Bonvallet
แหล่งที่มา

ฉันคิดว่าคุณหมายถึง "ไม่น่าเป็นไปได้มากกว่า" หรือ "มีโอกาสน้อยลง" ใช่ไหม แน่ใจว่าคุณสามารถเปลี่ยนเป็นอัลกอริทึมแฮชที่มีไบต์น้อยลงในเอาต์พุต แต่นั่นไม่ได้หมายความว่าคุณจะถูกต้องใช่มั้ย :)

— MichaelK

2

SHA-1 แตกในแง่ที่ว่ามันจะเป็นไปได้ที่จะสร้างการชนกันโดยเจตนา ฉันคิดว่ามันเป็นไปแล้วในปี 2012 เช่นกัน ดังนั้นการเปลี่ยนเป็นแฮชที่แตกต่างกันซึ่งมีความปลอดภัยมากกว่าและมีสถานะและเอาท์พุทที่ใหญ่กว่าจะสร้างความแตกต่างอย่างแน่นอน

— Maarten Bodewes

9

คุณสามารถเห็นการศึกษาที่ดีใน " Git จะจัดการกับการชน SHA-1 บนหยดได้อย่างไร "

เนื่องจากการชนกันของ SHA1 เป็นไปได้ในขณะนี้ (ตามที่ฉันอ้างอิงในคำตอบนี้ด้วยshattered.io ) รู้ว่า Git 2.13 (Q2 2017) จะปรับปรุง / บรรเทาสถานการณ์ปัจจุบันด้วยตัวแปร "ความพยายามในการตรวจจับเพื่อสร้างการชน" ของSHA-1 โดยมาร์คสตีเวนส์ (CWI) และแดนชูโมว (Microsoft)

ดูกระทำ f5f5e7f , กระทำ 8325e43 , กระทำ c0c2006 , กระทำ 45a574e , กระทำ 28dc98e (16 มีนาคม 2017) โดยเจฟฟ์คิง (peff )
^{(รวมโดยJunio C Hamano - gitster-ในการกระทำ 48b3693 , 24 มีนาคม 2017)}

Makefile: ทำให้DC_SHA1เป็นค่าเริ่มต้น

เราเคยใช้การใช้งาน SHA1 จากไลบรารี OpenSSL ตามค่าเริ่มต้น
ในขณะที่เราพยายามระวังการโจมตีจากการชนหลังจากประกาศ "แตก" เมื่อเร็ว ๆ นี้ให้เปลี่ยนค่าเริ่มต้นเพื่อกระตุ้นให้ผู้คนใช้การติดตั้ง DC_SHA1 แทน
ผู้ที่ต้องการใช้การใช้งานจาก OpenSSL สามารถขอได้อย่างชัดเจนโดยOPENSSL_SHA1=YesPleaseเมื่อเรียกใช้ " make"

เราไม่ได้มีการชนกันของ Git-object ดังนั้นสิ่งที่ดีที่สุดที่เราทำได้คือการเรียกใช้ PDF ที่แตกหักผ่านการทดสอบ sha1 การดำเนินการนี้จะกระตุ้นการตรวจสอบการชนและตาย

Git จะได้รับการปรับปรุงให้ดีขึ้นเพื่อใช้กับสิ่งนั้นหรือฉันจะต้องเปลี่ยนเป็นอัลกอริทึมแฮชใหม่หรือไม่?

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

คุณจะสามารถใช้อัลกอริทึมแฮชอื่น: SHA1 ไม่ได้เป็น Git อีกต่อไป

Git 2.18 (Q2 2018) เอกสารที่ดำเนินการ

ดูกระทำ 5988eb6 , กระทำ 45fa195 (26 มีนาคม 2018) โดยÆvar Arnfjord Bjarmason (avar )
^{(ผสานโดยJunio C Hamano - gitster- in d877975 , 11 Apr 2018)}

doc hash-function-transition: ชี้แจงความหมายของ SHAttered

พยายามอธิบายความหมายของการโจมตีโดยพลการของ SHAttered ในทางปฏิบัติสำหรับ Git
ข้อความก่อนหน้านี้ไม่ได้กล่าวถึง Git แต่อย่างใดที่มีการลดลงสำหรับการโจมตีเฉพาะนี้ซึ่งนักวิจัยของ SHAttered อ้างว่าจะตรวจจับการโจมตีการโจมตีของ cryptanalytic

ฉันอาจได้รับความแตกต่างเล็กน้อย แต่เท่าที่ฉันรู้ว่าข้อความใหม่นี้สรุปสถานการณ์ปัจจุบันกับ SHA-1 อย่างแม่นยำในคอมไพล์ เช่นgit ไม่ได้ใช้ SHA-1 อีกต่อไป แต่ใช้ Hardened-SHA-1 (มันเกิดขึ้นเพื่อให้ได้ผลลัพธ์ที่เหมือนกัน 99.99999999999 ... % ของเวลา)

ดังนั้นข้อความก่อนหน้านี้ไม่ถูกต้องในการยืนยันว่า:

[... ] ด้วยเหตุนี้ [จาก SHAttered] ทำให้ SHA-1 ไม่สามารถใช้การเข้ารหัสแบบเข้ารหัสได้อีกต่อไป [... ]

นั่นไม่ใช่กรณี เรามีการลดผลกระทบต่อ SHAttered แต่ เราคิดว่ามันรอบคอบที่จะย้ายไปทำงานเพื่อหาNewHashช่องโหว่ในอนาคตทั้งใน SHA-1 หรือ Hardened-SHA-1

ดังนั้นเอกสารใหม่อ่านในขณะนี้:

Git v2.13.0 และต่อมาย้ายไปใช้ SHA-1 ที่แข็งขึ้นตามค่าเริ่มต้นซึ่งไม่เสี่ยงต่อการโจมตีของ SHAttered

ดังนั้น Git จึงย้ายไปยังแฮชใหม่ที่ไม่ใช่ SHA-1 และไม่แชร์ช่องโหว่ฟังก์ชันแฮชใหม่ของมันเพิ่งเกิดขึ้นเพื่อสร้างเอาต์พุตเดียวกันสำหรับอินพุตที่รู้จักทั้งหมดยกเว้น PDF สองไฟล์ที่เผยแพร่โดย SHAttered นักวิจัยและการใช้งานใหม่ (เขียนโดยนักวิจัยเหล่านั้น) อ้างว่าตรวจจับการโจมตีการชนกันของ cryptanalytic ในอนาคต

ไม่ว่าจะเป็นการพิจารณาที่รอบคอบแล้วที่จะย้ายตัวแปร SHA-1 ใด ๆ ไปสู่แฮชใหม่ ไม่มีการรับประกันว่าการโจมตี SHA-1 ในอนาคตจะไม่ได้รับการเผยแพร่ในอนาคตและการโจมตีเหล่านั้นอาจไม่ได้ช่วยบรรเทาปัญหาได้

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

หมายเหตุ: เอกสารเดียวกันในขณะนี้ (ไตรมาสที่ 3 ปี 2018, Git 2.19) อ้างอิง"hash ใหม่"อย่างชัดเจนว่าเป็น SHA-256 : ดูที่ " ทำไม Git จึงไม่ใช้ SHA ที่ทันสมัยกว่านี้ "

— VonC
แหล่งที่มา

4

นี่เป็นคำตอบหรือข้อคิดเห็นที่ดีเพียงอย่างเดียวที่นี่ บทสรุปคือ - ไม่น่าเป็นไปได้อย่างยิ่ง แต่เป็นไปได้ พวกเขาก็จะไม่สามารถระบุได้ทันทีและแก้ไขได้ด้วยการปรับแต่งไฟล์ (พร้อมความคิดเห็น) เพื่อหลีกเลี่ยงการชนกัน การหาประโยชน์โดยเจตนานั้นคิดว่าไม่เกี่ยวข้องเพราะบางคนสามารถตรวจสอบได้ง่าย ๆ ใน "รหัสไม่ดี" - และมีสิ่งต่าง ๆ เช่นลายเซ็นต์และการดึงคำขอโดยเจตนาไปยังขั้นตอนป้องกันไม่ให้คนสุ่มตรวจสอบสิ่งต่าง ๆ แบบสุ่ม

— แบรด

5

ตอนนี้ Google อ้างว่าการชนกันของ SHA-1 เป็นไปได้ภายใต้เงื่อนไขบางประการ: https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html

เนื่องจาก git ใช้ SHA-1 เพื่อตรวจสอบความสมบูรณ์ของไฟล์นั่นหมายความว่าความสมบูรณ์ของไฟล์ใน git นั้นถูกบุกรุก

IMO, git ควรใช้อัลกอริทึมการแปลงแป้นพิมพ์ที่ดีขึ้นอย่างแน่นอนเนื่องจากการชนกันโดยเจตนานั้นเป็นไปได้

— Petercommand Hsu
แหล่งที่มา

2

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

— DomQ

2

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

อัตราต่อรองคืออะไร?

SHA-256มีแฮชที่เป็นไปได้ 2 ^ 256 นั่นคือประมาณ10 ^ 78 หรือจะเป็นกราฟิกมากขึ้นโอกาสของการปะทะกันอยู่ที่ประมาณ

1: 100 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 000 000 000 000

โอกาสในการชนะการจับสลากเป็นเรื่องเกี่ยวกับ1: 14 Mio โอกาสของการปะทะกับ SHA-256 นั้นเหมือนกับการชนะลอตเตอรี่ใน11 วันติดต่อกัน !

คำอธิบายทางคณิตศาสตร์: 14 000 000 ^ 11 ~ 2 ^ 256

นอกจากนี้จักรวาลมีอะตอมประมาณ 10 ^ 80 นั่นเป็นเพียง 100 เท่าของชุดค่าผสม SHA-256

การชนกันของ MD5 ที่ประสบความสำเร็จ

แม้แต่MD5โอกาสก็น้อยมาก แม้ว่านักคณิตศาสตร์สามารถสร้างการชนกันได้:

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

มี MD5 เหมือนกัน

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

นี่ไม่ได้หมายความว่า MD5 จะปลอดภัยน้อยลงในขณะที่อัลกอริทึมของมันจะแตก คุณสามารถสร้างการชนกันของ MD5 ได้ตามวัตถุประสงค์ แต่โอกาสของการชนที่เกิดจาก MD5 โดยบังเอิญนั้นยังคงเป็น 2 ^ 128 ซึ่งยังคงมีอยู่มาก

ข้อสรุป

คุณไม่ต้องกังวลเรื่องการชน อัลกอริทึมการแฮชเป็นวิธีที่ปลอดภัยที่สุดที่สองในการตรวจสอบความเหมือนกันของไฟล์ วิธีที่ปลอดภัยกว่าคือการเปรียบเทียบแบบไบนารี

— bytecode77
แหล่งที่มา

4

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

— Andrew Arnott

@AndrewArnott ไม่มีความแตกต่างที่เกี่ยวข้องระหว่าง SHA-256 และ SHA-1 SHA-1 มีค่าลดลง 2 ^ 128 เท่า แต่ก็ไม่สำคัญเช่นกัน ก็ยังไม่เปราะดังนั้นคำตอบของฉันไม่ได้จึงถูกใส่ผิดที่

— bytecode77

4

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

— Andrew Arnott

"นี่ไม่ได้หมายความว่า MD5 ปลอดภัยน้อยกว่าตอนนี้อัลกอริทึมของมันจะแตก" มาอีกครั้ง? คุณช่วยอธิบายประโยคนั้นได้ไหม

— Maarten Bodewes

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

— bytecode77

1

ฉันเดาว่าตอนนี้เรารู้แล้วว่าจะเกิดอะไรขึ้น - คุณควรคาดหวังว่าที่เก็บของคุณจะเสียหาย (ที่มา )

— แบรดลีย์คอนเนอร์
แหล่งที่มา

1

ฉันเพิ่งพบการโพสต์จาก 2013-04-29 ในกลุ่มสนทนา BSD ที่

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

ที่โปสเตอร์อ้างว่า:

ฉันวิ่งชนแฮ็ชหนึ่งครั้งโดยใช้การรีบูท git

น่าเสียดายที่เขาไม่มีข้อพิสูจน์ในการเรียกร้องของเขา แต่บางทีคุณอาจต้องการติดต่อเขาและถามเขาเกี่ยวกับเหตุการณ์ที่คาดคะเนนี้

แต่ในระดับทั่วไปมากขึ้นเนื่องจากการโจมตีวันเกิดโอกาสที่จะเกิดการชนกันของ SHA-1 คือ 1 ใน pow (2, 80)

ฟังดูเยอะแยะและแน่นอนว่ามีมากกว่าจำนวนเวอร์ชั่นของไฟล์แต่ละไฟล์ที่มีอยู่ในที่เก็บ Git ทั้งหมดของโลกรวมกัน

อย่างไรก็ตามสิ่งนี้ใช้ได้กับเวอร์ชันที่ยังคงอยู่ในประวัติเวอร์ชันเท่านั้น

หากนักพัฒนาใช้มากในการรีบูตทุกครั้งที่มีการรีบูทรันสำหรับสาขาความมุ่งมั่นทั้งหมดในทุกเวอร์ชันของสาขานั้น (หรือส่วนที่ถูกรีบูทของสาขา) จะได้รับแฮชใหม่ เช่นเดียวกับทุกไฟล์ที่แก้ไขด้วย "git filter-branch" ดังนั้น "rebase" และ "filter-branch" อาจเป็นตัวทวีคูณขนาดใหญ่สำหรับจำนวนของแฮชที่สร้างขึ้นเมื่อเวลาผ่านไปแม้ว่าจะไม่ได้ถูกเก็บไว้ทั้งหมด: บ่อยครั้งหลังจากรีบูต (โดยเฉพาะอย่างยิ่งเพื่อวัตถุประสงค์ในการ "ล้าง" สาขา ) สาขาเดิมจะถูกโยนทิ้งไป

แต่หากการชนเกิดขึ้นระหว่างการรีบูทหรือฟิลเตอร์สาขาก็ยังสามารถมีผลเสีย

อีกสิ่งหนึ่งก็คือการประมาณจำนวนเอนทิตีที่แฮชในที่เก็บข้อมูลคอมไพล์และดูว่าพวกมันมาจากไหน (2, 80)

สมมติว่าเรามีคนประมาณ 8 พันล้านคนและพวกเขาทั้งหมดจะทำงานคอมไพล์และเก็บเนื้อหาของพวกเขาในที่เก็บ 100 คอมไพล์ต่อคน สมมติว่าที่เก็บข้อมูลเฉลี่ยมี 100 การคอมมิทและ 10 ไฟล์และไฟล์ใดไฟล์หนึ่งเท่านั้นที่มีการเปลี่ยนแปลงต่อการคอมมิท

อย่างน้อยเราก็มีแฮชสำหรับวัตถุต้นไม้และวัตถุที่กระทำเอง เมื่อรวมกับไฟล์ที่มีการเปลี่ยนแปลงเรามี 3 แฮชต่อการแก้ไขและทำให้ 300 แฮชต่อที่เก็บ

สำหรับที่เก็บข้อมูล 100 แห่งจาก 8 พันล้านคนสิ่งนี้จะช่วยให้ธาร (2, 47) ซึ่งยังห่างไกลจากธาร (2, 80)

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

— Guenther Brunthaler
แหล่งที่มา

น่าสนใจ +1 ดังที่ฉันได้กล่าวถึงข้างต้นปัญหานี้จะหายไปในที่สุด: stackoverflow.com/a/47838703/6309

— VonC

Hash collision ในคอมไพล์

เลือกอะตอมใน 10 ดวงจันทร์

"แต่เมื่อการปะทะกันไม่เกิดขึ้นแล้วสิ่งที่เกิดขึ้นจริง?"

`Makefile`: ทำให้`DC_SHA1`เป็นค่าเริ่มต้น

doc `hash-function-transition`: ชี้แจงความหมายของ SHAttered

อัตราต่อรองคืออะไร?

การชนกันของ MD5 ที่ประสบความสำเร็จ

ข้อสรุป

Hash collision ในคอมไพล์

เลือกอะตอมใน 10 ดวงจันทร์

"แต่เมื่อการปะทะกันไม่เกิดขึ้นแล้วสิ่งที่เกิดขึ้นจริง?"

Makefile: ทำให้DC_SHA1เป็นค่าเริ่มต้น

doc hash-function-transition: ชี้แจงความหมายของ SHAttered

อัตราต่อรองคืออะไร?

การชนกันของ MD5 ที่ประสบความสำเร็จ

ข้อสรุป

`Makefile`: ทำให้`DC_SHA1`เป็นค่าเริ่มต้น

doc `hash-function-transition`: ชี้แจงความหมายของ SHAttered