Git अधिक आधुनिक SHA का उपयोग क्यों नहीं करता है?

Question

मैंने पढ़ा है कि Git एक संशोधन के लिए ID के रूप में SHA-1 डाइजेस्ट का उपयोग करता है। यह SHA के अधिक आधुनिक संस्करण का उपयोग क्यों नहीं करता है?

Comments

प्रदर्शन ही एकमात्र ऐसा कारण है जिसके बारे में मैं सोच सकता हूं, SHA-1, SHA-2 से तेज है। व्यक्तिगत रूप से मैं इसे एक बुरा निर्णय मानता हूं, क्योंकि SHA-1 का टक्कर प्रतिरोध कमज़ोर है।

— कोडइन्चोज

stackoverflow.com/questions/9392365/… - एक सटीक मैच नहीं है, लेकिन इसी तरह के मैदान को कवर करता है

— नरमी

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

— tbc0

अपडेट: SHA-1 अब जंगली बिखर

— it

Q1 2018: एक वैकल्पिक SHA का समर्थन करने का यह प्रयास चल रहा है: नीचे मेरा उत्तर देखें

— VONC

Answer 1

यह SHA के अधिक आधुनिक संस्करण का उपयोग क्यों नहीं करता है?

दिसंबर 2017: यह होगा और Git 2.16 (Q1 2018) उस आशय को स्पष्ट और कार्यान्वित करने वाली पहली रिलीज़ है।

नोट: नीचे 2.19 Git देखें: यह SHA-256 होगा ।

Git 2.16 Git में किस हैश फ़ंक्शन का उपयोग करता है, यह परिभाषित करने के लिए एक बुनियादी ढाँचा प्रस्तावित करेगा, और विभिन्न कोडपाथों में इसे गिराने का प्रयास शुरू करेगा।

रामसे जोन्स (``) द्वारा प्रतिबद्ध c250e02 (28 नवंबर 2017) देखें । प्रतिबद्ध देखें , eBay0ccfd , 78a6766 , f50e766 के लिए प्रतिबद्ध करें , ब्रायन एम द्वारा abade65 (12 नवंबर 2017) । कार्लसन ( ) । ^{(द्वारा विलय Junio सी Hamano - - में प्रतिबद्ध 721cc43 , 13 दिसंबर 2017)}
bk2204
gitster

---

हैश एल्गोरिथ्म का प्रतिनिधित्व करने वाली संरचना जोड़ें

चूंकि भविष्य में हम एक अतिरिक्त हैश एल्गोरिथ्म का समर्थन करना चाहते हैं, एक संरचना जोड़ें जो एक हैश एल्गोरिथ्म का प्रतिनिधित्व करता है और सभी डेटा जो इसके साथ जाने चाहिए । हैश एल्गोरिदम की आसान गणना करने के लिए
एक निरंतर जोड़ें । अमूर्त एपीआई बनाने के लिए फ़ंक्शन को
लागू करें जिसका उपयोग किसी भी हैश एल्गोरिथ्म द्वारा किया जा सकता है, और इस SHA के अनुरूप मौजूदा SHA1 फ़ंक्शन के लिए रैपर।typedefs

हेक्स आकार के साथ-साथ बाइनरी आकार के लिए एक मूल्य का पर्दाफाश करें ।
जबकि एक हमेशा दूसरे से दोगुना होगा, दोनों मानों का उपयोग आमतौर पर पूरे कोडबेस में किया जाता है और दोनों ही बेहतर पठनीयता प्रदान करते हैं।

शून्य ऑब्जेक्ट आईडी के लिए हैश एल्गोरिथ्म संरचना में एक प्रविष्टि शामिल न करें।
जैसा कि यह मान सभी शून्य है, किसी भी उपयुक्त आकार के सभी-शून्य ऑब्जेक्ट आईडी का उपयोग किया जा सकता है, और किसी दिए गए हैश के आधार पर स्टोर करने की कोई आवश्यकता नहीं है।

वर्तमान हैश फ़ंक्शन संक्रमण योजना ऐसे समय में लागू होती है, जब हम SHA-1 या NewHash प्रारूप में उपयोगकर्ता से इनपुट स्वीकार करेंगे।
चूँकि हम यह नहीं जान सकते हैं कि उपयोगकर्ता ने जो प्रदान किया है, वह अज्ञात एल्गोरिदम का निरूपण करके हमें यह सूचित करने की अनुमति देता है कि हमें सही मूल्य देखना चाहिए।

---

रेपो सेटअप के साथ हैश एल्गोरिदम को एकीकृत करें

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

एक स्थिरांकthe_hash_algo जोड़ें , जो hash_algoरिपॉजिटरी ग्लोबल में स्ट्रक्चर पॉइंटर को इंगित करता है।
ध्यान दें कि यह वह हैश है जिसका उपयोग डेटा को डिस्क में क्रमबद्ध करने के लिए किया जाता है, न कि हैश में जो उपयोगकर्ता को आइटम प्रदर्शित करने के लिए उपयोग किया जाता है।
संक्रमण योजना का अनुमान है कि ये भिन्न हो सकते हैं।
हम ui_hash_algoइस मामले के लिए भविष्य में एक अतिरिक्त तत्व जोड़ सकते हैं (कह सकते हैं )।

---

Git 2.19 (Q3 2018) के लिए अगस्त 2018 को अपडेट करें, Git को SHH -256 को NewHash के रूप में चुनना है।

जोनाथन Nieder ( ) द्वारा देखें 0ed8d8d (04 अगस्त 2018 ) । देखें प्रतिबद्ध 13f5e09 द्वारा (25 जुला 2018) Ævar Arnfjörð Bjarmason ( ) । ^{(द्वारा विलय Junio सी Hamano - - में प्रतिबद्ध 34f2297 , 20 अगस्त 2018)}artagnon
avar
gitster

डॉक्टरhash-function-transition : SHA-256 को न्यू हैश के रूप में चुनें

सुरक्षा के दृष्टिकोण से, ऐसा लगता है कि SHA-256, BLAKE2, SHA3-256, K12, और इसी तरह सभी पर समान सुरक्षा गुण पाए जाते हैं।
सुरक्षा के दृष्टिकोण से सभी अच्छे विकल्प हैं।

SHA-256 के कई फायदे हैं:

• यह थोड़ी देर के लिए आसपास रहा है, व्यापक रूप से उपयोग किया जाता है, और बस हर एक क्रिप्टो लाइब्रेरी (ओपनएसएसएल, mbedTLS, CryptoNG, SecureTransport, आदि) द्वारा समर्थित है।

• जब आप SHA1DC के खिलाफ तुलना करते हैं, तो अधिकांश वेक्टराइज्ड SHA-256 कार्यान्वयन वास्तव में तेज होते हैं, यहां तक ​​कि त्वरण के बिना भी।

• यदि हम OpenPGP के साथ हस्ताक्षर कर रहे हैं (या यहां तक ​​कि, मुझे लगता है, सीएमएस), हम SHA-2 का उपयोग करने जा रहे हैं, तो इसका मतलब यह नहीं है कि हमारी सुरक्षा दो अलग-अलग एल्गोरिदम पर निर्भर करती है जब उनमें से एक अकेले सुरक्षा को तोड़ सकते हैं जब हम सिर्फ एक पर निर्भर हो सकते हैं।

तो SHA-256 यह है ।
ऐसा कहने के लिए हैश-फंक्शन-ट्रांज़िशन डिज़ाइन को अपडेट करें।

इस पैच के बाद, स्ट्रिंग का कोई शेष उदाहरण नहीं है " NewHash", 2008 में एक चर नाम केt/t9700/test.pl रूप में एक असंबंधित उपयोग को छोड़कर ।

---

आप इस बदलाव को SHA 256 में Git 2.20 (Q4 2018) के साथ प्रगति पर देख सकते हैं:

देखें प्रतिबद्ध 0d7c419 , dda6346 प्रतिबद्ध , eccb5a5 प्रतिबद्ध , 93eb00f प्रतिबद्ध , d8a3a69 प्रतिबद्ध , प्रतिबद्ध fbd0e37 , प्रतिबद्ध f690b6b , प्रतिबद्ध 49d1660 , प्रतिबद्ध 268babd , प्रतिबद्ध fa13080 , प्रतिबद्ध 7b5e614 , 58ce21b प्रतिबद्ध , प्रतिबद्ध 2f0c9e9 , 825544a प्रतिबद्ध (15 अक्टू 2018) द्वारा ब्रायन मीटर । कार्लसन ( bk2204) । SZEDER गैबर ( ) द्वारा प्रतिबद्ध 6afedba (15 अक्टूबर 2018)
देखें । ^{(द्वारा मर्ज किया गया}szeder
^{gitsterजूनियो सी हमानो - - in प्रतिबद्ध d829d49 , 30 अक्टूबर 2018)}

हार्ड-कोडेड स्थिरांक को बदलें

कई 40-स्थिरांक स्थिरांक को संदर्भ के साथ GIT_MAX_HEXSZया the_hash_algo, उपयुक्त के रूप में बदलें ।
उपयोग के सभी उपयोगों को परिवर्तित GIT_SHA1_HEXSZकरें the_hash_algoताकि वे किसी भी हैश लंबाई के लिए उपयुक्त हों।
एक हेक्स ऑब्जेक्ट आईडी के आकार के लिए हार्ड-कोडित स्थिरांक का उपयोग करने के बजाय parse_oid_hex, पार्स की गई ऑब्जेक्ट आईडी के बाद उस बिंदु से गणना सूचक का उपयोग करने के लिए स्विच करें ।

GIT_SHA1_HEXSZGit 2.22 (Q2 2019) के साथ आगे हटा / बदल दिया गया है और d4e568b प्रतिबद्ध है ।

---

यह परिवर्तन Git 2.21 (Q1 2019) के साथ जारी है, जो sha-256 हैश जोड़ता है और कोड के माध्यम से इसे "NewHash" के साथ Git बनाने की अनुमति देता है।

देखें प्रतिबद्ध 4b4e291 , 27dc04c प्रतिबद्ध , 13eeedb प्रतिबद्ध , प्रतिबद्ध c166599 , प्रतिबद्ध 37649b7 , प्रतिबद्ध a2ce0a7 , प्रतिबद्ध 50c817e , 9a3a0ff प्रतिबद्ध , प्रतिबद्ध 0dab712 , प्रतिबद्ध 47edb64 (14 नवंबर 2018), और 2f90b9d प्रतिबद्ध , 1ccf07c प्रतिबद्ध (22 अक्टू 2018) द्वारा ब्रायन मीटर । कार्लसन ( bk2204) ।
^{( जूनियो सी gitsterहमानो द्वारा विलय - - में 33e4ae9 , 29 जनवरी 2019)}

SHA-256 समर्थन (फरवरी 2019) का आधार कार्यान्वयन जोड़ें

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

SHA-256 आधारित बंद का एक मूल कार्यान्वयन जोड़ें libtomcrypt, जो सार्वजनिक डोमेन में है।
इसे ऑप्टिमाइज़ करें और इसे हमारे कोडिंग मानकों को पूरा करने के लिए पुनर्गठन करें।
अद्यतन और अंतिम कार्यों में SHA-1 ब्लॉक कार्यान्वयन से खींचो, क्योंकि हम सभी संकलक के साथ इन फ़ंक्शन को सही ढंग से जानते हैं। यह कार्यान्वयन SHA-1 की तुलना में धीमा है, लेकिन भविष्य में आने वाले समय में अधिक प्रदर्शनकारी कार्यान्वयन शुरू किए जाएंगे।

हैश एल्गोरिदम की सूची में SHA-256 को तार करें, और एक परीक्षण जोड़ें जो एल्गोरिथ्म सही ढंग से काम करता है।

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

hash: OpenSSL का उपयोग करके SHA-256 कार्यान्वयन जोड़ें

हमारे पास पहले से ही SHA-1 के लिए ओपनएसएसएल रूट उपलब्ध हैं, इसलिए SHA-256 के लिए भी रूटीन जोड़ें।

एक कोर 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

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

GnuPG के साथ अधिकांश सिस्टम भी होंगे libgcrypt, क्योंकि यह GnuPG की निर्भरता है।
libgcryptकुछ KiB और बड़े संदेशों के लिए SHA1DC कार्यान्वयन से भी तेज़ है।

तुलना के लिए, एक कोर i7-6600U पर, यह कार्यान्वयन 355 MiB / s पर 16 KiB विखंडन को संसाधित करता है जबकि SHA1DC 337 MiB / s पर बराबर विखंडू को संसाधित करता है।

इसके अलावा, एलजीपीएल 2.1 के तहत लिबगक्रिप्ट लाइसेंस प्राप्त है, जो जीपीएल के साथ संगत है। 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 अगस्त 2019) ब्रायन एमbk2204 द्वारा । कार्लसन ( ) ।
^{(द्वारा विलय Junio सी Hamano - gitster- में 676278f प्रतिबद्ध , 11 अक्टू 2019)}

उपयोग करने GIT_SHA1_HEXSZऔर हार्ड-कोडित स्थिरांक के बजाय, उपयोग करने के लिए स्विच करें the_hash_algo।

---

Git 2.26 (Q1 2020) के साथ, परीक्षण स्क्रिप्ट उस दिन के लिए तैयार हैं जब ऑब्जेक्ट नाम SHA-256 का उपयोग करेगा।

देखें 277eb5a प्रतिबद्ध , 44b6c05 प्रतिबद्ध , 7a868c5 प्रतिबद्ध , 1b8f39f प्रतिबद्ध , a8c17e3 प्रतिबद्ध , 8,320,722 प्रतिबद्ध , 74ad99b प्रतिबद्ध , ba1be1a प्रतिबद्ध , cba472d प्रतिबद्ध , 82d5aeb प्रतिबद्ध , प्रतिबद्ध 3c5e65c , प्रतिबद्ध 235d3cd , 1d86c8f प्रतिबद्ध , प्रतिबद्ध 525a7f1 , 7a1bcb2 प्रतिबद्ध , cb78f4f प्रतिबद्ध , प्रतिबद्ध 717c939 , प्रतिबद्ध 08a9dd8 , 215b60b प्रतिबद्ध , 194264 सी(२१ दिसंबर २०१ ९) ब्रायन एमbk2204 द्वारा । कार्लसन ( ) ।
^{(द्वारा विलय Junio सी Hamano - gitster- में f52ab33 प्रतिबद्ध , 05 फरवरी 2020)}

उदाहरण:

t4204: हैश आकार स्वतंत्र करें

^{साइन-ऑफ-बाय: ब्रायन एम। कार्लसन}

$OID_REGEXएक हार्ड-कोडेड नियमित अभिव्यक्ति के बजाय उपयोग करें ।

इसलिए, उपयोग करने के बजाय:

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

टेस्ट का उपयोग कर रहे हैं

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

और ब्रायन एम द्वारा प्रतिबद्ध बीडी 9 एलसीडी (13 मई 2018) OID_REGEXसे आता है । कार्लसन ( ) । ^{(द्वारा विलय Junio सी Hamano - - में 9472b13 प्रतिबद्ध , 30 मई 2018, Git v2.18.0-RC0)}bk2204
gitster

t/test-lib: परिचय OID_REGEX

^{साइन-ऑफ-बाय: ब्रायन एम। कार्लसन}

वर्तमान में हमारे पास एक चर है, $_x40,जिसमें एक रेगेक्स होता है जो पूर्ण 40-वर्ण हेक्स स्थिरांक से मेल खाता है।

हालाँकि, NewHashहमारे पास 40 से अधिक वर्णों वाले ऑब्जेक्ट ID होंगे।

ऐसे मामले में, $_x40एक भ्रमित नाम होगा।

एक $OID_REGEXवैरिएबल बनाएं जो वर्तमान हैश की लंबाई की परवाह किए बिना उपयुक्त ऑब्जेक्ट आईडी से मेल खाते एक रेगेक्स को हमेशा प्रतिबिंबित करेगा।

और, अभी भी परीक्षण के लिए:

देखें प्रतिबद्ध f303765 , edf0424 प्रतिबद्ध , 5db24dc प्रतिबद्ध , d341e08 प्रतिबद्ध , प्रतिबद्ध 88ed241 , 48c10cc प्रतिबद्ध , f7ae8e6 प्रतिबद्ध , प्रतिबद्ध e70649b , a30f93b प्रतिबद्ध , a79eec2 प्रतिबद्ध , 796d138 प्रतिबद्ध , 417e45e प्रतिबद्ध , dfa5f53 प्रतिबद्ध , f743e8f प्रतिबद्ध , 72f936b प्रतिबद्ध , 5df0f11 प्रतिबद्ध , प्रतिबद्ध 07877f3 , 6025e89 प्रतिबद्ध , 7b1a182 प्रतिबद्ध , प्रतिबद्ध 94db7e3 ,bri mbk2204 द्वारा db12505 (07 फरवरी 2020) । कार्लसन ( ) ।
^{(द्वारा विलय Junio सी Hamano - gitster- में प्रतिबद्ध 5af345a , 17 फ़र 2020)}

t5703: SHA-256 के साथ परीक्षण कार्य करें

^{साइन-ऑफ-बाय: ब्रायन एम। कार्लसन}

इस परीक्षण में एक ऑब्जेक्ट आईडी का उपयोग किया गया था, जिसकी लंबाई 40 हेक्स वर्ण थी, जिसके कारण परीक्षण न केवल पास हुआ, बल्कि लटका हुआ था, जब हैश के रूप में SHA-256 के साथ चलाया गया।

इस मान को एक निश्चित डमी ऑब्जेक्ट आईडी का उपयोग करके बदलें test_oid_initऔर test_oid।

इसके अलावा, सुनिश्चित करें कि हम एक निश्चित लंबाई के बजाय खेतों के साथ कट का उपयोग करके उचित लंबाई की एक वस्तु आईडी निकालें।

---

कुछ कोडपैथ को रिपॉजिटरी में काम करने के लिए एक पैरामीटर के रूप में एक रिपॉजिटरी उदाहरण दिया गया था, लेकिन the_repositoryइसके कैलीज़ को उदाहरण दिया गया, जिसे गिट 2.26 (Q1 2020) के साथ साफ किया गया है (कुछ हद तक)।

देखें b98d188 प्रतिबद्ध , 2dcde20 प्रतिबद्ध , 7ad5c44 प्रतिबद्ध , c8123e7 प्रतिबद्ध , 5ec9b8a प्रतिबद्ध , a651946 प्रतिबद्ध , eb999b3 प्रतिबद्ध (30 जनवरी 2020) द्वारा माथिउस Tavares ( matheustavares) ।
^{( जूनियो सी gitsterहमानो द्वारा विलय - - में cdcd६ 14 एलसीडी , १४ फरवरी २०२०)}

sha1-file: check_object_signature()किसी भी रेपो को संभालने की अनुमति

^{साइन-ऑफ-बाय: मैथ्यूस तवारेस}

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

पर आधारित:

sha1-file: पास git_hash_algoकरनाhash_object_file()

^{साइन-ऑफ-बाय: मैथ्यूस तवारेस}

hash_object_file()एक git_hash_algoपैरामीटर को पेश करके मनमाना रेपो पर काम करने की अनुमति दें । उन कॉलर्स को बदलें, जिनके पास रेपोओ से पास होने के लिए उनके दायरे में एक स्ट्रक्चर रिपॉजिटरी पॉइंटर है git_hash_algo।
अन्य सभी कॉलर्स के लिए, पास करें the_hash_algo, जो पहले से ही आंतरिक रूप से उपयोग किया जा रहा था hash_object_file()।
इस कार्यशीलता का उपयोग निम्नलिखित पैच में किया जाएगा ताकि वे check_object_signature()मनमाने ढंग से रिपोज पर काम कर सकें (जो बदले में, object.cparse_object ()) में एक असंगति को ठीक करने के लिए उपयोग किया जाएगा ।

Comments

इसके अलावा, यह मत भूलो कि Git v2.13.0 और बाद में डिफ़ॉल्ट रूप से एक कड़े SHA-1 कार्यान्वयन में चला गया, जो SHAttered हमले के लिए असुरक्षित नहीं है। देखें stackoverflow.com/a/43355918/6309

— VONC

1: गूगल का उत्पादन टक्कर shattered.io फ़रवरी 2017 में (अनुमानित लागत $ 110,000) 2: नानयांग प्रौद्योगिकी विश्वविद्यालय एक टक्कर का उत्पादन किया sha-mbles.github.io जनवरी 2019 में (अनुमानित लागत $ 11k के बीच - $ 45k) यह समय आ गया है पिछले SHA1

— bristweb

@bristweb "यह गेट SHA1 को स्थानांतरित करने का समय है": मैं सहमत हूं, और Git 2.25 (आज जारी) के साथ, वह कदम एक हो जाता है। git rev-parseअब यह प्रिंट करने में सक्षम है कि किस हैश का उपयोग किया जाएगा: stackoverflow.com/a/58862319/6309 । और खाली पेड़ की नई SHA2 आईडी है: stackoverflow.com/a/9766506/6309

— VonC

इस हैश एल्गो एक्स्टेंसिबिलिटी के साथ, CRC32 आखिरकार फिर से चमक सकता है।

— वाल

Answer 2

अद्यतन : उपरोक्त प्रश्न और यह उत्तर 2015 से हैं। तब से Google ने पहली SHA-1 टक्कर की घोषणा की है: https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html

---

जाहिर है कि मैं केवल बाहर से देखने के बारे में अनुमान लगा सकता हूं कि आखिर क्यों GA SHA-1 का उपयोग जारी रखता है, लेकिन ये निम्न कारणों से हो सकते हैं:

1. गिट लिनुस टॉर्वाल्ड का निर्माण था, और लिनस जाहिरा तौर पर इस समय एक और हैशिंग एल्गोरिथ्म के साथ SHA-1 को स्थानापन्न नहीं करना चाहता है।
2. वह प्रशंसनीय दावे करता है कि GIT के खिलाफ सफल SHA-1 टकराव-आधारित हमले, स्वयं टकरावों को प्राप्त करने की तुलना में एक अच्छा सौदा है, और यह देखते हुए कि SHA-1 इससे कमजोर है, पूरी तरह से नहीं तोड़ा जाना चाहिए, जिससे यह काफी हद तक दूर हो जाता है कम से कम आज हमला करने योग्य। इसके अलावा, वह नोट करता है कि एक "सफल" हमला बहुत कम हासिल करेगा यदि टकराने वाली वस्तु मौजूदा एक की तुलना में बाद में आती है, क्योंकि बाद में एक को वैध माना जाएगा और इसे अनदेखा किया जाएगा (हालांकि अन्य ने बताया है कि उलटा हो सकता है)।
3. सॉफ्टवेयर बदलना समय-उपभोक्ता और त्रुटि-प्रवण होता है, विशेषकर तब जब मौजूदा प्रोटोकॉल और मौजूदा प्रोटोकॉल के आधार पर डेटा होता है, जिसे माइग्रेट करना होगा। यहां तक ​​कि सॉफ्टवेयर और हार्डवेयर उत्पाद बनाने वाले भी जहां क्रिप्टोग्राफिक सुरक्षा प्रणाली का एकमात्र बिंदु है, अभी भी SHA-1 और स्थानों में अन्य कमजोर एल्गोरिदम से दूर जाने की प्रक्रिया में हैं। बस उन सभी हार्डकोड unsigned char[20]बफ़र्स की कल्पना करें; ;-), बाद में इसे वापस लेने के बजाय, शुरुआत में क्रिप्टोग्राफ़िक चपलता के लिए प्रोग्राम करना बहुत आसान है।
4. SHA-1 का प्रदर्शन विभिन्न SHA-2 हैश की तुलना में बेहतर है (शायद अब तक एक सौदा तोड़ने वाला नहीं है, लेकिन शायद 10 साल पहले एक स्टिकिंग पॉइंट था), और SHA-2 का भंडारण आकार बड़ा है ।

कुछ लिंक:

• Git में टक्कर होने पर क्या होता है, इस पर स्टाकेवरफ्लो सवाल
• 2005 में मुख्य SHA-1 की कमजोरी बनने के कुछ महीने बाद इस विषय पर लिनुस की एक संक्षिप्त टिप्पणी दिखाती न्यूज़ग्रुप पोस्ट
• 2006 में sha-256 (लिनुस के उत्तरों के साथ) की कमजोरी और संभावित कदम पर चर्चा करने वाला एक धागा
• SHA-1 पदावनति पर NIST कथन और हैश के मजबूत SHA-2 परिवार में तेजी से संक्रमण के लिए "सिफारिश"

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

Comments

"आपके पास ऐसे लोग हो सकते हैं, जो दुर्भावनापूर्ण होने की कोशिश करते हैं। वे सफल नहीं होंगे। यह विशुद्ध रूप से एक संगति जाँच है। " -लीनस टोरवाल्ड्स

— शक्ति

कुछ भी सत्यापित करने के लिए अपने कोड पर लोगों के सुरक्षित हस्ताक्षर के लिए Git की हैश को सुरक्षित करने की आवश्यकता है। ये हस्ताक्षर इन हैश के एक विशाल वृक्ष पर हस्ताक्षर करते हैं। यदि उस पेड़ की कुछ शाखा टकराती है, तो हस्ताक्षर पास करते समय दुर्भावनापूर्ण कोड डाला जा सकता है। Git का उपयोग अब अविश्वसनीय रूप से व्यापक रूप से किया जाता है। हैश अपग्रेड की जरूरत है।

— fuzzyTew

"बिखर" के प्रकाश में विचार करने के लिए दो चीजें: 1. SHA-1 उपयोग। - SHA-1 का इस्तेमाल आकस्मिक भ्रष्टाचार के खिलाफ जांच के लिए एक गौरवशाली चेकसम के रूप में किया जाता है। - SHA-1 का उपयोग एक जनरेटर फ़ंक्शन के रूप में किया जाता है ताकि इसकी सामग्री पता योग्य स्टोर (यानी: ग्लोरिफाइड फ़ाइल-नाम जनरेटर) के अंदर वस्तुओं को नामित करने के लिए (कुछ हद तक) छोटी हेक्स संख्या दी जाए। - यह हस्ताक्षर किए गए हैं जो सुरक्षा के लिए ज़िम्मेदार हैं (यानी: सार्वजनिक-कुंजी क्रिप्टोग्राफी सिगंक्चर। शॉ -1 नहीं)

— DrYak

2. व्यवहार्यता - GPU समय के टन के बाद, Google ब्लॉक श्रृंखला की एक जोड़ी उत्पन्न करने में कामयाब रहा है। - दोनों एक ही SHA-1 राशि (कि टक्कर) के लिए हैश - वे पूरी तरह से रगड़ रहे हैं (यह सही साबित करने के लिए मुश्किल हो रहा है कि क्यों आपके कमेंट में बीच में बाइनरी जंक का एक विशाल ब्लॉक है)। - बिखरता डेमो अलग-अलग व्यवहार पेश करने के तरीके पर निर्भर करता है, जिसके आधार पर यादृच्छिक बाइनरी जंक मौजूद है। यह पीडीएफ के साथ संभव है (जिसके पीछे एक एम्बेडिंग स्क्रिप्टिंग भाषा छिपी है)। बहुत सादा स्रोत पर कठिन हो रहा है यही कारण है कि (लगता गुप्त सी प्रतियोगिता)

— DrYak

@DYYak 2 के लिए: मान लेते हैं कि आप उन पर टिप्पणी क्षेत्र के साथ फ़ोटोशॉप दस्तावेज़ ट्रैक कर रहे हैं। या मेटा टैग के साथ अन्य मीडिया फ़ाइलें। यह खेल के विकास में एक विशिष्ट मामला है। लेकिन वे आम तौर पर हर बदलाव पर जाँच नहीं करेंगे: यदि मेटा संदेश "आकार के लिए अनुकूलन" कहता है, तो मेटा-टैग की जाँच क्यों करें?

— आर्ने बबेनहोशीराइड

Answer 3

यह Mercurial के लिए SHA1 से दूर जाने की तात्कालिकता की चर्चा है, लेकिन यह Git पर भी लागू होता है: https://www.mercurial-scm.org/wiki/mpm/SHA1

संक्षेप में: यदि आप आज बहुत सुस्त नहीं हैं, तो आपके पास sha1 की तुलना में बहुत अधिक कमजोरियां हैं। लेकिन इसके बावजूद, 10 साल पहले मर्कुरियल ने शुरुआत की थी ताकि वह श 1 से दूर चले जाए।

SHA1 के उत्तराधिकारियों के लिए Mercurial के डेटा संरचनाओं और प्रोटोकॉल को वापस लाने के लिए वर्षों से काम चल रहा है। हमारे रिग्लॉग स्ट्रक्चर में बड़ी हैश के लिए स्टोरेज स्पेस को 10 साल पहले मर्क्यूरियल 0.9 में RevlogNG की शुरूआत के साथ आवंटित किया गया था। बंडल 2 प्रारूप ने हाल ही में नेटवर्क पर विभिन्न हैश प्रकारों के आदान-प्रदान का समर्थन किया है। केवल शेष टुकड़े एक प्रतिस्थापन समारोह का विकल्प हैं और एक पश्चगामी-अनुकूलता रणनीति चुनना है।

यदि मर्क्यूरियल करने से पहले git sha1 से दूर नहीं जाता है, तो आप hg-git के साथ एक स्थानीय मर्क्यूरियल दर्पण रखकर हमेशा सुरक्षा का एक और स्तर जोड़ सकते हैं ।

Answer 4

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

विचाराधीन कुछ हैश SHA-256, SHA-512/256, SHA-256x16, K12 और BLAKE2bp-256 हैं