सीआरसी एल्गोरिदम आम तौर पर हैमिंग दूरी की स्थिति के तहत त्रुटि का पता लगाने की गारंटी देता है। सीमित संख्या में बिट फ़्लिप को देखते हुए, CRC _necessily_ एक भिन्न परिणाम उत्पन्न करेगा।

यह उन स्थितियों में उपयोगी साबित हो सकता है जहां त्रुटियों को केवल कुछ बिट्स फ्लिप करने के लिए माना जाता है।
कुछ दशक पहले, यह अपेक्षाकृत सामान्य था, खासकर ट्रांसमिशन परिदृश्यों में, क्योंकि अंतर्निहित सिग्नल अभी भी बहुत "कच्चा" था, इसलिए भौतिक परत पर ज्ञात बिट फ़्लिप एक चीज़ थी।

हालांकि इस संपत्ति की वितरण लागत है। एक बार "सुरक्षित" हैमिंग दूरी पार हो जाने के बाद, टक्कर की संभावना और भी खराब हो जाती है। यह पिजन होल सिद्धांत का तार्किक परिणाम है। कितना बुरा? खैर, यह सटीक सीआरसी पर निर्भर करता है, लेकिन मुझे उम्मीद है कि अच्छा सीआरसी 3x - 7x बदतर रेंज में होगा। यह बहुत अच्छा लग सकता है, लेकिन यह सिर्फ 2-3 बिट्स फैलाव में कमी है, इसलिए यह इतना भयानक नहीं है। फिर भी।

इसके विपरीत "आदर्श" वितरण संपत्ति की विशेषता वाले हैश के साथ: कोई भी परिवर्तन, चाहे वह एक बिट या पूरी तरह से अलग आउटपुट हो, टकराव उत्पन्न करने की बिल्कुल 1/2 ^ n संभावना है। यह समझना आसान है: टक्कर का जोखिम हमेशा समान होता है। सीआरसी के साथ सीधी तुलना में, जब हैमिंग दूरी छोटी होती है तो टक्कर की दर बदतर होती है (क्योंकि यह> 0 है), लेकिन हैमिंग दूरी बड़ी होने पर यह बेहतर होता है।

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

इस नए परिवेश में, शर्त यह है कि त्रुटियां, जब वे होती हैं, "बिटफ्लिप" श्रेणी में नहीं रह जाती हैं। किस मामले में, सीआरसी की वितरण संपत्तियां एक दायित्व बन जाती हैं। एक शुद्ध हैश में वास्तव में टकराव पैदा करने की संभावना कम होती है।

यह तब होता है जब केवल चेकसमिंग पर विचार किया जाता है।
एक "आदर्श" हैश की एक अतिरिक्त संपत्ति यह है कि, हैश से बिट्स के किसी भी खंड को निकालते समय, यह अभी भी इस 1 / 2^n टकराव की संभावना को प्रदर्शित करता है, जो अन्य संरचनाओं के लिए बिट्स के स्रोत के रूप में बहुत महत्वपूर्ण है, जैसे कि हैश टेबल या ब्लूम फिल्टर। इसके विपरीत, सीआरसी ऐसी गारंटी प्रदान नहीं करता है। कुछ बिट्स बहुत अनुमानित या अत्यधिक सहसंबद्ध होते हैं, और जब उन्हें हैश उद्देश्य के लिए निकाला जाता है, तो फैलाव बहुत खराब होता है।

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

PIC/Arduino भीड़ के भीतर, लोग अभी भी पुराने साधारण 8-बिट चेकसम, 16-बिट फ्लेचर योग या 16-बिट CRC का उपयोग करते हैं।
(...)
8 या 16 बिट तक कम होने पर हैश फ़ंक्शंस के साथ कुछ स्वाभाविक रूप से खराब है?

एक अच्छे हैश के गुणों के कारण, हैश से 8 या 16 बिट निकालना वास्तव में संभव है, जिसके परिणामस्वरूप 1/256 या 1/65535 टकराव की संभावना है। मुझे इस पर कोई चिंता नहीं दिखती।

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

सीआरसी एल्गोरिदम आम तौर पर हैमिंग दूरी की स्थिति के तहत त्रुटि का पता लगाने की गारंटी देता है। सीमित संख्या में बिट फ़्लिप को देखते हुए, CRC _necessily_ एक भिन्न परिणाम उत्पन्न करेगा।

यह उन स्थितियों में उपयोगी साबित हो सकता है जहां त्रुटियों को केवल कुछ बिट्स फ्लिप करने के लिए माना जाता है।
कुछ दशक पहले, यह अपेक्षाकृत सामान्य था, खासकर ट्रांसमिशन परिदृश्यों में, क्योंकि अंतर्निहित सिग्नल अभी भी बहुत "कच्चा" था, इसलिए भौतिक परत पर ज्ञात बिट फ़्लिप एक चीज़ थी।

हालांकि इस संपत्ति की वितरण लागत है। एक बार "सुरक्षित" हैमिंग दूरी पार हो जाने के बाद, टक्कर की संभावना और भी खराब हो जाती है। यह पिजन होल सिद्धांत का तार्किक परिणाम है। कितना बुरा? खैर, यह सटीक सीआरसी पर निर्भर करता है, लेकिन मुझे उम्मीद है कि अच्छा सीआरसी 3x - 7x बदतर रेंज में होगा। यह बहुत अच्छा लग सकता है, लेकिन यह सिर्फ 2-3 बिट्स फैलाव में कमी है, इसलिए यह इतना भयानक नहीं है। फिर भी।

इसके विपरीत "आदर्श" वितरण संपत्ति की विशेषता वाले हैश के साथ: कोई भी परिवर्तन, चाहे वह एक बिट या पूरी तरह से अलग आउटपुट हो, टकराव उत्पन्न करने की बिल्कुल 1/2 ^ n संभावना है। यह समझना आसान है: टक्कर का जोखिम हमेशा समान होता है। सीआरसी के साथ सीधी तुलना में, टक्कर की दर खराब होती है (क्योंकि यह> 0 है) जब हैमिंग दूरी छोटी होती है, लेकिन हैमिंग दूरी बड़ी होने पर यह बेहतर होता है।

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

इस नए परिवेश में, शर्त यह है कि त्रुटियां, जब वे होती हैं, "बिटफ्लिप" श्रेणी में नहीं रह जाती हैं। किस मामले में, सीआरसी की वितरण संपत्तियां एक दायित्व बन जाती हैं। एक शुद्ध हैश में वास्तव में टकराव पैदा करने की संभावना कम होती है।

यह तब होता है जब केवल चेकसमिंग पर विचार किया जाता है।
एक "आदर्श" हैश की एक अतिरिक्त संपत्ति यह है कि, हैश से बिट्स के किसी भी खंड को निकालते समय, यह अभी भी इस 1 / 2^n टकराव की संभावना को प्रदर्शित करता है, जो अन्य संरचनाओं के लिए बिट्स के स्रोत के रूप में बहुत महत्वपूर्ण है, जैसे कि हैश टेबल या ब्लूम फिल्टर। इसके विपरीत, सीआरसी ऐसी गारंटी प्रदान नहीं करता है। कुछ बिट्स बहुत अनुमानित या अत्यधिक सहसंबद्ध होते हैं, और जब उन्हें हैश उद्देश्य के लिए निकाला जाता है, तो फैलाव बहुत खराब होता है।

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

PIC/Arduino भीड़ के भीतर, लोग अभी भी पुराने साधारण 8-बिट चेकसम, 16-बिट फ्लेचर योग या 16-बिट CRC का उपयोग करते हैं।
(...)
8 या 16 बिट तक कम होने पर हैश फ़ंक्शंस के साथ कुछ स्वाभाविक रूप से खराब है?

एक अच्छे हैश के गुणों के कारण, हैश से 8 या 16 बिट निकालना वास्तव में संभव है, जिसके परिणामस्वरूप 1/256 या 1/65535 टकराव की संभावना है। मुझे इस पर कोई चिंता नहीं दिखती।

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

हम जानते हैं कि सीआरसी 32 के साथ और एचडी = 6 का उपयोग करके यह किसी भी 5-बिट त्रुटियों का पता लगा सकता है और यह 2 ^ 31 = लगभग 204 एमबी तक के फटने का पता लगा सकता है
और सभी सिंगल-बिट त्रुटियों का पता लगाएं
xxHash में, कितने बिट्स को बदलने की आवश्यकता है ताकि हम किसी त्रुटि का पता न लगा सकें?
मुझे पता है कि हैश में भी 1-बिट परिवर्तन पूरी तरह से अलग डाइजेस्ट बनाता है लेकिन हम टक्कर बनाने के लिए आवश्यक बिट्स की संख्या की गणना कैसे कर सकते हैं?
जैसा कि आपने उल्लेख किया है एक और प्रश्न है:

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

यह बुरा क्यों है? यदि बिट्स किसी तरह सहसंबद्ध हैं तो क्या हम इस सहसंबंध का उपयोग क्षतिग्रस्त फ़ाइल को सुधारने के लिए कर सकते हैं?

xxHash में, कितने बिट्स को बदलने की आवश्यकता है ताकि हम एक त्रुटि (या टकराव) का पता न लगा सकें

1 बिट।

xxHash एक गैर-क्रिप्टोग्राफ़िक हैश फ़ंक्शन है, चेकसम नहीं। यह कोई हैमिंग दूरी या टक्कर प्रतिरोध गारंटी प्रदान नहीं करता है।

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

xxHash में, कितने बिट्स को बदलने की आवश्यकता है ताकि हम एक त्रुटि (या टकराव) का पता न लगा सकें

1 बिट।

xxHash एक गैर-क्रिप्टोग्राफ़िक हैश फ़ंक्शन है, चेकसम नहीं। यह कोई हैमिंग दूरी या टक्कर प्रतिरोध गारंटी प्रदान नहीं करता है।

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

क्या आपका मतलब है कि हम केवल 1 बिट डेटा बदलकर डिकोडर को बेवकूफ बना सकते हैं?
यह टकराव पैदा कर सकता है? (यह डरावना है) और इस तरह के टकराव की संभावना डाइजेस्ट आकार पर निर्भर करती है

क्या आपका मतलब है कि हम केवल 1 बिट डेटा बदलकर डिकोडर को बेवकूफ बना सकते हैं?

2 अलग-अलग सामग्रियों से उत्पन्न हैश मानों को ध्यान में रखते हुए, टकराव की संभावना हमेशा 1 / 2^64 (अच्छी गुणवत्ता वाले 64-बिट हैश एल्गोरिदम के लिए, जैसे xxh64 या xxh3 ), जो भी हो उन 2 सामग्रियों के बीच संशोधनों की मात्रा।

इसका वास्तव में मतलब है कि, कम से कम सिद्धांत रूप में, एक बिट के परिवर्तन से टकराव उत्पन्न हो सकता है।

अब, ध्यान रखें कि यह प्रायिकता 1 / 2^64 , जो कि बहुत अधिक असीम है।
लोग इस विषय को समझने में अपेक्षाकृत खराब हैं। वे कभी-कभी इसे "छोटा" के साथ जोड़ते हैं, जिसे ज्यादातर लोगों के दिमाग में एक वास्तविक राशि के रूप में माना जाता है, जैसे ~ 10%।

अधिक सटीक विचार प्राप्त करने के लिए, मैं इस तालिका को देखना पसंद करता हूं:

यानी : 1 / 2 ^ 64 सीधे किसी के सिर पर धूमकेतु प्राप्त करने की संभावना से बहुत कम है, और राष्ट्रीय लॉटरी _3 बार लगातार जीतने की तुलना में कम है (जो कि संदिग्ध होगा)। यह वास्तव में "शून्य" के बहुत करीब है। सॉफ़्टवेयर बग के अन्य स्रोतों से शुरू करके, किसी भी सिस्टम के अधिकांश घटकों की तुलना में _much_ अधिक संभावना के साथ टूटने की संभावना होती है।

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

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

कुछ बिट्स बहुत अनुमानित या अत्यधिक सहसंबद्ध होते हैं, और जब उन्हें हैश उद्देश्य के लिए निकाला जाता है, तो फैलाव बहुत खराब होता है।

यह बुरा क्यों है?

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

यदि बिट्स किसी तरह सहसंबद्ध हैं तो क्या हम इस सहसंबंध का उपयोग क्षतिग्रस्त फ़ाइल को सुधारने के लिए कर सकते हैं?

यह बिल्कुल अलग विषय है।
एक सीआरसी के साथ क्षतिग्रस्त इनपुट की मरम्मत नहीं करता है। एक सीआरसी केवल एक त्रुटि का पता लगा सकता है, उसे सुधार नहीं सकता।

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

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

261 XXH3 के 64-बिट संस्करण में एकल बिट टकराव को प्रदर्शित करता है, हालांकि यह बीज-निर्भर है और यादृच्छिक इनपुट पर होने की संभावना नहीं है।

वास्तव में; अधिक पूर्ण होने के लिए, मेरा पिछला कथन इनपुट> 240 बाइट्स के लिए बड़े आकार के अनुभाग में निर्देशित किया गया था।

लेकिन हां, आकार की सीमित सीमा में जहां इनपुट को 64-बिट secret में से एक से मेल खाना है, एक सिंगल-बिट टकराव संभव हो जाता है। यह स्वीकार्य लगा क्योंकि एक सटीक स्थान पर एक सटीक 64-बिट इनपुट पर आधारित टक्कर अभी भी इस 1 / 2^64 क्षेत्र के भीतर है, यह मानते हुए कि इनपुट यादृच्छिक है (अर्थात टक्कर उत्पन्न करने के लिए इंजीनियर नहीं)। इसके अलावा, मिलान करने के लिए secret को प्रभावी ढंग से _secret_ बनाया जा सकता है, इसलिए एक बाहरी हमलावर को इसे खोजने के लिए अपने तरीके से जबरदस्ती करना होगा।

क्या आपका मतलब है कि हम केवल 1 बिट डेटा बदलकर डिकोडर को बेवकूफ बना सकते हैं?

2 अलग-अलग सामग्रियों से उत्पन्न हैश मानों को ध्यान में रखते हुए, टकराव की संभावना हमेशा 1 / 2^64 (अच्छी गुणवत्ता वाले 64-बिट हैश एल्गोरिदम के लिए, जैसे xxh64 या xxh3 ), जो भी हो उन 2 सामग्रियों के बीच संशोधनों की मात्रा।

इसका वास्तव में मतलब है कि, कम से कम सिद्धांत रूप में, एक बिट के परिवर्तन से टकराव उत्पन्न हो सकता है।

अब, ध्यान रखें कि यह प्रायिकता 1 / 2^64 , जो कि बहुत अधिक असीम है।
लोग इस विषय को समझने में अपेक्षाकृत खराब हैं। वे कभी-कभी इसे "छोटा" के साथ जोड़ते हैं, जिसे ज्यादातर लोगों के दिमाग में एक वास्तविक राशि के रूप में माना जाता है, जैसे ~ 10%।

अधिक सटीक विचार प्राप्त करने के लिए, मैं इस तालिका को देखना पसंद करता हूं:

यानी : 1 / 2 ^ 64 सीधे किसी के सिर पर धूमकेतु प्राप्त करने की संभावना से बहुत कम है, और राष्ट्रीय लॉटरी _3 बार लगातार जीतने की तुलना में कम है (जो कि संदिग्ध होगा)। यह वास्तव में "शून्य" के बहुत करीब है। सॉफ़्टवेयर बग के अन्य स्रोतों से शुरू करके, किसी भी सिस्टम के अधिकांश घटकों की तुलना में _much_ अधिक संभावना के साथ टूटने की संभावना होती है।

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

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

कुछ बिट्स बहुत अनुमानित या अत्यधिक सहसंबद्ध होते हैं, और जब उन्हें हैश उद्देश्य के लिए निकाला जाता है, तो फैलाव बहुत खराब होता है।

यह बुरा क्यों है?

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

यदि बिट्स किसी तरह सहसंबद्ध हैं तो क्या हम इस सहसंबंध का उपयोग क्षतिग्रस्त फ़ाइल को सुधारने के लिए कर सकते हैं?

यह बिल्कुल अलग विषय है।
एक सीआरसी के साथ क्षतिग्रस्त इनपुट की मरम्मत नहीं करता है। एक सीआरसी केवल एक त्रुटि का पता लगा सकता है, उसे सुधार नहीं सकता।

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

क्या आप इन परिदृश्यों की पुष्टि कर सकते हैं?

1. LZ4 में प्रत्येक डेटा ब्लॉक के लिए सामग्री चेकसम है, विचार करें कि हमारे पास 1 जीबी फ़ाइलों के 10 ^ 6 पैकेट हैं
   टक्कर की संभावना 1/2^32 = 0.0000000002 है इसका मतलब है कि अगर हम 10^10 (यह विशाल आकार) पैकेट भेजते हैं तो हमारे पास 2 टकराव हो सकते हैं (कबूतर सिद्धांत के आधार पर) लेकिन अगर हम इस राशि से कम भेजते हैं, तो संभावना है टक्कर देखने में काफी गिरावट आएगी ताकि हम सभी त्रुटियों का पता लगा सकें, डिकोडर चेकसम की गणना करता है और पैकेट चेकसम से इसकी तुलना करता है, क्या यह सही है?
2. सामग्री चेकसम संपीड़ित फ़ाइल पर चेकसम की गणना करता है (यह वैकल्पिक है और हम इसका उपयोग क्रम से बाहर का पता लगाने या टकराव की संभावना को कम करने के लिए कर सकते हैं (सीसी का उपयोग करने से पहले, टकराव की संभावना 1/2 ^ 32 है और फिर यह होगा 1/2 ^ 64 हो।)

वर्णित परिदृश्य है:

• LZ4-संपीड़ित डेटा दूषित हो रहा है (जो पहले से ही अपने आप में एक बहुत ही दुर्लभ घटना है)
• हैश टक्कर के कारण भ्रष्टाचार का पता नहीं चला।

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

पता नहीं चलने के लिए, एक भ्रष्टाचार को ___all___ लागू चेकसम सफलतापूर्वक पास करना होगा।
यह मानते हुए कि ब्लॉक चेकसम सक्षम है, और यह मानते हुए कि भ्रष्टाचार पूरी तरह से एक ही ब्लॉक में स्थित है, ब्लॉक और फ्रेम चेकसम दोनों को पास करने की संभावना वास्तव में 1 / 2^32 x 1 / 2^32 = 1 / 2^64 ।

अब, यदि दूषित डेटा कई ब्लॉकों में रहता है, या तो कई भ्रष्टाचार की घटनाओं के कारण, या क्योंकि एक बड़ा दूषित अनुभाग लगातार ब्लॉकों को कवर करता है, तो भ्रष्टाचार का पता न लगना _और भी कठिन है। इसमें शामिल प्रत्येक ब्लॉक चेकसम के साथ टकराव उत्पन्न करना होगा।
उदाहरण के लिए, यह मानते हुए कि भ्रष्टाचार 2 ब्लॉकों में फैला हुआ है, इस भ्रष्टाचार के अनिर्धारित रहने की संभावना 1 / 2^32 x 1 / 2^32 x 1 / 2^32 = 1 / 2^96 । खगोलीय रूप से छोटा।

इस तथ्य की गिनती नहीं करना कि प्रत्येक दूषित ब्लॉक को डीकंप्रेसन प्रक्रिया द्वारा अडिकोडेबल के रूप में पहचाना जा सकता है, जो उसके ऊपर आता है।

तो हाँ, ब्लॉक और फ्रेम चेकसम के संयोजन से भ्रष्टाचार की घटनाओं का पता लगाने की संभावना नाटकीय रूप से बढ़ जाती है।

वर्णित परिदृश्य है:

* LZ4-compressed data being corrupted (which is already a pretty rare event by itself)

* Corruption remaining undetected due to hash collision.

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

पता नहीं चलने के लिए, एक भ्रष्टाचार को _ सभी _ लागू चेकसमों को सफलतापूर्वक पास करना होगा।
यह मानते हुए कि ब्लॉक चेकसम सक्षम है, और यह मानते हुए कि भ्रष्टाचार पूरी तरह से एक ही ब्लॉक में स्थित है, ब्लॉक और फ्रेम चेकसम दोनों को पास करने की संभावना वास्तव में 1 / 2^32 x 1 / 2^32 = 1 / 2^64 ।

अब, यदि दूषित डेटा कई ब्लॉकों में रहता है, या तो कई भ्रष्टाचार की घटनाओं के कारण, या क्योंकि एक बड़ा दूषित अनुभाग लगातार ब्लॉकों को कवर करता है, तो भ्रष्टाचार का पता न लगना _और भी कठिन है। इसमें शामिल प्रत्येक ब्लॉक चेकसम के साथ टकराव उत्पन्न करना होगा।
उदाहरण के लिए, यह मानते हुए कि भ्रष्टाचार 2 ब्लॉकों में फैला हुआ है, इस भ्रष्टाचार के अनिर्धारित रहने की संभावना 1 / 2^32 x 1 / 2^32 x 1 / 2^32 = 1 / 2^96 । खगोलीय रूप से छोटा।

इस तथ्य की गिनती नहीं करना कि प्रत्येक दूषित ब्लॉक को डीकंप्रेसन प्रक्रिया द्वारा अडिकोडेबल के रूप में पहचाना जा सकता है, जो उसके ऊपर आता है।

तो हाँ, ब्लॉक और फ्रेम चेकसम के संयोजन से भ्रष्टाचार की घटनाओं का पता लगाने की संभावना नाटकीय रूप से बढ़ जाती है।

क्या मक्खी पर LZ4 का उपयोग करना संभव है? मेरा मतलब है, जैसे ही आपको इसमें से कुछ मिल जाए, डेटा को कंप्रेस/डिकंप्रेस करें। यह किसी तरह पाइपलाइनिंग है।
xxHash के बारे में क्या?

क्या मक्खी पर LZ4 का उपयोग करना संभव है? मेरा मतलब है, जैसे ही आपको इसमें से कुछ मिल जाए, डेटा को कंप्रेस/डिकंप्रेस करें।

यह स्ट्रीमिंग मोड है। जी हां संभव है।

xxHash के बारे में क्या?

फ़्रेम चेकसम लगातार अद्यतन किया जाता है, लेकिन केवल फ़्रेम के अंत में परिणाम उत्पन्न करता है। इसलिए, फ़्रेम ईवेंट के अंत तक तुलना करने के लिए कोई चेकसम परिणाम नहीं है (एक स्ट्रीम में कई संलग्न फ़्रेम शामिल हो सकते हैं, लेकिन आम तौर पर ऐसा नहीं होता है)।

इसके विपरीत, प्रत्येक ब्लॉक पर ब्लॉक चेकसम बनाए जाते हैं, इसलिए स्ट्रीमिंग के दौरान उन्हें नियमित रूप से उत्पादित और चेक किया जाता है।

दोनों चेकसम XXH32 कार्यरत हैं।