CRC-32 कैलकुलेटर - टेक्स्ट, हेक्स और फ़ाइल की चेकसम
CRC-32 चेकसम कैलकुलेटर
हैश करने से पहले UTF-8 के रूप में एन्कोड किया जाता है। 6 बाइट
| संदेश की लंबाई | 6 बाइट |
| CRC-32 | 0xFF55531A |
| CRC-32b (अंत में जोड़ा गया शून्य बाइट) | 0x2F9F43A4 |
CRC-32 ज़िप आर्काइव, gzip स्ट्रीम, PNG चंक और इथरनेट फ़्रेम में हो जाने वाली आकस्मिक क्षति पकड़ लेता है। यह क्रिप्टोग्राफ़िक हैश नहीं है: यह रैखिक है, आसानी से नकली बनाया जा सकता है, और किसी विरोधी के सामने अखंडता की जाँच के लिए इसका उपयोग कभी नहीं करना चाहिए।
क्या है
चेकसम किसी लंबे संदेश का एक छोटा, निश्चित लंबाई वाला सार है, जिसे इस तरह निकाला जाता है कि संदेश में हुआ कोई भी अनजाने में हुआ बदलाव उस सार को बदलने की बहुत प्रबल संभावना रखे। यह विचार व्यक्तिगत कंप्यूटर से भी पुराना है। IBM ने पंच कार्ड पढ़ने वाली टैब्युलेटिंग मशीनें बनाईं और संचालकों ने देखा कि मशीनों के बीच जाने वाला डेटा कभी-कभी चुपचाप बिगड़ जाता था: कोई कॉलम गलत पंच होना, कोई कार्ड मुड़ा होना, कोई पुराना रीडर। तकनीकी समाधान यह हुआ कि डेटा के साथ एक अतिरिक्त अंकगणितीय मान भी भेजा गया, जिसे प्राप्त करने वाली मशीन फिर निकालकर मिलाती थी; मेल खाता तो हस्तांतरण ठीक माना जाता, न खाता तो दोबारा भेजने को कहा जाता। इसी विचार की आधुनिक वंशज हैं साइक्लिक रिडंडेंसी चेक। CRC संदेश को GF(2) क्षेत्र पर बहुपद मानता है, जहाँ जोड़ना और घटाना दोनों एक्सक्लूसिव ऑर होते हैं, और उसे एक निश्चित जनक बहुपद से भाग देकर शेष निकालता है। CRC-32 में जनक बहुपद 0x04C11DB7 है, और चूँकि बिट-उलटी हुई रूपांतरण पारंपरिक रूप से सस्ता पड़ता है, वास्तविक कोड उलटी स्थिरांत 0xEDB88320 के साथ काम करता है। सामान्य क्रियान्वयन पहले 256 प्रविष्टियों की एक तालिका बनाता है और फिर हर बाइट को एक तालिका-खोज और एक शिफ्ट के साथ संसाधित करता है: crc = तालिका[(crc या बाइट) और 0xFF] या (crc >> 8)। इसी तालिका की वजह से एक मेगाबाइट दो-तीन मिलीसेकंड में जाँच लिया जाता है, और इसे किसी जादुई सरणी की चिपकाकर नहीं बल्कि परिभाषा से बनाना यह गारंटी करता है कि कोड वही लागू कर रहा है जिसका दावा करता है। पहले बाइट से पहले रजिस्टर को 0xFFFFFFFF से शुरू किया जाता है और निकलते समय परिणाम को 0xFFFFFFFF के साथ एक्सक्लूसिव ऑर किया जाता है, जिसे ऑग्मेंटेशन कहते हैं। इन दोनों में से कोई भी सजावट नहीं है। बीज शून्य होने पर आरंभिक शून्य बाइट्स रजिस्टर को बदलते नहीं, इसलिए संदेश 00 00 41 और संदेश 41 एक जैसा मान देते हैं; सब-एक से आरंभ करना इन बाइट्स को अवशोषित करने पर बाध्य करता है, और यही कारण है कि लगातार शून्य भी पकड़े में आते हैं। अंतिम एक्सक्लूसिव ऑर यह प्रतिबंधित करता है कि संदेश अपनी ही चेकसम लिए-एंडियन में जोड़ने पर एक निश्चित अवशेष 0x2144DF1C छोड़ता है, जिसे प्राप्तकर्ता जाँचता है, और इसीलिए खाली संदेश की चेकसम साफ़-सुथरी 0x00000000 होती है, किसी एक के झुंड के बजाय। CRC-32 और CRC-32b एक ही एल्गोरिदम के अलग-अलग फ़्रेमिंग हैं: यहाँ दिखाई गई किस्म आपके बाइट्स के अंत में एक 0x00 बाइट जोड़कर चलाती है, जो कुछ प्रोटोकॉल की पेलोड को उसके टर्मिनेटर से अलग करने की परंपरा है, जबकि अन्य स्रोत इसी नाम से BZIP2 किस्म बताते हैं जो चार शून्य बाइट जोड़ती है; इसलिए हमेशा बताएँ कि कौन-सी फ़्रेमिंग की बात हो रही है। वास्तव में CRC-32 हर ZIP प्रविष्टि की अखंडता का क्षेत्र है, हर gzip और zlib स्ट्रीम के अंत में, PNG फ़ाइल के हर एक खंड में, MPEG-2 परिवहन स्ट्रीम में, और हर एथरनेट फ़्रेम की फ़्रेम चेक सीक्वेंस में, जहाँ इसे FCS कहते हैं। लेकिन CRC-32 क्रिप्टोग्राफ़िक हैश बिलकुल नहीं है। यह GF(2) पर रैखिक फलन है: दो समान लंबाई के संदेशों में एक ही अंतर एक्सक्लूसिव ऑर करने पर उनकी चेकसम में भी वही अंतर आता है, यानी जो कोई एक संदेश और उसकी चेकसम जानता है, वह चार बाइट का ऐसा सुधार बना सकता है जिससे चेकसम उसकी मनचाही हो। यह केवल 32 बिट चौड़ा भी है, इसलिए जन्मदिन परिणाम के अनुसार लगभग 2^32 के वर्गमूल, यानी करीब 65536 संदेशों के आसपास, दो भिन्न संदेश एक ही चेकसम साझा करने लगते हैं, जबकि कोई भी एक-बिट अनजाने का भ्रामक गड़बड़ निश्चित रूप से पकड़ा जाता है। संयोगिक क्षति के लिए इसका उपयोग करें, किसी विरोधी के विरुद्ध अखंडता के लिए कभी नहीं।
कैसे उपयोग करें
- अपने ब्राउज़र में CRC-32 कैलकुलेटर खोलें। चेकसम स्थानीय रूप से जावास्क्रिप्ट से बनती है, इसलिए आपके लिखे या चुने गए किसी भी चीज़ को किसी सर्वर पर नहीं भेजा जाता।
- ऊपर दिए तीन बटन से इनपुट मोड चुनें: टेक्स्ट के लिए Text, कच्चे बाइनरी के लिए Hex bytes, और पूरी फ़ाइल के लिए File।
- Text मोड में, Input text बॉक्स में लिखें या चिपकाएँ। स्ट्रिंग को पहले UTF-8 में एनकोड किया जाता है, इसलिए मात्रा अक्षरों और इमोजी स्पष्ट दिखने से कहीं ज़्यादा बाइट्स लेते हैं, और नीचे बाइट संख्या लगातार बदलती रहती है।
- Hex मोड में, 48 65 6c 6c 6f जैसे हेक्साडेसिमल अंकों के जोड़े चिपकाएँ। रिक्त स्थान, अल्प विराम और 0x उपसर्ग अपने आप हट जाते हैं, अंकों की विषम संख्या अस्वीकार कर दी जाती है, और कोई भी गैर-हेक्स वर्ण चुपचाप अनदेखा करने के बजाय त्रुटि देता है।
- File मोड में, Choose a file नियंत्रण से कोई फ़ाइल चुनें। कैलकुलेटर उसे ब्राउज़र की फ़ाइल API से पढ़ता है और डिस्क पर उसके आकार के साथ-साथ वास्तव में हैश किए गए बाइट्स की संख्या भी दिखाता है।
- Output format मेन्यू से ज़रूरी रूप चुनें: Hex, Decimal, Octal, Binary या Base64। CRC-32 result बॉक्स तुरंत उसी रूप में फिर से बन जाता है।
- सारांश तालिका से संदेश की सही बाइट लंबाई, CRC-32 मान, और तुलना के लिए एक अंतिम शून्य बाइट के साथ बना CRC-32b मान पढ़ें।
- यह पुष्टि करने के लिए कि डाउनलोड, अपलोड या भेजा गया डेटा सुरक्षित पहुँचा, मान को प्रकाशित चेकसम से मिलाएँ।
उदाहरण
इनपुट: Text मोड, स्ट्रिंग CRC-32
प्रक्रिया:
6 UTF-8 बाइट्स 43 52 43 2D 33 32 तालिका-आधारित लूप से गुज़रेपरिणाम: CRC-32 = 0xFF55531A, और अंत में शून्य बाइट वाला CRC-32b = 0x2F9F43A4
इनपुट: Text मोड, स्ट्रिंग 123456789
प्रक्रिया:
CRC-32/BZIP2 किस्म के लिए ISO 3309 और ITU-T V.42 का मानक परीक्षण मानपरिणाम: 0xCBF43926 — यदि आपका क्रियान्वयन अलग बताए, तो उसके मानक गलत हैं
इनपुट: Hex मोड, बाइट्स 48 65 6c 6c 6f
प्रक्रिया:
Hello के अर्थ वाले पाँच कच्चे बाइट्स, टेक्स्ट के बजाय हेक्स रूप में दाएँ गएपरिणाम: 0xF7D18982 — Hello शब्द को टेक्स्ट मानकर हैश करने से अलग
इनपुट: File मोड, खाली या शून्य आकार की फ़ाइल
प्रक्रिया:
लूप एक बार भी नहीं चलता, इसलिए बीज सीधे अंतिम एक्सक्लूसिव ऑर से गुज़रता हैपरिणाम: 0x00000000, इसीलिए खाला संदेश आसानी से पहचान लिया जाता है
संबंधित खोजें
लोग यह भी खोजते हैं: crc32 कैलकुलेटर, crc32 चेकसम, चेकसम कैलकुलेटर, crc32 ऑनलाइन, फ़ाइल चेकसम, crc32 हेक्साडेसिमल।
crc32 कैलकुलेटरcrc32 चेकसमचेकसम कैलकुलेटरcrc32 ऑनलाइनफ़ाइल चेकसमcrc32 हेक्साडेसिमलcrc32 टेक्स्टcrc32biso 3309 मानकitu-t v.420xedb88320फ़ाइल अखंडता जाँचzip crc जाँचgzip चेकसमpng crcethernet fcscrc32 बेस 64crc32 और sha256 अंतरक्षति पहचाननामुफ़्त ऑनलाइन उपकरण
अक्सर पूछे जाने वाले प्रश्न
CRC-32 का असली सॉफ़्टवेयर में उपयोग कहाँ होता है?
हर उस जगह CRC-32 का उपयोग होता है जहाँ दुर्घटनावश हुई क्षति के विरुद्ध सस्ता और लगभग निश्चित जाँच, सुरक्षा की गारंटी से ज़्यादा कीमती हो। हर ZIP संग्रह अपनी प्रत्येक प्रविष्टि के लिए केंद्रीय निर्देशिका में एक चेकसम रखता है, और unzip उसे खोलते समय जाँचता है, इसलिए कटी या बिट बदली फ़ाइल का पता चलता है, बजाय इसके कि चुपचाप बेतहाशा बकवास छूटे। gzip और zlib अपने संपीड़ित स्ट्रीम के अंत में CRC-32 जोड़ते हैं, इसीलिए क्षतिग्रस्त .gz फ़ाइल एक अस्पष्ट डिकम्प्रेशन त्रुटि के बजाय चेकसम त्रुटि देती है। PNG हर एक खंड में CRC-32 रखता है, ताकि हर खंड अलग से जाँचा जा सके और डिकोडर पहले बुरे खंड पर रुक सके। MPEG-2 परिवहन स्ट्रीम प्रति पैकेट एक रखते हैं, और एथरनेट फ़्रेम की चेक सीक्वेंस भी CRC-32 ही है, जो आमतौर पर नेटवर्क कार्ड के हार्डवेयर में हर फ़्रेम पर निकाली जाती है। इन सभी में खतरा एक ही होता है: शोर, पुरानापन, अधूरी लेखन और मेल न खाते संस्करण, कोई सोचा-समझा दुर्षेक्षी नहीं।
क्या CRC-32 क्रिप्टोग्राफ़िक हैश है? क्या इससे पासवर्ड रख सकते हैं?
नहीं, और इसका उपयोग पासवर्ड के लिए या किसी अविश्वसनीय स्रोत से आई डाउनलोड की अखंडता जाँचने के लिए करना गंभीर गलती होगी। CRC GF(2) क्षेत्र पर रैखिक फलन है, यानी दो संदेशों में एक ही अंतर एक्सक्लूसिव ऑर करने पर उनकी चेकसम में भी वही अंतर आता है। इसलिए जो कोई एक संदेश और उसकी चेकसम जानता है, वह ऐसा दूसरा संदेश बना सकता है जो मात्र चार बाइट्स में भिन्न हो और जिसकी चेकसम वह चाहे। यह ऐसी नकल है जिसके लिए न किसी चतुराई की, न किसी खोज की ज़रूरत पड़ती है। केवल 32 बिट चौड़ाई के कारण आक्रामक जीपीयू पर कुछ ही सेकंड में टकराव पहले से तैयार कर सकता है। इसमें न कुंजी है, न नमक, न लागत कारक, न अवलोपन व्यवहार, इसलिए यह एकतरफ़ता, अन-अनुमेयता और ब्रूट-फ़ोर्स प्रतिरोध का कोई भी गुण नहीं देता, जिस पर पासवर्ड भंडारण और कोड हस्ताक्षर निर्भर हैं। किसी विरोधी के विरुद्ध अखंडता के लिए SHA-256 जैसा क्रिप्टोग्राफ़िक हैश लें, और किसी भी ऐसी चीज़ के लिए जो पहचान-सा दिखे, Argon2id या bcrypt जैसी समर्पित फलन लें।
CRC-32b का परिणाम CRC-32 से अलग क्यों है?
क्योंकि दोनों नाम उसी एल्गोरिदम को थोड़ा-थोड़ा अलग फ़्रेमिंग में बताते हैं। इस कैलकुलेटर की CRC-32b पंक्ति आपके बाइट्स के अंत में एक 0x00 बाइट जोड़कर ठीक वही एल्गोरिदम चलाती है, और वह अतिरिक्त बाइट रजिस्टर की स्थिति बदल देता है, इसलिए सारे मान खिसक जाते हैं। ऐसी किस्म का उद्देश्य पेलोड को उसके अपने टर्मिनेटर से अलग पहचानना है, ताकि कोई स्ट्रीम जो वैध रूप से शून्य बाइट पर समाप्त हो, उस भ्रम न हो जाए जो संयोग से वहीं समाप्त हो। जान लें कि यह शब्द भ्रमपूर्ण ढंग से प्रयोग होता है: BZIP2 किस्म, जिसे सामान्यतः CRC-32/BZIP2 लिखा जाता है और जिसकी पहचान स्ट्रिंग 123456789 के मान 0xCBF43926 से होती है, एक नहीं बल्कि चार शून्य बाइट जोड़ती है और पूरी तरह दूसरी फलन है। किसी विशेष टूल या फ़ॉर्मैट से जुड़कर काम करते समय जाँच लें कि उसका क्रियान्वयन सचमुच कितने शून्य बाइट जोड़ता है, नाम पर भरोसा किए बिना।
0xEDB88320 स्थिरांत का क्या अर्थ है?
यह CRC-32 जनक बहुपद 0x04C11DB7 का उलटा रूप है, और आपको मिलने वाली लगभग हर सॉफ़्टवेयर क्रियान्वयन में दिखता है। जनक बहुपद तय करता है कि कौन-से बिट प्रतिरूप त्रुटि माने जाएँ। इसका सामान्य रूप, बिट्स सीधे क्रम में, पाठ्यपुस्तकों वाला रूप है, लेकिन उलटा क्रम पूरी गणना बाइट्स में दाएँ से बाएँ चलाने की अनुमति देता है, जिसके लिए प्रति बाइट केवल एक तालिका-खोज और एक शिफ्ट चाहिए, न कि आठ सशर्त शिफ्ट। उलटे क्रियान्वयन में 0x04C11DB7 का मान 0xEDB88320 में बदल जाता है, और तालिका के 256 प्रविष्टियों में से हर एक बाइट मान से शुरू करके वही उलटी लूप आठ बार चलाकर बनती है: यदि सबसे निचला बिट एक है, तो 0xEDB88320 से एक्सक्लूसिव ऑर करके दाएँ खिसकाएँ, अन्यथा केवल दाएँ खिसकाएँ। तालिका को उसी परिभाषा से बनाना, जैसा यह उपकरण करता है, 256 प्रविष्टियों वाला सरणी चिपकाने से सुरक्षित है, क्योंकि इससे वह जोखिम समाप्त हो जाता है कि दी गई तालिका उस परिभाषा से बिगड़ जाए जिसका दावा वह करती है।
दो अलग-अलग फ़ाइलों को कभी-कभी एक ही CRC-32 क्यों मिलता है?
क्योंकि आउटपुट स्थान केवल 32 बिट चौड़ा है, यानी लगभग 43 करोड़ संभावित चेकसम हैं जो सभी संभव संदेशों में बाँटने हैं, इसलिए कुछ संदेशों का साझा होना अनिवार्य है। जन्मदिन परिणाम से अनुमान लगाने पर, टकराव की संभावना बनने वाले संदेशों की संख्या लगभग 2^32 का वर्गमूल होती है, यानी लगभग 65536, इसलिए यादृच्छिक डेटा उसी पड़ाव पर दोहरी चेकसम पा लेता है। वास्तविक फ़ाइलें यादृच्छिक डेटा से भी बुरी होती हैं, क्योंकि संरचित दस्तावेज़ आमतौर पर केवल कुछ पूर्वानुमेय जगहों पर अलग होते हैं। यह डिज़ाइन की कमी नहीं, बल्कि डिज़ाइन का ठीक से काम करना है। CRC-32 हर एक-बिट त्रुटि और 32 बिट तक के उछल-कूद त्रुटि को निश्चित रूप से पकड़ लेता है, जो शोर, पुरानापन और स्थानांतरण-विफलता से होने वाली लगभग सारी अनजाने की क्षति को कवर करता है। यह विरोधी के सामने पहचान सिद्ध नहीं कर सकता, क्योंकि विरोधी कुछ ही सेकंड में जानबूझकर टकराव बना सकता है। यदि आपको टकराव-प्रतिरोध चाहिए, तो आपको क्रिप्टोग्राफ़िक हैश चाहिए।
डाउनलोड की गई फ़ाइल क्षतिग्रस्त तो नहीं है, यह कैसे जाँचें?
यहाँ फ़ाइल का CRC-32 निकालकर उसकी तुलना उस चेकसम से करें जो प्रकाशक या स्थानांतरण प्रणाली ने दर्ज की है। मेल खाने पर फ़ाइल बिना क्षति के पहुँची है। कई उपकरण यह पहले ही कर देते हैं, क्योंकि unzip हर प्रविष्टि जाँचता है, gzip और zlib स्ट्रीम के अंत की जाँच करते हैं, और ब्राउज़र PNG के खंडों को डीकोड करते समय जाँचते हैं; फिर भी स्वयं निकालना यह पुष्टि करने का सबसे तेज़ तरीका है कि किसी विशेष उपकरण ने वास्तव में क्या निकाला, और अकेले यही तरीका है जब आपके पास ऐसा असामान्य फ़ॉर्मैट हो जिसमें अंतर्निहित जाँच नहीं है। File मोड चुनें, डाउनलोड चुनें, और CRC-32 of file का परिणाम पढ़ें। एक महत्वपूर्ण सीमा: मेल खाना तभी सिद्ध करता है कि फ़ाइल प्रकाशक की ही है, यदि आप प्रकाशक पर भरोसा करते हैं। यदि डाउनलोड में बदलाव संभव था, तो उस क्षमता वाला आक्रामक उसी चेकसम वाली दूसरी फ़ाइल बना सकता है, और यही कारण है कि GPG या Sigstore हस्ताक्षरित प्रकाशन चेकसम के साथ-साथ मौजूद होते हैं।
क्या मेरी फ़ाइल या टेक्स्ट किसी सर्वर पर अपलोड होती है?
नहीं। यह कैलकुलेटर एक क्लाइंट-साइड घटक है: आपके ब्राउज़र का जावास्क्रिप्ट आपका टेक्स्ट, आपके हेक्स बाइट्स या आपके द्वारा चुनी गई फ़ाइल पढ़ता है, मेमोरी में CRC-32 तालिका बनाता है, और लूप स्थानीय रूप से चलाता है। नेटवर्क पर कुछ नहीं भेजा जाता, किसी सर्वर लॉग में कुछ नहीं लिखा जाता, और टैब बंद करने के बाद कुछ भी नहीं बचता। फ़ाइल मोड के लिए यह ब्राउज़र की फ़ाइल API से लागू किया गया है, जो स्थानीय डिस्क से फ़ाइल को आवश्यकता होने पर मेमोरी में पढ़ती है। इसका व्यावहारिक लाभ केवल निजता का नहीं है: आप कई गीगाबाइट वाली डिस्क छवि या नियमित अनुबंध के तहत संवेदनशील संग्रह की जाँच बिना अपलोड की प्रतीक्षा किए और बिना अपना आँकड़ों की नकल किसी तीसरे पक्ष को सौंपे कर सकते हैं।