SHA-256 hash बनाएँ

पिछले पंद्रह साल में बनी लगभग हर चीज़ का डिफ़ॉल्ट hash SHA-256 है: TLS प्रमाणपत्र, पैकेजों के हस्ताक्षर, Bitcoin, ब्राउज़र के integrity token। इस पर कोई ज्ञात व्यावहारिक हमला नहीं है और सैद्धांतिक हमलों से दूरी बहुत बड़ी है।

यह चुनाव पसंद का नहीं, आपसी अनुकूलता का है। SHA-512 भले 64 बिट के हार्डवेयर पर तेज़ हो, पर SHA-256 वह मान है जिसकी उम्मीद बाक़ी सारे तंत्र करते हैं, और दूसरे पक्ष की उम्मीद से मेल खाना उस अंतर से ज़्यादा क़ीमती है जिस तक कोई पहुँचने वाला ही नहीं।

लंबा hash ज़्यादा सुरक्षा जैसा लगता है और SHA-2 के दायरे में वह ऐसा है नहीं। टकराव के सामने बिट में लंबाई का आधा गिना जाता है — SHA-256 में 128 —, और 2^128 कोशिशें उस दायरे से बाहर हैं जिसकी इजाज़त ज्ञात ब्रह्मांड की ऊर्जा और समय देते हैं।

इसलिए दोनों के बीच चुनाव व्यावहारिक है: SHA-512 64 बिट की मशीनों पर तेज़ चलता है, SHA-256 वह है जिसकी उम्मीद बाक़ी सब करते हैं। जब तक आप बहुत बड़ी मात्रा में डेटा hash नहीं कर रहे, सही कसौटी यही है कि आपको किससे बात मिलानी है।

यह गणना `crypto.subtle` से होती है, वह अमल जो ब्राउज़र में पहले से है और जिसकी जाँच और अनुकूलन दोनों हो चुके हैं — वही जो आपके खोले हर पन्ने के प्रमाणपत्र जाँचने में इस्तेमाल होता है। SHA-256 का अपना कोई रूप यहाँ लिखा नहीं गया है।

यह जान-बूझकर लिया गया फ़ैसला है। हाथ से लिखा hash सारे परीक्षण-सदिश पार करके भी किसी किनारे की हालत में ग़लत हो सकता है, और थोड़ा-सा ग़लत hash किसी hash के न होने से बुरा है, क्योंकि वह सही दिखता है। जहाँ ब्राउज़र मूल-क्रिया देता है, वहाँ ब्राउज़र वाली ही इस्तेमाल होती है।

SHA-256 256 बिट का है, जो 64 hexadecimal अंकों में लिखा जाता है। लंबाई हमेशा वही रहती है, इनपुट के आकार से बेपरवाह, क्योंकि hash तय आकार में सार निकालता है।

इससे मान को एक नज़र में पहचाना जा सकता है: 32 अक्षर MD5 हैं, 40 SHA-1 और 64 SHA-256। अगर SHA-256 का लेबल लगी किसी चीज़ की लंबाई कुछ और है तो लेबल ग़लत है — और विरासत में मिले दस्तावेज़ों में यह अक्सर होता है।

Unix का औज़ार फ़ाइल के आख़िर में पंक्ति-विच्छेद लिखता है; टेक्स्ट का खाना नहीं लिखता। एक शब्द वाली फ़ाइल का SHA-256 यहाँ लिखे उसी शब्द के SHA-256 से पूरी तरह अलग होता है — पूरी तरह, क्योंकि hash आंशिक अंक नहीं देता और एक अतिरिक्त बाइट नतीजे का हर अक्षर बदल देती है।

जो `sha256sum` से मिलान कर रहा है उसे encoding से पहले यही जाँचना चाहिए। दोनों कारण देखने में एक जैसे लगते हैं — दो मान जिनमें कुछ भी साझा नहीं — और दोनों एक मिनट में ख़ारिज हो जाते हैं, जबकि किसी काल्पनिक अमल-दोष की तलाश में पूरी शाम जाती है।

Hash बाइट पर निकलता है, और टेक्स्ट UTF-8 में बाइट बनता है। देवनागरी का एक अक्षर तीन बाइट है; ISCII में वह एक होता, और Kruti Dev जैसी फ़ॉन्ट-आधारित सामग्री में तो वह असल में कोई रोमन अक्षर होता। दो कार्यक्रम जो स्क्रीन पर एक ही टेक्स्ट दिखा रहे हैं, अलग-अलग बाइट-अनुक्रम hash कर रहे हो सकते हैं।

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

Hash का मान वही रहता है चाहे उसे छोटे अक्षरों में लिखें या बड़े में: `ff` और `FF` एक ही संख्या है। पर टेक्स्ट की तुलना के लिए यह सब कुछ बदल देता है, इसलिए यह सवाल उसी क्षण सजावटी नहीं रह जाता जब मान की तुलना की जाए, उसे किसी key की तरह इस्तेमाल किया जाए या उस पर दोबारा hash निकाला जाए।

परिपाटियाँ एक जैसी नहीं हैं: Unix के औज़ार और ज़्यादातर लाइब्रेरियाँ छोटे अक्षरों में लिखती हैं, Windows के औज़ार और प्रमाणपत्र दिखाने वाली बहुत सी खिड़कियाँ बड़े अक्षरों में। इसीलिए यह विकल्प यहाँ है: नतीजा उसी रूप में निकालिए जिसमें दूसरा पक्ष उसे लिखता है, ताकि तुलना उसी क़दम पर हो जाए।

Hash यह कहता है कि दो सामग्रियाँ एक जैसी हैं। यह नहीं कहता कि उन्हें किसने बनाया, और न ही किसी को इससे रोकता है कि वह सामग्री के साथ-साथ बग़ल में छपा hash भी बदल दे। उसके लिए हस्ताक्षर चाहिए, जो एक ऐसी कुंजी जोड़ता है जो सिर्फ़ भेजने वाले के पास हो।

इसीलिए फ़ाइल वाले पन्ने पर ही छपा checksum किसी ख़राब mirror से बचाता है, पर उससे नहीं जो पन्ना ही नियंत्रित करता हो। जब integrity के अलावा उद्गम भी मायने रखता हो तो जवाब हस्ताक्षर है — कुंजी साझा हो तो HMAC, न हो तो असममित हस्ताक्षर।

फ़ाइलों के लिए इस साइट पर checksum वाला पन्ना है, जिसमें खींचकर छोड़ने का खाना है, और वह दूसरे सवाल का जवाब देता है: कोई डाउनलोड सही-सलामत पहुँची या नहीं। यह पन्ना बताता है कि किसी मान का hash क्या है — डेटाबेस का कोई फ़ील्ड, हस्ताक्षर से पहले का कोई payload, कोई पहचान जो हमेशा एक जैसी निकलनी चाहिए।

दोनों को एक ही पन्ने पर रखने से हर आने वाले के लिए आधा इंटरफ़ेस फ़ालतू हो जाता। Algorithm एक ही है और वह उसी अंतर्निहित क्रिप्टोग्राफ़ी से आता है; बदलता सिर्फ़ सवाल है, और इसीलिए पन्ने बदलते हैं।

SHA-3 को 2015 में मानक बनाया गया और वह SHA-2 का उत्तराधिकारी नहीं है। वह एक खुली प्रतियोगिता से इसलिए निकला था कि अगर SHA-2 के परिवार में कभी कोई ढाँचागत दरार मिले तो एक ऐसा विकल्प तैयार रहे जो भीतर से बिलकुल अलग बना हो — और वह दरार आज तक नहीं मिली।

इसीलिए उसका फैलाव धीमा है और यह कोई चूक नहीं है। जब तक SHA-256 पर कोई व्यावहारिक हमला नहीं है, बदलने का ख़र्च ही उठाने लायक़ नहीं। जिसे आज चुनना है उसके लिए सही जवाब SHA-256 है; SHA-3 वह बीमा है जिसका दावा अब तक करना नहीं पड़ा।

इस खाने में एक अक्षर जोड़िए और चौंसठों अक्षर बदल जाते हैं, न कि आख़िर वाले कुछ। यह hash का बुनियादी गुण है: इनपुट का एक बिट बदलने पर नतीजे का हर बिट आधी संभावना से पलट जाता है, और यही उसे किसी checksum से अलग करता है।

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

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

जो हिस्सा यह पन्ना हल करता है वह यह है कि गणना आपके डिवाइस पर होती है, इसलिए न मूल मान हम तक पहुँचता है न hash। यही इसे असली डेटा के साथ इस्तेमाल लायक़ बनाता है; जो नहीं बदलता वह यह है कि नतीजा किस स्वभाव का है।