एमडी 5 चेकसम का मूल्य क्या है यदि एमडी 5 हैश खुद भी संभवतः हेरफेर कर सकता है?

Question

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

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

MD5 चेकसम कैसे जानबूझकर परिवर्तित फ़ाइलों के खिलाफ कोई सुरक्षा प्रदान कर सकता है अगर चेकसम खुद समझौता किया गया है, तो यह जानने का कोई तरीका नहीं है?

Comments

अगर हम MD5 हैश अभिनय की प्रामाणिकता की मुहर के बजाय सूक्ष्म टाइमस्टैम्प विसंगतियों को देख रहे वेबसाइट होस्ट पर भरोसा कर रहे हैं ... तो चेकसम द्वारा प्रदान की गई सुरक्षा बहुत अधिक वाष्पित हो गई है।

— ऑस्टिन '' डेंजर '' पॉवर्स

@BigChris मुझे यकीन नहीं है कि आपका क्या मतलब है, लेकिन यह गलत लगता है। क्रिप्टोग्राफ़िक हैश एल्गोरिदम एमडी 5 जैसे संदेश डेटा के बारे में पूरी तरह से हैं। एक ही लंबाई के दो यादृच्छिक संदेशों में लगभग निश्चित रूप से अलग-अलग हैश होंगे।

— मैट नॉर्डहॉफ

@MattNordhoff बिल्कुल। एक MD5 चेकसम फ़ाइल डेटा के आधार पर उत्पन्न नहीं होती है, तो क्या है उस पर आधारित?

— ऑस्टिन '' डेंजर '' पॉवर्स

MD5 हैश डेटा का निर्माण डेटा पर किया जाएगा, हाँ, लेकिन यह उसी हैश के साथ दुर्भावनापूर्ण फ़ाइल बनाने के लिए बहुत अधिक प्रयास नहीं करेगा। जैसा कि कहा गया है कि जाँच का कोई तरीका नहीं होगा कि फ़ाइल दुर्भावनापूर्ण थी या नहीं। पढ़ें: mscs.dal.ca/~selinger/md5collision

— किंकिक्टस

कभी-कभी हैश प्रथम-पक्षीय सर्वर पर प्रकाशित होते हैं जबकि वास्तविक डाउनलोड तृतीय-पक्ष दर्पण और / या CDN पर होस्ट किए जाते हैं।

— el.pescado

Answer 1

मैंने सुना है कि किसी भी दुर्भावनापूर्ण परिवर्तन का भी पता लगाने के लिए [...] की अनुमति है।

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

Comments

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

— डेविड स्पिललेट

आप यह भी है कि difital हस्ताक्षर को संबोधित इस सीमा (यह मानते हुए कि आप प्रमाण पत्र पर भरोसा / अधिकार को प्रमाणित) अपने जवाब में जोड़ने के लिए चाहते हो सकता है

— ATK

यह इससे भी बदतर है - यदि कोई आपके ट्रैफ़िक के साथ / सर्वर से छेड़छाड़ कर सकता है, तो भले ही सर्वर से समझौता न किया जाए, वे आपके द्वारा प्राप्त होने वाली फ़ाइल और चेकसम दोनों को संशोधित कर सकते हैं।

— cpast

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

— cpast

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

— मैथ्यू एलवे

Answer 2

कुछ पैकेज मैनेजमेंट सिस्टम जैसे dpkg द्वारा उपयोग किया जाने वाला समाधान हैश पर हस्ताक्षर करना है : सार्वजनिक कुंजी हस्ताक्षरित एल्गोरिदम में से किसी एक पर इनपुट के रूप में हैश का उपयोग करें। Http://www.pgpi.org/doc/pgpintro/#p12 देखें

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

Answer 3

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

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

Answer 4

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

मैं यहां वर्षों से सुरक्षित चेकसमों की कमी के बारे में लिख रहा हूं ।

MITM हमलों के जोखिम के कारण, उपयोगकर्ताओं को अविश्वसनीय नेटवर्क पर अविश्वसनीय निष्पादन योग्य डाउनलोड नहीं करना चाहिए और उन्हें चलाना चाहिए। पी। रुइसेन, आर। व्लोथोसेन द्वारा उदाहरण के लिए, "स्वचालित अपडेट सिस्टम के भीतर असुरक्षा"।

2014 परिशिष्ट: नहीं, यह गलत नहीं है "वेब पृष्ठों पर पोस्ट किए गए चेकसम का उपयोग दुर्भावनापूर्ण संशोधनों का पता लगाने के लिए किया जाता है," क्योंकि यह एक भूमिका है जो वे प्रदर्शन कर सकते हैं। वे आकस्मिक भ्रष्टाचार से बचाने में मदद करते हैं, और अगर HTTPS पर सेवा की जाती है या सत्यापित हस्ताक्षर (या बेहतर अभी तक, दोनों) दुर्भावनापूर्ण भ्रष्टाचार से बचाने में मदद करते हैं! मैंने HTTPS पर चेकसम प्राप्त किए हैं और सत्यापित किया है कि वे कई बार HTTP डाउनलोड से मेल खाते हैं।

आजकल, बायनेरिज़ अक्सर हस्ताक्षरित, स्वचालित रूप से सत्यापित हैश के साथ वितरित किए जाते हैं, फिर भी यह पूरी तरह से सुरक्षित नहीं है ।

उपरोक्त लिंक से अंश: "KeRanger एप्लिकेशन को एक मान्य मैक ऐप डेवलपमेंट सर्टिफिकेट के साथ हस्ताक्षरित किया गया था; इसलिए, यह Apple के गेटकीपर सुरक्षा को बायपास करने में सक्षम था।" ... "Apple ने दुरुपयोग प्रमाणपत्र और अपडेट किए गए XProtect एंटीवायरस हस्ताक्षर को निरस्त कर दिया है, और ट्रांसमिशन प्रोजेक्ट ने अपनी वेबसाइट से दुर्भावनापूर्ण इंस्टॉलर को हटा दिया है। Palo Alto Networks ने KeRanger को सिस्टम को प्रभावित करने से रोकने के लिए URL फ़िल्टरिंग और खतरा निवारण को भी अद्यतन किया है। तकनीकी विश्लेषण

दो KeRanger संक्रमित ट्रांसमिशन इंस्टॉलर्स को Apple द्वारा जारी एक वैध प्रमाण पत्र के साथ हस्ताक्षरित किया गया था। डेवलपर ने इस प्रमाणपत्र को सूचीबद्ध किया है जो ID Z7276PX673 के साथ एक तुर्की कंपनी है, जो ट्रांसमिशन इंस्टॉलर के पिछले संस्करणों पर हस्ताक्षर करने के लिए उपयोग की जाने वाली डेवलपर आईडी से अलग थी। कोड साइनिंग जानकारी में, हमने पाया कि ये इंस्टॉलर 4. मार्च की सुबह उत्पन्न हुए और हस्ताक्षर किए गए थे। "

2016 एडेंडा:

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

कुछ और बातें: CRC32 एक चेकसम है। एमडी 5, एसएचए, आदि चेकसम से अधिक हैं; वे सुरक्षित हैश होने का इरादा रखते हैं। इसका मतलब है कि वे टक्कर के हमलों के लिए बहुत प्रतिरोधी हैं। एक चेकसम के विपरीत, एक सुरक्षित रूप से संप्रेषित सुरक्षित हैश एक मैन-इन-बीच (MITM) हमले से बचाता है जहां MITM सर्वर और उपयोगकर्ता के बीच होता है। यह उस हमले से बचाव नहीं करता है जहाँ सर्वर खुद समझौता करता है। उस से बचाने के लिए, लोग आमतौर पर पीजीपी, जीपीजी, गेटकीपर आदि जैसी चीजों पर भरोसा करते हैं।

Comments

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

— ब्रेकथ्रू

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

— कॉर्नस्टाल्स

+1! लेकिन ... क्या एक हस्ताक्षरित हैश वास्तव में सुरक्षित ( भरोसेमंद ) है जैसा कि एक अहस्ताक्षरित हैश ने https (ssl / कर्ल) पर लिया है? मुझे लगता है कि यह अभी भी बेहतर है कि हैश खुद वैसे भी हस्ताक्षरित है ...

— matpop

Answer 5

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

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

Comments

यदि किसी व्यक्ति को किसी स्वतंत्र स्रोत के माध्यम से पता चलता है कि किसी फ़ाइल के भरोसेमंद संस्करण का अपेक्षित हैश क्या होना चाहिए, तो हॉल्ट दुर्भावनापूर्ण परिवर्तन से रक्षा कर सकता है। वेब साइट होने के मूल्य इसकी फ़ाइलों के हैश मानों को सूचीबद्ध करने में झूठ नहीं बोलते हैं, जो किसी साइट से फ़ाइलों को डाउनलोड करने के लिए उसी साइट के खिलाफ डाउनलोड की गई फ़ाइल के हैश की जांच करते हैं, बल्कि उन लोगों को बताने में करते हैं जो किसी अन्य स्रोत से जानते हैं जिस फ़ाइल को वे चाहते हैं , उसका हैश , पता करें कि क्या प्रश्न फ़ाइल उसको डाउनलोड करने से पहले मेल खाएगी। BTW, एक चीज जो मैं देखना चाहता हूं ...

— सुपरकैट

... URL / URI का एक रूप होगा जिसमें एक अपेक्षित हैश मान (शायद MD5 के बजाय SHA) शामिल है, और यह निर्दिष्ट करेगा कि एक ब्राउज़र को केवल एक फ़ाइल स्वीकार करनी चाहिए यदि हैश निर्दिष्ट है। ऐसे मामलों में जहां एक ही बड़ी फ़ाइल को कई लोगों द्वारा एक्सेस करने की आवश्यकता होगी, उन सभी लोगों को https: // के माध्यम से एक URL दिया जाएगा, लेकिन उन्हें प्रॉक्सी से फ़ाइल डाउनलोड करने से अधिक उन सभी को उपयोग करने की तुलना में अधिक कुशल हो सकता है: https: // सीधे स्रोत से।

— सुपरकैट

@supercat मेरा मतलब है कि "लोगों को चेकसम के साथ खिलवाड़ करने से रोकें" - कुछ को सुरक्षित रूप से स्थानांतरित किया जाना चाहिए, और अगर वह चेकसम है तो चेकसम फाइल के साथ दुर्भावनापूर्ण छेड़छाड़ से बचाने में मदद कर सकता है।

— cpast

एक MD5 चेकसम एक फ़ाइल के अलावा कुछ पथ के माध्यम से प्रेषित होता है जो छेड़छाड़ के खिलाफ सुरक्षा प्रदान करेगा जब तक कि इस तरह की छेड़छाड़ को सुविधाजनक बनाने के लिए फ़ाइल जानबूझकर नहीं बनाई गई थी। इसके विपरीत, CRC32 जैसी कोई चीज़ छेड़छाड़ के खिलाफ लगभग कोई सुरक्षा प्रदान नहीं करेगी, भले ही फ़ाइल का मूल स्रोत विश्वसनीय हो और CRC32 को सुरक्षित रूप से वितरित किया गया हो।

— सुपरकाट

Answer 6

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

एक संभावित समाधान हस्ताक्षरित फ़ाइलों का उपयोग है।

(BTW: MD5 कहीं भी असुरक्षित है और इसका उपयोग अब और नहीं किया जाना चाहिए।)

Answer 7

MD5 चेकसम कैसे जानबूझकर परिवर्तित फ़ाइलों के खिलाफ कोई सुरक्षा प्रदान कर सकता है अगर चेकसम खुद समझौता किया गया है, तो यह जानने का कोई तरीका नहीं है?

आप पूरी तरह से सही हैं। लक्ष्य, तब, आपका "अगर" गलत होगा - अगर हम जानते हैं कि किसी फ़ाइल के सुरक्षित क्रिप्टोग्राफ़िक हैश से समझौता नहीं किया जाता है, तो हम जानते हैं कि फ़ाइल से समझौता नहीं किया गया है।

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

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

Comments

Gpg के बारे में: याद रखें कि यह इसी तरह की समस्याएं हैं यदि आप पूरी तरह से सार्वजनिक कुंजी पर भरोसा नहीं करते हैं तो एक समझौता नहीं किया गया है और इसके साथ निजी कुंजी के साथ हस्ताक्षरित सामग्री।

— डेविड स्पिललेट

Answer 8

आप फ़ाइल को संशोधित किए बिना MD5 चेकसम को भी संशोधित नहीं कर सकते। यदि आप फ़ाइल को डाउनलोड करते हैं, तो हैश डाउनलोड करें, और फिर फ़ाइल के आपके गणना में जो दिया गया है, वह मेल नहीं खाता है, या तो हैश या फ़ाइल गलत या अपूर्ण है।

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

फ़ाइल को संशोधित करने से हस्ताक्षर अमान्य हो जाएंगे, इसलिए इसका उपयोग फ़ाइल अखंडता को सत्यापित करने के लिए भी किया जा सकता है।

Answer 9

Hashes इंगित करते हैं कि क्या फ़ाइल का आपका संस्करण ("डाउनलोड") सर्वर के संस्करण से अलग है। वे फ़ाइल की प्रामाणिकता की कोई गारंटी नहीं देते हैं।

डिजिटल हस्ताक्षर (असममित एन्क्रिप्शन + हैश फ़ंक्शन) का उपयोग यह सत्यापित करने के लिए किया जा सकता है कि फ़ाइल को किसी ऐसे व्यक्ति द्वारा संशोधित नहीं किया गया है जिसके पास निजी कुंजी नहीं है।

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

केवल फ़ाइल को संशोधित करने से श्री "ए। हॅकर" को रोकना है, फिर इसे अपनी निजी कुंजी के साथ हस्ताक्षर करना है?

फ़ाइल को मान्य करने के लिए, आपको इसके हैश की तुलना उसी से करने की ज़रूरत है जिसे आपने संबंधित डिजिटल हस्ताक्षर को डिक्रिप्ट करके प्राप्त किया था। यदि आपको लगता है कि फ़ाइल "IMAwesome" से है, तो आप हैश को उसकी कुंजी का उपयोग करके डिक्रिप्ट करते हैं और हैश फ़ाइल से मेल नहीं खाता है, क्योंकि हैश को A.Hacker की कुंजी का उपयोग करके एन्क्रिप्ट किया गया था।

इसलिए डिजिटल हस्ताक्षर एक व्यक्ति को आकस्मिक और दुर्भावनापूर्ण दोनों परिवर्तनों का पता लगाने की अनुमति देते हैं।

लेकिन हम पहली बार में IMAwesome की सार्वजनिक कुंजी कैसे प्राप्त कर सकते हैं? हम यह कैसे सुनिश्चित कर सकते हैं कि जब हमने उसकी चाबी प्राप्त की थी, तो यह वास्तव में A.Hacker की कुंजी नहीं थी जो कि एक समझौता किए गए सर्वर या एक मानव-मध्य हमले द्वारा की गई थी? यह वह जगह है जहां प्रमाण पत्र श्रृंखला और विश्वसनीय रूट प्रमाण पत्र आते हैं, जिनमें से कोई भी समस्या का पूरी तरह से सुरक्षित [1] समाधान नहीं है, और दोनों को संभवतः विकिपीडिया पर और एसओ पर अन्य प्रश्नों पर अच्छी तरह से समझाया जाना चाहिए।

[१] निरीक्षण करने पर, रूट सर्टिफिकेट जो माइक्रोसॉफ्ट ओएस के साथ मेरे कार्य पीसी पर भेजते हैं, में यूएस सरकार का एक प्रमाणपत्र शामिल है। इसी निजी कुंजी खाँसी एनएसए खाँसी के उपयोग के साथ कोई भी इसलिए मेरे वेब ब्राउज़र को सामग्री परोस सकता है जो "पता बार में एक पैडलॉक है" चेक करता है। कितने लोगों को वास्तव में ताला पर क्लिक करें और देखने के लिए परेशान करेगा कौन है कुंजी-जोड़ी करने के लिए इस्तेमाल किया जा रहा है "सुरक्षित" कनेक्शन?

Comments

यह केवल एक व्यक्ति को लेता है जो एक घोटाले का कारण बनने के लिए प्रमाण पत्र श्रृंखला की जांच करता है। यदि आपको लगता है कि NSA MITM के लिए एक सरकारी CA कुंजी का उपयोग निजी तौर पर आयोजित या चोरी किए गए एक से अधिक उपयोग करने के बजाय विदेशी प्रमाणपत्र प्राधिकारी (इस प्रकार प्रशंसनीय विकृतीकरण प्रदान करता है) करने के लिए करता है, तो मेरे पास आपको बेचने के लिए एक पुल है।

— चार्ल्स डफी

मैं इस संभावना का सुझाव दे रहा था कि इसका उपयोग किसी विशेष उपयोगकर्ता पर MITM को लक्षित करने के लिए किया जा सकता है। जैसा कि यह वास्तव में संभावना है, कि टिन-फ़ॉइल लोगों के लिए बहस करने के लिए है

— मार्क के कोवान

मैं यह सवाल नहीं कर रहा हूं कि क्या लक्षित MITM की संभावना है। मैं सवाल कर रहा हूं कि क्या यह आसानी से पता लगाया जा सकता है कि आसानी से पता लगाया जा सकता है और इसे करने के लिए CA कुंजी को जिम्मेदार ठहराया है। पर्याप्त रूप से उच्च-मूल्य लक्ष्य के लिए, आउटबाउंड 'नेट ट्रैफ़िक मेटाडेटा को SSL हैंडशेक के सार्वजनिक भाग को शामिल करने और शामिल करने के लिए पर्याप्त विवरण में दर्ज किया जा सकता है, इसलिए भले ही उपयोगकर्ता नहीं दिखता हो, उनके सुरक्षा कर्मचारी या स्वचालित बुनियादी ढांचा पूर्वव्यापी विश्लेषण में ऐसा कर सकता है।

— चार्ल्स डफी

Answer 10

MD5 चेकसम कैसे जानबूझकर बदली गई फ़ाइलों के खिलाफ कोई सुरक्षा प्रदान कर सकता है अगर चेकसम के साथ समझौता नहीं किया गया है, तो यह जानने का कोई तरीका नहीं है?

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

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

अपने उदाहरण का उपयोग करते हुए, जबकि एमडी 5 चेकसम अपने स्वयं के पाठ फ़ाइल में एक फ़ाइल के बगल में बैठ सकता है, प्राधिकरण रिकॉर्ड एमडी 5 चेकसम एक गैर-कनेक्टेड डेटाबेस सिस्टम में संग्रहीत किया जाएगा। इसलिए यदि किसी ने डेटा को हेरफेर करने के लिए किसी फ़ाइलशेयर में हैक किया है, तो उस घुसपैठिये का एमडी 5 प्राधिकरण रिकॉर्ड या कनेक्टेड इतिहास तक कोई पहुंच नहीं होगी।

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

तो मान लीजिए कि आपके पास एक संग्रह में 5 फाइलें हैं। एसीई ऑडिट मैनेजर में उन 5 फ़ाइलों को फिर एक और मिलेगा - चलो इसे "माता-पिता" कहते हैं - प्रत्येक फ़ाइल के 5 एमडी 5 चेकसम से उत्पन्न हैश है। इसलिए अगर कोई सिर्फ एक फ़ाइल के साथ छेड़छाड़ करता है, तो फ़ाइल के लिए हैश बदल जाएगा और इसलिए पूरे "माता-पिता" संग्रह के लिए हैश होगा।

सामान्य तौर पर आपको एमडी 5 चेकसम और संबंधित अखंडता हैश को देखने की जरूरत है जब तक कि वे एमडी 5 हैश के लिए कुछ गैर-प्रत्यक्ष भंडारण से जुड़े नहीं हैं, वे दूषित हो सकते हैं। और एक दीर्घकालिक डेटा अखंडता उपकरण के रूप में उनका मूल्य एक सस्ते लॉक के बराबर है जो सामान के एक नए टुकड़े पर "मुक्त" आता है; यदि आप अपने सामान को लॉक करने के बारे में गंभीर हैं, तो आपको एक ताला मिलेगा जिसे 5 सेकंड में पेपरक्लिप के साथ नहीं खोला जा सकता है।

Comments

"एमडी 5 चेकसम का एमडी 5 चेकसम" एक मर्कल ट्री के रूप में जाना जाता है ।

— pjc50

@ pjc50 धन्यवाद! संदर्भ के उत्तर को संपादित किया।

— जेकगोल्ड 19

Answer 11

गति

अक्सर लोग पाते हैं कि यह (a) कुछ अविश्वसनीय "पास में" सामग्री वितरण नेटवर्क (CDN), मिरर साइट, टोरेंट पीयर्स इत्यादि से एक बड़ी फ़ाइल डाउनलोड करता है और संबंधित शॉर्ट चेकसम फ़ाइल (अक्सर SHA256; पुराने सॉफ़्टवेयर) भी डाउनलोड करता है; अक्सर कुछ विश्वसनीय स्रोतों से एमडी 5 का उपयोग किया जाता है। वे इसे असहनीय रूप से धीमी गति से पाते हैं (बी) पूरी बड़ी फ़ाइल को एक विश्वसनीय स्रोत से सीधे डाउनलोड करते हैं।

मान्यता

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

परिवर्तन

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

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

जैसा कि cpast ने पहले कहा है, यदि एक अच्छा क्रिप्टोग्राफिक चेकसम एक विश्वसनीय कनेक्शन पर प्रसारित होता है, तो यह सुरक्षा प्रदान कर सकता है (जो कि विश्वसनीय कनेक्शन से प्राप्त होता है)।

जैसा कि सुपरकैट ने पहले कहा है, चेकसम फाइल एक साइट उन लोगों की मदद नहीं करती है जो एक ही साइट से बड़ी फाइल डाउनलोड करते हैं और उसी तरह से वे चेकसम फाइल डाउनलोड करते हैं - वे उन लोगों की मदद करते हैं जो किसी अन्य साइट से फाइल डाउनलोड करना चाहते हैं।

"सुरक्षा के संदर्भ में, क्रिप्टोग्राफिक हैश जैसे एमडी 5 असुरक्षित दर्पण से प्राप्त डेटा के प्रमाणीकरण के लिए अनुमति देते हैं। एमडी 5 हैश पर हस्ताक्षर करना चाहिए या उस संगठन के सुरक्षित स्रोत (HTTPS पेज) से आना चाहिए जिस पर आप भरोसा करते हैं।" - https://help.ubuntu.com/community/HowToMD5SUM

क्रिप्टोग्राफिक चेकसम व्यावहारिक सार्वजनिक-कुंजी हस्ताक्षरों का एक महत्वपूर्ण हिस्सा हैं (जैसा कि GnuPG और अन्य OpenPGP- अनुरूप सॉफ़्टवेयर में लागू किया गया है)। सार्वजनिक-कुंजी हस्ताक्षरों के अकेले चेकसमों पर कुछ फायदे हैं।

Answer 12

मैंने यह सुना है [एमडी 5 चेकसम] अनुमति देने के लिए [...] भी किसी भी दुर्भावनापूर्ण परिवर्तनों का आसानी से पता लगाया जा सकता है।

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

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

यहाँ एक वास्तविक दुनिया उदाहरण है जो पूरी बात स्पष्ट कर सकती है। निम्नलिखित मार्ग विषय पर विशेष रूप से महत्वपूर्ण है:

पुराने संग्रहीत सीडी रिलीज़ के लिए, केवल MD5 चेकसम उत्पन्न किए गए थे [...] नई रिलीज़ के लिए, नए और क्रिप्टोग्राफ़िक रूप से अधिक मजबूत चेकसम एल्गोरिदम (SHA1, SHA256 और SHA512) का उपयोग किया जाता है