गश में टक्कर

Question

वास्तव में अगर मैं git का उपयोग करते समय हैश टकराव होता तो क्या होता?

उदाहरण के लिए, मैं एक ही sha1 चेकसम के साथ दो फाइल करने का प्रबंधन करता हूं, क्या यह नोटिस करेगा या फाइलों में से एक को भ्रष्ट करेगा?

क्या इसके साथ रहने के लिए सुधार किया जा सकता है, या मुझे एक नए हैश एल्गोरिथ्म में बदलना होगा?

(कृपया इस सवाल पर चर्चा न करें कि यह कैसे संभव नहीं है - धन्यवाद)

Comments

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

पूरी तरह से नहीं है। डैन बर्नस्टीन के हवाले से: "यह तथ्य कि शिक्षाविदों ने SHA-1 टकराव के हमले को अभी तक अंजाम नहीं दिया है, एक मामूली ऐतिहासिक दुर्घटना है" - अब जब SHA-3 प्रतियोगिता समाप्त हो गई है, तो एक अच्छा मौका है कि संबंधित लोग अपना ध्यान आकर्षित करेंगे। टक्कर का उत्पादन करने के लिए ज्ञात हमले का उपयोग करने के लिए। मार्क स्टीवंस मात्र 2 ^ 61 ऑपरेशन के रूप में कठिनाई का अनुमान लगाते हैं। बहुत जल्द ही SHA-1 टक्कर प्रदर्शित होने की संभावना है; यह अजीब है कि यह पहले से ही नहीं हुआ है।

— पॉल क्रॉले

@KurzedMetal: CERN में ब्लैक होल बनाने का एक मौका है (दो प्रोटॉन सटीक रूप से टकराते होंगे (10 ^ -15 m)), हालाँकि यह ब्लैक होल पृथ्वी को नहीं चूस पायेगा, यह तुरंत हॉक विकिरण के कारण वाष्पित हो जाएगा ... तो SHA1 के टकराने की संभावना चूसे जाने से बहुत बड़ी है ... बस कह रही है ...

— जा-सी

संभव डुप्लिकेट कैसे एक बूँद पर एक SHA-1 टकराव को हैंडल करेगा?

— meagar

यह आश्चर्य की बात है कि आपने विशेष रूप से लोगों से गिट टकराव की अवांछितता पर चर्चा नहीं करने के लिए कहा, और लगभग सभी ने गिट टकराव के बारे में बात की। इन लोगों को जीवन के लिए स्टैकओवरफ्लो से प्रतिबंधित किया जाना चाहिए!

— युकियो फुकुजावा

Answer 1

10 मोन्स पर परमाणु उठा

एक SHA-1 हैश एक 40 हेक्स कैरेक्टर स्ट्रिंग है ... जो कि 4 बिट्स प्रति कैरेक्टर समय 40 ... 160 बिट्स है। अब हम जानते हैं कि 10 बिट्स लगभग 1000 (1024 के सटीक होने का) मतलब है कि 1 000 000 000 000 000 000 000 000 000 000 000 000 000 000 अलग-अलग SHA-1 हैश ... 10 ⁴⁸ ।

यह किसके समकक्ष है? वैसे चंद्रमा लगभग 10 ⁴⁷ परमाणुओं से बना है। इसलिए यदि हमारे पास 10 चंद्रमा हैं ... और आप बेतरतीब ढंग से इनमें से एक चंद्रमा पर एक परमाणु उठाते हैं ... और फिर आगे बढ़ते हैं और उन पर फिर से एक यादृच्छिक परमाणु उठाते हैं ... तो संभावना है कि आप एक ही परमाणु को दो बार चुनेंगे , संभावना है कि दो दिए गए कमिट में समान SHA-1 हैश होगा।

इस पर विस्तार करते हुए हम सवाल पूछ सकते हैं ...

इससे पहले कि आप टकरावों के बारे में चिंता करना शुरू करें, आपको कितने भंडार की आवश्यकता होगी?

यह तथाकथित "जन्मदिन के हमलों" से संबंधित है, जो बदले में "जन्मदिन विरोधाभास" या "जन्मदिन की समस्या" को संदर्भित करता है, जिसमें कहा गया है कि जब आप किसी दिए गए सेट से यादृच्छिक रूप से चुनते हैं, तो आपको आश्चर्यजनक रूप से कुछ पिक्स की आवश्यकता होती है, इससे अधिक होने की संभावना नहीं है दो बार कुछ लेने के लिए। लेकिन "आश्चर्यजनक रूप से कुछ" यहाँ एक बहुत ही सापेक्ष शब्द है।

विकिपीडिया में जन्मदिन विरोधाभास टकराव की संभावना पर एक तालिका है । 40 वर्ण वाले हैश के लिए कोई प्रविष्टि नहीं है। लेकिन 32 और 48 वर्णों के लिए प्रविष्टियों का एक प्रक्षेप हमें 5 * 10 ²² की सीमा में लैंड करता है जो टकराव की 0.1% संभावना के लिए प्रतिबद्ध है। पचास हज़ार बिलियन बिलियन अलग-अलग कमिट्स, या पचास ज़ेटैकेमिट्स , इससे पहले कि आप एक 0.1% संभावना पर भी पहुँच गए हैं कि आपकी टक्कर है।

इन कमिट्स के लिए अकेले हैश की बाइट राशि एक वर्ष के लिए पृथ्वी पर उत्पन्न सभी डेटा की तुलना में अधिक डेटा होगी, जो यह कहना है कि आपको YouTube स्ट्रीम वीडियो की तुलना में कोड को तेजी से मंथन करने की आवश्यकता होगी। उसके साथ अच्छा भाग्य। : डी

इसका मुद्दा यह है कि जब तक कोई जानबूझकर टकराव पैदा नहीं कर रहा है, तब तक किसी के यादृच्छिक होने की संभावना इतनी कम है कि आप इस मुद्दे को अनदेखा कर सकते हैं

"लेकिन जब टक्कर होती है, तो वास्तव में क्या होता है?"

ठीक है, मान लें कि अनुचित कार्य होता है, या मान लें कि कोई व्यक्ति जानबूझकर SHA-1 हैश टकराव दर्जी करने में कामयाब रहा । फिर क्या होता है?

उस मामले में एक उत्कृष्ट जवाब है जहां किसी ने उस पर प्रयोग किया । मैं उस जवाब से उद्धृत करूंगा:

1. यदि एक ही हैश के साथ एक बूँद पहले से मौजूद है, तो आपको कोई चेतावनी नहीं मिलेगी। सब कुछ ठीक प्रतीत होता है, लेकिन जब आप धक्का देते हैं, तो कोई क्लोन, या आप वापस लौटते हैं, तो आप नवीनतम संस्करण खो देंगे (ऊपर बताए गए तरीके के अनुरूप)।
2. यदि कोई ट्री ऑब्जेक्ट पहले से मौजूद है और आप उसी हैश के साथ एक बूँद बनाते हैं: सब कुछ सामान्य लगेगा, जब तक कि आप या तो धक्का देने की कोशिश नहीं करते या कोई आपकी रिपॉजिटरी को क्लोन नहीं करता। तब आप देखेंगे कि रेपो भ्रष्ट है।
3. यदि कोई प्रतिबद्ध वस्तु पहले से मौजूद है और आप उसी हैश के साथ एक बूँद बनाते हैं: # 2 के समान - भ्रष्ट
4. यदि एक बूँद पहले से ही मौजूद है और आप उसी हैश के साथ कमिट ऑब्जेक्ट बनाते हैं, तो यह "रेफ" को अपडेट करते समय विफल हो जाएगा।
5. यदि एक बूँद पहले से मौजूद है और आप उसी हैश के साथ एक ट्री ऑब्जेक्ट बनाते हैं। यह प्रतिबद्ध बनाते समय विफल हो जाएगा।
6. यदि कोई ट्री ऑब्जेक्ट पहले से मौजूद है और आप उसी हैश के साथ कमिट ऑब्जेक्ट बनाते हैं, तो यह "Ref" को अपडेट करते समय विफल हो जाएगा।
7. यदि एक ट्री ऑब्जेक्ट पहले से मौजूद है और आप उसी हैश के साथ ट्री ऑब्जेक्ट बनाते हैं, तो सब कुछ ठीक लगेगा। लेकिन जब आप प्रतिबद्ध होते हैं, तो सभी रिपॉजिटरी गलत पेड़ का संदर्भ देंगे।
8. यदि कोई प्रतिबद्ध ऑब्जेक्ट पहले से मौजूद है और आप उसी हैश के साथ कमिट ऑब्जेक्ट बनाते हैं, तो सब कुछ ठीक लगेगा। लेकिन जब आप प्रतिबद्ध होते हैं, तो कमिट कभी नहीं बनाई जाएगी, और HEAD पॉइंटर को एक पुरानी कमिट में ले जाया जाएगा।
9. यदि कोई प्रतिबद्ध ऑब्जेक्ट पहले से मौजूद है और आप उसी हैश के साथ ट्री ऑब्जेक्ट बनाते हैं, तो यह प्रतिबद्ध बनाते समय विफल हो जाएगा।

जैसा कि आप महसूस कर सकते हैं कि कुछ मामले अच्छे नहीं हैं। विशेषकर # 2 और # 3 मामले आपके भंडार को गड़बड़ कर देते हैं। हालाँकि, ऐसा लगता है कि दोष उस भंडार के भीतर रहता है, और हमला / विचित्र अनुचितता अन्य रिपॉजिटरी में नहीं फैलता है।

इसके अलावा ऐसा लगता है कि जानबूझकर टकराव के मुद्दे को वास्तविक खतरे के रूप में पहचाना जा रहा है, और इसलिए उदाहरण के लिए GitHub इसे रोकने के लिए उपाय कर रहा है ।

Comments

मुझे नहीं पता कि क्या संख्याएँ सही हैं, लेकिन यह

— अवांछितता

मैं 10 चन्द्रमाओं को खोजने और इसे आजमाने के लिए नासा के साथ संपर्क में हूं। जब तक हमारे पास 10 चंद्रमा हैं, कोई भी नहीं बताता है कि यह काम करता है;)

— उत्कर्ष कुमार

मौका है कि एक वास्तविक पाठ फ़ाइल का एक यादृच्छिक प्रतिबद्ध टकराव शून्य के रूप में अच्छा है, बहुत ही संभावना नहीं है। लेकिन यह जवाब पूरी तरह से इस तथ्य पर निर्भर करता है कि कोई व्यक्ति कोशिश कर सकता है और जानबूझकर टकराव पैदा कर सकता है। हमले के तहत SHA-1 हैश के साथ, बल्कि एक महत्वपूर्ण कारक बन रहा है।

— मार्टन बोदवेस

डाउन वोटिंग का कारण: बहुत अच्छी तरह से कहा गया है, लेकिन संभावना का मतलब यहां बिल्कुल कुछ भी नहीं है। लोट्टो जीतने के बारे में आप यही कह सकते हैं, लेकिन लोग यहां पर लोट्टो जीतते हैं। इसलिए लोट्टो कंपनी वास्तव में सिर्फ यह नहीं कह सकती है: मौका छोटा है इसलिए हमें वास्तव में जैकपॉट का भुगतान करने के बारे में चिंता नहीं करनी चाहिए। यहाँ ओपी का प्रश्न है: जब वह छोटा मौका होता है तो क्या होता है, और आप इसका उत्तर देने में असफल रहे।

— युकियो फुकुजावा

@FukuzawaYukio में 2 ^ 48 लॉटरी टिकट नहीं छपे हैं, हालाँकि - केवल लाखों (शायद प्रति वर्ष कुल 200 मिलियन .. कौन जानता है?), और एक जीतने वाली लॉटरी है। संभावना बहुत अधिक है, और कुछ लॉटरी टिकटों के लिए, जीतने वाला टिकट हमेशा मुद्रित होता है; इसलिए, विजेता अपरिहार्य है (जब तक कि जीतने वाला टिकट गलती से गलत न हो जाए)। इसके अलावा, मैंने कई साल पहले एक छद्म यथार्थवादी लॉटरी टिकट का खेल बनाया था: लॉटरी । कहने की जरूरत नहीं है, आप 99% समय खो देते हैं।

— dylnmc

Answer 2

अगर दो फाइलों में एक ही हैश राशि होती है, तो यह उन फाइलों को समान मानती है। ऐसा होने की बिल्कुल संभावना नहीं है, आप हमेशा एक कमिट कर सकते हैं, और फ़ाइल में कुछ बदल सकते हैं ताकि वे अब टकराए नहीं ...

लिंडस टॉर्वाल्ड्स को "श-256 के बारे में सोचना शुरू करें" पोस्ट देखें। git मेलिंग सूची में ।

Comments

"अगर दो फाइलों में समान हैश राशि होती है, तो यह उन फ़ाइलों को समान मानती है।" यह वास्तव में एक उचित उत्तर है। हालाँकि, क्या आपके पास इस कथन के लिए कुछ स्रोत हैं। आपका लिंक मेरे लिए काम नहीं कर रहा है।

— टियागो

लेकिन यह बिल्कुल असंभव नहीं है यदि आप किसी प्रोजेक्ट पर हैश टक्कर के नमूनों के संग्रह के साथ काम करते हैं।

— डूमजुनकी

@JBishop नहीं यह नहीं था। यदि आपके पास हैश टकराने का प्रमाण है तो आपके पास तुरंत प्रसिद्धि होगी। इसे पोस्ट करने के लिए मत भूलना! यदि आप मुझे एक सप्ताह के भीतर Git में बनाए गए पूर्ण आकार SHA-1 हैश टक्कर दिखाते हैं, तो मैं वास्तव में अच्छा हार्लेम बीयर का एक टोकरा भेजूँगा। ध्यान दें कि यह एक अलग हैश टकराव होना चाहिए, न कि पहले से ही कहीं और उद्धृत किया गया हो (ऐसा नहीं है कि किसी ने अभी तक एक पोस्ट किया है, लेकिन अभी भी)।

— मार्टन बोदवेस 16:24 बजे

+1 अब तक का एकमात्र उत्तर है जो वास्तव में प्रश्न का उत्तर देता है। बाकी सभी सिर्फ "छोटे मौके" के बारे में बड़बड़ा रहे हैं, यह हो सकता है, जिसे हर डेवलपर पहले से जानता है।

— युकिओ फुकुजावा

आईटी सिक्योरिटी पर चर्चा करने वाले लाइनस के बारे में बहुत सावधान रहें - वह पहले भी गलत रहा है और वह इस पर गलत है। यदि कोई वसीयत में SHA-1 टकराव पैदा कर सकता है, तो कोई इसका उपयोग सभी प्रकार के तबाही के लिए कर सकता है जैसे कि वृत्ताकार इतिहास बनाना जिससे Git सर्वर और क्लाइंट क्रैश हो जाते हैं।

— डोमक्यू

Answer 3

इस सवाल का सही जवाब देना वास्तव में संभव नहीं है "लेकिन" बिना यह बताए कि यह समस्या क्यों नहीं है। यह वास्तव में हैश वास्तव में क्या है पर एक अच्छी पकड़ के बिना ऐसा करना संभव नहीं है। CS प्रोग्राम में आपके द्वारा उजागर किए गए सरल मामलों की तुलना में यह अधिक जटिल है।

यहां सूचना सिद्धांत की बुनियादी गलतफहमी है। यदि आप कुछ राशि (यानी एक हैश) को त्यागकर बड़ी मात्रा में जानकारी को कम कर देते हैं, तो डेटा की लंबाई से सीधे टकराव की संभावना होगी। डेटा जितना छोटा होगा, संभावना है कि यह कम होगा। अब, विशाल बहुमत टकराव हो जाएगा, जिससे उन्हें वास्तव में होने की अधिक संभावना है (आप कभी भी अस्पष्टता में जांच नहीं करेंगे ... यहां तक ​​कि एक द्विआधारी छवि कुछ संरचित है)। अंत में, संभावनाएं दूरस्थ हैं। आपके प्रश्न का उत्तर देने के लिए, हाँ, जीआईटी उन्हें एक जैसा ही मानेगा, हैश एल्गोरिथ्म को बदलने में मदद नहीं करेगा, यह किसी प्रकार का "दूसरा चेक" लेगा, लेकिन अंततः, आपको "अतिरिक्त चेक" डेटा की आवश्यकता होगी डेटा की लंबाई के रूप में 100% सुनिश्चित हो ... ध्यान रखें कि आप 99.99999 होंगे ...। अंकों की वास्तव में लंबी संख्या के लिए .... निश्चित रूप से एक साधारण जांच के साथ जैसे आप वर्णन करते हैं। SHA-x क्रिप्टोग्राफिक रूप से मजबूत हैश है, जिसका अर्थ है आम तौर पर दो स्रोत डेटा सेट बनाने के लिए जानबूझकर कठिन नहीं है जो एक दूसरे के लिए बहुत ही सरल हैं, और एक ही हैश है। डेटा में थोड़ा सा बदलाव एक से अधिक (अधिमानतः संभव के रूप में) हैश आउटपुट में परिवर्तन के बिट्स बनाने चाहिए, जिसका अर्थ यह भी है कि हैश से पूर्ण सेट पर वापस काम करना बहुत मुश्किल (लेकिन असंभव नहीं है) टकराव, और इस तरह से टकराव के सेट से मूल संदेश बाहर खींच - सभी लेकिन कुछ अस्पष्ट हो जाएगा, और उन है कि वहाँ अभी भी एक बड़ी संख्या के माध्यम से अगर संदेश लंबाई किसी भी महत्वपूर्ण लंबाई है sift करने के लिए नहीं कर रहे हैं। एक क्रिप्टो हैश का नकारात्मक पक्ष यह है कि वे सामान्य रूप से गणना करने के लिए धीमी हैं।

तो, यह सब मतलब है तो Git के लिए क्या है? बहुत ज्यादा नहीं। हैश इतनी मुश्किल से किया जाता है (बाकी सब चीजों के सापेक्ष) कि उनकी कम्प्यूटेशनल पेनल्टी ऑपरेशन के लिए कम है। टकरावों की एक जोड़ी को मारने की संभावना इतनी कम है, यह तुरंत होने का वास्तविक मौका नहीं है और न ही पता लगाया जा सकता है (यानी आपका कोड सबसे अधिक संभावना है कि अचानक निर्माण बंद हो जाएगा), जिससे उपयोगकर्ता को समस्या को ठीक करने की अनुमति मिलती है (एक संशोधन वापस,) और फिर से बदलाव करें, और समय बदलने के कारण आपको निश्चित रूप से एक अलग हैश मिलेगा, जो हैश को भी हिट करता है)। यदि आप मनमाने ढंग से बायनेरीज़ को git में स्टोर कर रहे हैं, तो आपके लिए यह एक वास्तविक समस्या होने की अधिक संभावना है, जो वास्तव में प्राथमिक उपयोग मॉडल नहीं है। यदि आप ऐसा करना चाहते हैं ... आप शायद पारंपरिक डेटाबेस का उपयोग कर रहे हैं।

इस बारे में सोचना गलत नहीं है - यह एक अच्छा सवाल है कि बहुत सारे लोग बस पास हो जाते हैं क्योंकि "इतनी संभावना नहीं है कि यह सोचने लायक नहीं है" - लेकिन यह वास्तव में उससे थोड़ा अधिक जटिल है। यदि ऐसा होता है, तो यह बहुत आसानी से पता लगाया जाना चाहिए, यह एक सामान्य वर्कफ़्लो में एक मूक भ्रष्टाचार नहीं होगा।

Comments

you'll almost certainly get a different hash because of the time change, which also feeds the hash in gitहैश पूरी तरह से एक फ़ाइल की सामग्री पर आधारित नहीं है?

— fredoverflow

बूँद का हैश एक फ़ाइल की सामग्री पर आधारित होता है (मेटाडेटा के एक छोटे से) के साथ, हालांकि एक कमिट का हैश (जो सिद्धांत में भी टकरा सकता है) में वर्तमान समय, साथ ही पेड़ का हैश भी शामिल है। लेखक, माता-पिता का हैश आदि शुरू हो जाता है। हालाँकि, जैसा कि @Steve बताते हैं, छोटी चीज़ों के टकराने की संभावना कम होती है, और एक छोटी सी बात है।

— cdyson37

मुझे नहीं लगता कि मैं "कम डेटा, कम संभावना [टक्कर] होगा" से सहमत हूं। यदि आपके पास छोटी हैश है, तो आप संभव हैश = अधिक इनपुट मैप के सेट को प्रत्येक हैश = उच्च टक्कर के अवसर पर कम कर रहे हैं। यदि आपके पास हैश मैसेज का मतलब है कि आप हैशिंग हैं, तो यह केवल इस अर्थ में सही है कि संभावित इनपुट की संख्या उपयोग किए गए वर्णों की संख्या तक सीमित है, जो इतना स्पष्ट लगता है कि मुझे लगता है कि मुझे आपकी बात याद आ रही होगी?

— बेसिक

मैंने कभी भी "VERY SIMILAR" बिंदु के बारे में नहीं सोचा, जो वास्तव में एक अच्छा बिंदु है। इसका मूल रूप से मतलब है कि एक ही हैश के साथ 2 कमिट करने के लिए, आपको हर एक फ़ाइल में वर्णों के एक महत्वपूर्ण हिस्से को बदलना होगा (फ़ाइल नाम, पथ और फ़ाइलों की संख्या का उल्लेख नहीं करना)।

— पीटरन्यूट्स

@PieterNuyts नहीं, एक विशिष्ट हैश प्राप्त करने के लिए, एक प्रारंभिक प्रारंभिक फ़ाइल से, आपको आम तौर पर फ़ाइल में जानकारी को हैश में सूचना के बिट्स की संख्या के समान मात्रा में बदलना होगा, अर्थात, लगभग 160 बिट्स SHA-1। हालाँकि, इस बारे में जानकारी कि किन बिट्स को बदलना है, यहाँ भी गिना जाता है, इसलिए फ़ाइल, जितनी कम बिट्स आपको सही वाले को चुनना है, आपको बदलना होगा। Hypothetically, 2 ^ 160 बाइट्स के ऊपर अच्छी तरह से लंबाई की एक फ़ाइल दी गई है, आप एक बिट को बदलकर लगभग कोई हैश प्राप्त कर सकते हैं, क्योंकि उस बिट का स्थान 160 बिट्स से अधिक जानकारी रखता है!

— M Kloster

Answer 4

क्या इसके साथ रहने के लिए सुधार किया जा सकता है, या मुझे एक नए हैश एल्गोरिथ्म में बदलना होगा?

टक्कर किसी भी हैश एल्गोरिथ्म के लिए संभव है, इसलिए हैश फ़ंक्शन को बदलने से समस्या का सामना नहीं होता है, यह सिर्फ ऐसा होने की संभावना कम कर देता है। तो आपको तब एक बहुत अच्छा हैश फंक्शन (SHA-1 पहले से ही है) चुनना चाहिए, लेकिन आपने पूछा नहीं कि :)

Comments

मुझे लगता है कि आप "अधिक संभावना नहीं" या "कम संभावना" का मतलब है, है ना? यकीन है कि आप आउटपुट में कम बाइट के साथ एक हैश एल्गोरिथ्म में बदल सकते हैं , लेकिन इसका मतलब यह नहीं होगा, है ना? :)

— माइकलके

SHA-1 इस अर्थ में टूट गया है कि जानबूझकर हैश टकराव पैदा करना संभव हो जाएगा। मुझे लगता है कि यह पहले से ही 2012 में भी था। इसलिए एक अलग हैश में बदलना जो अधिक सुरक्षित है और एक बड़ा राज्य और आउटपुट है निश्चित रूप से एक अंतर होगा।

— मार्टन बोदवेस

Answer 5

आप " एक बूँद पर एक SHA-1 टकराव को कैसे संभालेंगे? " में एक अच्छा अध्ययन देख सकते हैं ।

चूंकि SHA1 की टक्कर अब संभव है (जैसा कि मैं इस उत्तर में बिखरता हूं।), यह जान लें कि Git 2.13 (Q2 2017) वर्तमान स्थिति को सुधार देगा / टकराव की स्थिति का पता लगाने के साथ-साथ SHA-1 कार्यान्वयन के प्रकार का पता लगाएगा। मार्क स्टीवंस (CWI) और डैन शुमो (Microsoft) द्वारा ।

प्रतिबद्ध देखें f5f5e7f , 8325e43 , कमिट c0c2006 , कमेंट 45a574e , जेफ किंग ( ) द्वारा 28dc98e (16 Mar 2017 ) । ^{(द्वारा विलय Junio सी Hamano - - में प्रतिबद्ध 48b3693 , 24 मार्च 2017)}peff
gitster

Makefile: DC_SHA1डिफ़ॉल्ट बनाएं

हम डिफ़ॉल्ट रूप से OpenSSL लाइब्रेरी से SHA1 कार्यान्वयन का उपयोग करते थे।
जैसा कि हम हाल ही में "बिखर" घोषणा के बाद टकराव के हमलों के खिलाफ सावधान रहने की कोशिश कर रहे हैं, इसके बजाय डिफॉल्ट को स्विच करें ताकि DC_SHA1 कार्यान्वयन का उपयोग किया जा सके।
जो लोग ओपनएसएसएल से कार्यान्वयन का उपयोग करना चाहते हैं, वे स्पष्ट रूप से इसके लिए पूछ सकते हैं OPENSSL_SHA1=YesPleaseजब " make" चल रहा हो ।

हमारे पास वास्तव में गिट-ऑब्जेक्ट की टक्कर नहीं है, इसलिए हम जो सबसे अच्छा कर सकते हैं, वह परीक्षण-sha1 के माध्यम से टूटे हुए पीडीएफ में से एक को चलाना है। यह टकराव की जांच को ट्रिगर करना चाहिए और मरना चाहिए।

---

क्या इसके साथ रहने के लिए Git में सुधार किया जा सकता है, या मुझे एक नए हैश एल्गोरिथ्म में बदलना होगा?

दिसम्बर २.१६ के साथ अद्यतन २०१ G २.१६ (Q1 २०१:): एक वैकल्पिक SHA का समर्थन करने का यह प्रयास चल रहा है: " Git अधिक आधुनिक SHA का उपयोग क्यों नहीं करता है? "।

आप एक और हैश एल्गोरिथ्म का उपयोग करने में सक्षम होंगे: SHA1 अब Git के लिए एकमात्र नहीं है।

---

2.18 (Q2 2018) दस्तावेज जो प्रक्रिया करते हैं।

देखें प्रतिबद्ध 5988eb6 , 45fa195 प्रतिबद्ध (26 मार्च 2018) द्वारा Ævar Arnfjörð Bjarmason ( avar) ।
^{(द्वारा विलय Junio सी Hamano - gitster- में प्रतिबद्ध d877975 , 11 अप्रैल 2018)}

डॉक्टर hash-function-transition: स्पष्ट करें कि SHAttered का क्या मतलब है

यह स्पष्ट करने का प्रयास किया जाता है कि शिट्टेड हमले का अर्थ क्या होता है।
पाठ के पिछले संस्करण ने इस बात का कोई जिक्र नहीं किया कि इस विशिष्ट हमले के लिए गीट के पास जो भी पहले से ही एक शमन है, जो दावा करता है कि SHAttered शोधकर्ता क्रिप्टानालिटिक टकराव के हमलों का पता लगाएंगे।

हो सकता है कि मैंने कुछ बारीकियों को गलत कर दिया हो, लेकिन जहाँ तक मुझे पता है कि यह नया पाठ सटीक स्थिति को संक्षेप में SHA-1 के साथ सम्‍मिलित करता है। यानी git वास्तव में अब SHA-1 का उपयोग नहीं करता है, यह Hardened-SHA-1 का उपयोग करता है (वे ऐसा ही आउटपुट 99.99999999999 ... समय का%) करने के लिए करते हैं।

इस प्रकार पिछले पाठ में यह कहना गलत था कि:

[...] परिणामस्वरूप [SHAttered], SHA-1 को क्रिप्टोग्राफिक रूप से किसी भी अधिक सुरक्षित नहीं माना जा सकता है [...]

ऐसी बात नहीं है। हम SHAttered के खिलाफ एक शमन है, हालांकि हम यह NewHashSHA-1 या कठोर-SHA-1 उभरने में भविष्य की कमजोरियों की दिशा में काम करना समझदारी मानते हैं ।

इसलिए नया दस्तावेज़ अब पढ़ता है:

G2 v2.13.0 और बाद में डिफ़ॉल्ट रूप से एक कठोर SHA-1 कार्यान्वयन में चला गया, जो SHAttered हमले के लिए असुरक्षित नहीं है।

इस प्रकार Git का प्रभाव पहले से ही एक नए हैश में चला गया है जो SHA-1 नहीं है और इसकी कमजोरियों को साझा नहीं करता है, इसका नया हैश फ़ंक्शन सभी ज्ञात इनपुट के लिए बिल्कुल समान आउटपुट उत्पन्न करने के लिए होता है, सिवाय SHAttered द्वारा प्रकाशित दो PDF को छोड़कर शोधकर्ताओं, और नए कार्यान्वयन (उन शोधकर्ताओं द्वारा लिखित) भविष्य के क्रिप्टानालिटिक टकराव के हमलों का पता लगाने का दावा करते हैं।

इसके बावजूद, SHA-1 के किसी भी संस्करण को नए हैश में ले जाना समझदारी माना जाता है। इस बात की कोई गारंटी नहीं है कि भविष्य में SHA-1 पर भविष्य के हमलों को प्रकाशित नहीं किया जाएगा, और उन हमलों में व्यवहार्य शमन नहीं हो सकता है।

यदि SHA-1 और इसके वेरिएंट को वास्तव में तोड़ा जाना था, तो Git के हैश फ़ंक्शन को क्रिप्टोग्राफ़िक रूप से सुरक्षित नहीं माना जा सकता है। यह हैश मानों के संचार को प्रभावित करेगा क्योंकि हम भरोसा नहीं कर सकते हैं कि किसी दिए गए हैश मूल्य सामग्री के ज्ञात अच्छे संस्करण का प्रतिनिधित्व करता है जो स्पीकर का इरादा था।

नोट: वही दस्तावेज अब (Q3 2018, Git 2.19) स्पष्ट रूप से SHA-256 के रूप में "नए हैश" का संदर्भ देता है : " Git अधिक आधुनिक SHA का उपयोग क्यों नहीं करता है? " देखें।

Comments

यह यहाँ का एकमात्र सभ्य उत्तर या टिप्पणी है। सारांश है - हालांकि बेहद संभावना नहीं है, यह संभव है। वे तुरंत भी अपरिचित होंगे, और टकराव से बचने के लिए एक फ़ाइल (टिप्पणी के साथ) को ट्विक करने के माध्यम से हटा दिया गया। जानबूझकर किए गए कारनामों को अप्रासंगिक माना जाता है, क्योंकि कोई व्यक्ति आसानी से "खराब कोड" में जांच कर सकता है - और हस्ताक्षर जैसी चीजें हैं और प्रक्रियात्मक को जानबूझकर खींचने के अनुरोध यादृच्छिक लोगों को यादृच्छिक चीजों में जाँच से रोकते हैं।

— ब्रैड

Answer 6

Google अब दावा करता है कि SHA-1 टक्कर कुछ पूर्व शर्त के तहत संभव है: https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html

चूँकि git फ़ाइल की अखंडता की जाँच करने के लिए SHA-1 का उपयोग करता है, इसका अर्थ है कि git में फ़ाइल अखंडता से छेड़छाड़ की जाती है।

IMO, git को निश्चित रूप से बेहतर हैशिंग एल्गोरिथ्म का उपयोग करना चाहिए क्योंकि जानबूझकर टक्कर अब संभव है।

Comments

इसके अलावा, कंप्यूटर सुरक्षा के बारे में लिनुस शब्द पर भरोसा नहीं करना समझदारी होगी। वह पहले भी गलत रहा है, और वह इस पर गलत है। (उदाहरण के लिए, एक SHA-1 टकराव की परिक्रमा एक सर्वर और क्लाइंट को समान रूप से क्रैश करने के लिए परिपत्र प्रतिबद्ध इतिहास बनाती है)

— DOMQ

Answer 7

एक हैश टक्कर इतनी अधिक संभावना नहीं है, कि यह सरासर मन उड़ाने वाला है! दुनिया भर के वैज्ञानिक एक को प्राप्त करने के लिए कड़ी मेहनत कर रहे हैं, लेकिन अभी तक इसे प्रबंधित नहीं किया है। कुछ एल्गोरिदम जैसे एमडी 5 के लिए वे सफल रहे, हालांकि।

हालात क्या हैं?

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!

लॉटरी जीतने का मौका लगभग 1: 14 Mio है । SHA-256 के साथ टक्कर की संभावना लगातार 11 दिनों पर लॉटरी जीतने की तरह है !

गणितीय व्याख्या: 14 000 000 ^ 11 ~ 2 ^ 256

इसके अलावा, ब्रह्मांड में लगभग 10 ^ 80 परमाणु हैं। यह SHA-256 संयोजनों की तुलना में सिर्फ 100 गुना अधिक है।

सफल MD5 टक्कर

एमडी 5 के लिए भी संभावनाएं कम हैं। हालांकि, गणितज्ञ एक टक्कर बनाने में कामयाब रहे:

d131dd02c5e6eec4 693d9a0698aff95c 2fcab5 8 712467eab 4004583eb8fb7f89
55ad340609f4b302 83e4888325 7 1415a 085125e8f7cdc99f d91dbdf280373c5b
d8823e3156348f5b ae6dacd436c919c6 dd53e2 b 487da03fd 02396306d248cda0
e99f33420f577ee8 ce54b67080 एक 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

इसका मतलब यह नहीं है कि एमडी 5 अब कम सुरक्षित है कि इसके एल्गोरिथ्म में दरार है। आप उद्देश्य पर एमडी 5 टक्कर बना सकते हैं, लेकिन एक आकस्मिक एमडी 5 टक्कर की संभावना अभी भी 2 ^ 128 है, जो अभी भी बहुत कुछ है।

निष्कर्ष

आप टकराव के बारे में एक चिंता करने की जरूरत नहीं है। हैशिंग एल्गोरिदम फ़ाइल साम्यता की जांच करने का दूसरा सबसे सुरक्षित तरीका है। एकमात्र सुरक्षित तरीका एक द्विआधारी तुलना है।

Comments

यह उत्तर ज्यादातर SHA-256 के बारे में बात करता है, जो कि सवाल SHA-1 के बारे में अप्रासंगिक है। SHA-1-टकराव की अनिच्छा दिखाते हुए गणित SHA-1 की तुलना में बहुत अधिक आशावादी है। इसके परिणामस्वरूप अभी भी बहुत संभावना नहीं है, लेकिन SHA-1 उत्तर अधिक प्रासंगिक होगा।

— एंड्रयू अरनोट Andrew

@AndrewArnott SHA-256 और SHA-1 के बीच कोई प्रासंगिक अंतर नहीं है। SHA-1 2 ^ 128 गुना कमजोर है, लेकिन यह भी कोई फर्क नहीं पड़ता। यह अभी भी विराम योग्य नहीं है, इसलिए मेरा उत्तर इतना गलत नहीं है ।

— bytecode77

SHA-1 वास्तव में टूट गया है, इसलिए यह कहना कि "अभी भी नहीं टूटने योग्य है" भी गलत है। यह देखते हुए कि SHA-1 वास्तव में टूटा हुआ है, कोई व्यक्ति जानबूझकर सामग्री का पता लगाने के लिए git के sha-1 एल्गोरिथम पर हमला कर सकता है। SHA-256 अभी तक नहीं टूटा है, इसलिए यह अधिक सुरक्षित होगा। इस प्रकार, संभावित git टक्करों के बारे में एक प्रश्न का उत्तर देना SHA-1 के लिए सर्वोत्तम होगा।

— एंड्रयू अरनॉट

"इसका मतलब यह नहीं है कि एमडी 5 अब कम सुरक्षित है कि इसके एल्गोरिथ्म में दरार है।" फिर से आना? क्या आप उस वाक्य की व्याख्या कर सकते हैं?

— मार्टन बोदवेस

उत्तर का कारण: क्योंकि उन लोगों में बहुत भ्रम है जो कंप्यूटिंग से परिचित नहीं हैं और अभी भी वेब पर खोज करने से यहां उतर रहे हैं। "एन्क्रिप्शन बनाम कंप्यूटिंग पावर" के बारे में गलत धारणाएं मेरे अनुभव में हैं जितना कि आप सोचते हैं कि मैंने इसे अतिरिक्त जानकारी के रूप में संबोधित किया है।

— bytecode77

Answer 8

वैसे मुझे लगता है कि अब हमें पता है कि क्या होगा - आपको उम्मीद करनी चाहिए कि आपका भंडार भ्रष्ट ( स्रोत ) हो जाएगा।

Answer 9

मैंने हाल ही में BSD चर्चा समूह में 2013-04-29 से पोस्टिंग पाई

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

जहां पोस्टर का दावा है:

मैं एक बार हैश टक्कर में भाग गया, git rebase का उपयोग करते हुए।

दुर्भाग्य से, वह अपने दावे के लिए कोई सबूत नहीं देता है। लेकिन शायद आप उससे संपर्क करने की कोशिश करना चाहेंगे और उससे इस कथित घटना के बारे में पूछेंगे।

लेकिन एक अधिक सामान्य स्तर पर, जन्मदिन के हमले के कारण SHA-1 हैश टकराव का एक मौका pow (2, 80) में 1 है।

यह बहुत लगता है और निश्चित रूप से संयुक्त दुनिया के सभी गिट रिपॉजिटरी में मौजूद व्यक्तिगत फ़ाइलों के संस्करणों की कुल संख्या से अधिक है।

हालाँकि, यह केवल उन संस्करणों पर लागू होता है जो वास्तव में संस्करण इतिहास में बने रहते हैं।

यदि कोई डेवलपर रिबासिंग पर बहुत अधिक निर्भर करता है, तो हर बार एक ब्रांच के लिए रिबेज चलाया जाता है, उस ब्रांच के सभी संस्करणों (या ब्रांच का रिबेडेड हिस्सा) में सभी नए हैश हो जाते हैं। हर फ़ाइल "git फ़िल्टर-शाखा" के साथ संशोधित होती है, वही सच है। इसलिए, "रिबेस" और "फिल्टर-ब्रांच" समय के साथ उत्पन्न होने वाली हैश की संख्या के लिए बड़े गुणक हो सकते हैं, भले ही उन सभी को वास्तव में नहीं रखा जाता है: अक्सर, रिबेसिंग के बाद (विशेष रूप से एक शाखा को "साफ करने" के उद्देश्य से) ), मूल शाखा को फेंक दिया जाता है।

लेकिन अगर रिबास या फिल्टर-शाखा के दौरान टकराव होता है, तो यह अभी भी प्रतिकूल प्रभाव डाल सकता है।

एक और बात यह होगी कि गिट रिपॉजिटरी में हैशेड संस्थाओं की कुल संख्या का अनुमान लगाना और देखें कि वे पॉव (2, 80) से कितनी दूर हैं।

मान लीजिए कि हमारे पास लगभग 8 बिलियन लोग हैं, और वे सभी जीआईटी चला रहे होंगे और अपने सामान को उस व्यक्ति के 100 जीआईटी रिपॉजिटरी में रखा जाएगा। आगे 'मान लें कि औसत रिपॉजिटरी में 100 कमिट और 10 फाइलें हैं, और उन फाइलों में से केवल एक ही प्रति प्रतिबद्ध है।

प्रत्येक संशोधन के लिए हमारे पास कम से कम वृक्ष वस्तु और प्रतिबद्ध वस्तु के लिए एक हैश है। परिवर्तित फ़ाइल के साथ हमारे पास प्रति संशोधन में 3 हैश है, और इस प्रकार प्रति भंडार 300 हैश है।

8 बिलियन लोगों की 100 रिपॉजिटरी के लिए यह पॉव (2, 47) देता है जो अभी भी पॉव (2, 80) से बहुत दूर है।

हालांकि, इसमें ऊपर उल्लिखित माना गुणन प्रभाव शामिल नहीं है, क्योंकि मैं अनिश्चित हूं कि इस अनुमान में इसे कैसे शामिल किया जाए। शायद यह टकराव की संभावना को काफी बढ़ा सकता है। खासकर अगर बहुत बड़े रिपॉजिटरी जो एक लंबे समय तक चलने वाले इतिहास (जैसे लिनक्स कर्नेल) को कई लोगों द्वारा छोटे बदलावों के लिए रिबूट किया जाता है, जो सभी प्रभावित कमिटों के लिए अलग-अलग हैश बनाते हैं।

Comments

दिलचस्प। +1। जैसा कि मैंने ऊपर उल्लेख किया है, यह समस्या अंततः दूर हो जाएगी: stackoverflow.com/a/47838703/6309

— VonC