SHA हैश जनरेटर गाइड: UTF-8, SHA-384 और SHA-512

टेक्स्ट हैश कैसे बनाएँ

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

परिणाम के साथ चुना एल्गोरिदम देखें, फिर परिणाम कॉपी करें या डाउनलोड करें लें। खाली इनपुट स्वीकार है और वास्तविक गैर-खाली डाइजेस्ट देता है। पंक्तियाँ लपेटें केवल दृश्य बदलता है। दूसरे ऐप से तुलना से पहले दोनों ओर समान बाइट क्रम, एल्गोरिदम और तुलना योग्य आउटपुट अभिव्यक्ति सुनिश्चित करें।

• आखिरी स्पेस और पंक्ति अंत जानबूझकर रखें; केवल तुलना मिलाने के लिए न हटाएँ।
• असली डेटा की जाँच से पहले abc जैसे निश्चित उदाहरण से एल्गोरिदम देखें।
• मूल डेटा और भरोसेमंद अपेक्षित डाइजेस्ट स्क्रीनशॉट या छोटे दिखते मान से अलग रखें।

SHA-256, SHA-384 और SHA-512 की आउटपुट लंबाई

ये SHA-2 परिवार के तीन सदस्य हैं। इनपुट खाली, छोटा शब्द या लंबा अनुमत टेक्स्ट हो, डाइजेस्ट लंबाई निश्चित है। हेक्साडेसिमल अक्षर चार बिट दर्शाता है, इसलिए 256-बिट डाइजेस्ट में 64 हेक्साडेसिमल अक्षर हैं। शुरुआती शून्य बाइट्स भी दर्शाए जाते हैं; आउटपुट छोटा नहीं होता। वर्कस्पेस का बाइट बैज UTF-8 हेक्स टेक्स्ट गिनता है: 64, 96 या 128 बाइट्स, नीचे के मूल डाइजेस्ट बाइट्स नहीं।

प्राप्त फ़ॉर्मेट या तुलना को चाहिए वही एल्गोरिदम चुनें। SHA-384 के अपने शुरुआती मान हैं; यह साधारण SHA-512 डाइजेस्ट का केवल शुरुआती भाग नहीं। अतिरिक्त अक्षरों को वैकल्पिक मानकर SHA-512 और SHA-256 सीधे नहीं तुलना सकते। लंबा आउटपुट अपने आप पासवर्ड संग्रह योजना या पूरे ऐप की सुरक्षा नहीं बनाता। यहाँ SHA-1, MD5, SHA-3, HMAC या साल्ट/कुंजी सेटिंग नहीं है।

NIST FIPS 180-4: सुरक्षित हैश मानकW3C Web Cryptography API: डाइजेस्ट और SHA एल्गोरिदम

ज्ञात SHA-256 उदाहरण: खाली टेक्स्ट और abc

तालिका दिए गए सही UTF-8 इनपुट के पूरे छोटे अक्षरों वाले SHA-256 डाइजेस्ट देती है। खाली स्ट्रिंग के शून्य इनपुट बाइट्स हैं; यह स्पेस या नई पंक्ति का डाइजेस्ट नहीं। abc के तीन ASCII बाइट हेक्स में 61 62 63 हैं। ये निश्चित परीक्षण उदाहरण हैं, आपके इनपुट की माप नहीं।

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

NIST FIPS 180-4: सुरक्षित हैश मानकWHATWG Encoding: UTF-8 और टेक्स्ट डिकोडिंग

UTF-8 बाइट्स, स्पेस और Unicode सामान्यीकरण

हैशिंग से पहले टूल बिना जोड़े वाले Unicode सरोगेट जाँचकर स्ट्रिंग UTF-8 में बदलता है। स्पेस छाँटता नहीं, दी स्ट्रिंग का प्रारंभिक U+FEFF हटाता नहीं और Unicode सामान्यीकरण नहीं करता। अंत का स्पेस, अक्षरों का केस या बाइट अभिव्यक्ति बदलने से डाइजेस्ट बदल सकता है। वर्कर को दी गई स्ट्रिंग हैश होती है।

दो स्ट्रिंग दिखने में एक जैसी पर बाइट्स अलग हो सकती हैं। पूर्व-संयोजित U+00E9 और क्रम U+0065 U+0301 एक ही उच्चारण-चिह्न वाला अक्षर दिखा सकते हैं, पर UTF-8 एन्कोडिंग अलग है। इसी तरह LF और CRLF अलग बाइट क्रम हैं। ब्राउज़र संपादन या आयात दी स्ट्रिंग बदल सकता है, इसलिए केवल दिखावट से बाइट समानता न मानें।

WHATWG Encoding: UTF-8 और टेक्स्ट डिकोडिंगECMAScript: String isWellFormedWHATWG HTML: टेक्स्ट एरिया मान और पंक्ति अंत

टेक्स्ट फ़ाइल खोलना मूल फ़ाइल बाइट्स हैश करना नहीं

फ़ाइल नियंत्रण File.text() से UTF-8 पढ़ता है, शुरुआती UTF-8 BOM हटाता और खराब UTF-8 क्रम बदलता है। फ़ाइल 4,000,000 बाइट्स से छोटी हो और पढ़ा टेक्स्ट दस लाख UTF-16 इकाइयों की सीमा में हो। फ़ाइल एक्सटेंशन अक्षर एन्कोडिंग साबित नहीं करता।

डिकोड स्ट्रिंग फिर UTF-8 में एन्कोड होकर डाइजेस्ट बनती है, इसलिए मूल फ़ाइल बाइट्स पर सीधे निकले चेकसम से परिणाम अलग हो सकता है। बाइनरी दस्तावेज़, चित्र, BOM, दूसरी अक्षर एन्कोडिंग या बदले अक्षर असर डाल सकते हैं। सही बाइट वाली फ़ाइल जाँच के लिए अपेक्षित एल्गोरिदम से मूल बाइट पढ़कर हैश करें; यह वर्कस्पेस वह फ़ाइल-चेकसम विधि नहीं है।

W3C File API: Blob टेक्स्ट पढ़नाWHATWG Encoding: UTF-8 और टेक्स्ट डिकोडिंग

मिलता या अलग हैश क्या बताता है

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

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

NIST FIPS 180-4: सुरक्षित हैश मानकW3C Web Cryptography API: डाइजेस्ट और SHA एल्गोरिदम

हैश डिक्रिप्ट नहीं होता, लेकिन अनुमान जाँचे जा सकते हैं

हैशिंग डाइजेस्ट बनाती है, डिक्रिप्शन कुंजी वाला सिफ़रटेक्स्ट नहीं। ToolMellow में डिक्रिप्ट या मूल टेक्स्ट वापस लाने का फ़ंक्शन नहीं। एन्क्रिप्शन, Base64 और हैशिंग की अलग भूमिकाएँ हैं: Base64 बाइट्स को वापस बदली जाने वाली अभिव्यक्ति देता है; एन्क्रिप्शन के लिए क्रिप्टोग्राफिक योजना और कुंजियाँ चाहिए। डाइजेस्ट ऐसा संकुचित रूप नहीं जिससे कोई भी मूल इनपुट फिर बनाया जाए।

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

NIST FIPS 180-4: सुरक्षित हैश मानकOWASP: पासवर्ड संग्रह चीट शीट

सादा SHA-256 पासवर्ड संग्रह प्रणाली क्यों नहीं

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

पासवर्ड संग्रह के लिए उसी उद्देश्य की संरचना और उचित ऐप नियंत्रण चाहिए। अपने सिस्टम के लिए वर्तमान पासवर्ड संग्रह दिशानिर्देश लें। HMAC और डिजिटल हस्ताक्षर अलग संरचनाओं से कुंजी वाला प्रमाणीकरण करते हैं; ToolMellow टेक्स्ट डाइजेस्ट न उन्हें बनाता, न सत्यापित करता है। वास्तविक क्रेडेंशियल सार्वजनिक उदाहरणों या स्क्रीनशॉट में न रखें।

OWASP: पासवर्ड संग्रह चीट शीटW3C Web Cryptography API: डाइजेस्ट और SHA एल्गोरिदम

परिणाम को इनपुट बनाएँ हेक्स टेक्स्ट हैश करता है

डाइजेस्ट बनने के बाद परिणाम को इनपुट बनाएँ उसके हेक्साडेसिमल अक्षर एडिटर में रखता है। अगली बार इस टेक्स्ट के UTF-8 बाइट्स हैश होते हैं। यह अपने आप मूल 32, 48 या 64 डाइजेस्ट बाइट अगले हैश को नहीं देता; इस इंटरफ़ेस में मूल-बाइट इनपुट मोड नहीं।

प्रोटोकॉल को मूल डाइजेस्ट बाइट का दूसरा हैश चाहिए तो दृश्य हेक्स परिणाम पर टेक्स्ट ऑपरेशन अलग गणना है। “दो बार हैश” को एक सार्वभौमिक काम न मानें; हर चरण की आवश्यक अभिव्यक्ति पहचानें। यहाँ बिना-कुंजी डाइजेस्ट दोहराने से पासवर्ड संग्रह या कुंजी वाला प्रमाणीकरण नहीं बनता।

WHATWG Encoding: UTF-8 और टेक्स्ट डिकोडिंगW3C Web Cryptography API: डाइजेस्ट और SHA एल्गोरिदम

इनपुट सीमा, Web Crypto और HTTPS

इनपुट सीमा 1,000,000 JavaScript UTF-16 कोड इकाइयाँ है, दस लाख UTF-8 बाइट्स या दिखते ग्रैफीम नहीं। इमोजी और संयुक्त क्रम इन गिनतियों के अंतर बताते हैं। SHA-2 डाइजेस्ट का हेक्स आउटपुट निश्चित लंबाई का है, इसलिए वैध परिणाम वापस लेने के लिए इनपुट सीमा में आता है; ब्राउज़र मेमोरी और वर्कर उपलब्धता फिर भी ज़रूरी हैं।

ब्राउज़र को उचित सुरक्षित संदर्भ, जैसे HTTPS या localhost सहित भरोसेमंद स्थानीय संदर्भ में crypto.subtle देना चाहिए। API न मिले तो समर्थन त्रुटि दिखाई जाती है। केवल HTTPS हर ब्राउज़र या एम्बेड परिवेश में API समर्थन की गारंटी नहीं। मानकीकृत एल्गोरिदम से यह प्रमाण नहीं मिलता कि ब्राउज़र, वेबसाइट या कार्यान्वयन को FIPS सत्यापन या प्रमाणन मिला है।

ECMAScript: String isWellFormedW3C Web Cryptography API: डाइजेस्ट और SHA एल्गोरिदमW3C Secure Contexts: संभावित भरोसेमंद ओरिजिन

असफल या अप्रत्याशित टेक्स्ट हैश की जाँच

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

तुलना असफल हो तो ज्ञात abc वेक्टर से शुरू कर वास्तविक इनपुट की शर्तें एक-एक करके तुलना करें। टूल नुकसान पहचानता, सत्यापन प्रमाणपत्र देता या URL से संदर्भ चेकसम फ़ेच नहीं करता। क्लिपबोर्ड न मिले तो डाइजेस्ट चुनकर खुद कॉपी करें।

W3C Web Cryptography API: डाइजेस्ट और SHA एल्गोरिदमWHATWG Encoding: UTF-8 और टेक्स्ट डिकोडिंग

टेक्स्ट डाउनलोड, साफ़ करना और स्थानीय गोपनीयता

डाउनलोड करें हेक्स परिणाम toolmellow-result.txt में UTF-8 टेक्स्ट रखता है, मूल डाइजेस्ट बाइट, बाइनरी चेकसम सूची या रिपोर्ट नहीं। साफ़ करें इनपुट, आउटपुट, त्रुटियाँ, खोज/बदलाव और एडिटर इतिहास हटाता है, पर एल्गोरिदम और पंक्तियाँ लपेटें रखता है। रिफ़्रेश या बंद होने से मेमोरी का काम हटता है; डाउनलोड फ़ाइलें डिवाइस पर रहती हैं।

ऐप दिए टेक्स्ट, चयनित फ़ाइल की सामग्री या परिणाम को हैश सर्वर पर अपलोड नहीं करता। साइट लोडिंग फिर भी होस्टिंग को सामान्य मेटाडेटा भेजती है और सार्वजनिक साइट पेज विज़िट में Google Analytics, कुकीज़ व ब्राउज़र/डिवाइस जानकारी इस्तेमाल करती है। स्थानीय हैशिंग गुमनामी, शून्य नेटवर्क ट्रैफ़िक या अवसंरचना में शून्य लॉग नहीं बताती। साफ़ करना मेमोरी के सभी पुनर्प्राप्त योग्य निशान मिटाने की गारंटी नहीं।

बैकलिंक सहित हैश जनरेटर एम्बेड करें

पेज भाषा चुनकर वर्कस्पेस के नीचे इंटीग्रेशन खोलें। HTML स्निपेट कॉपी या डाउनलोड कर ऐसे वेबसाइट क्षेत्र में रखें जो बाहरी iframe और स्क्रिप्ट अनुमति देता हो। इसमें ToolMellow वर्कस्पेस iframe, आकार स्क्रिप्ट और उसी भाषा के ToolMellow पेज का दिखता बैकलिंक है। यह श्रेय लिंक बनाए रखें।

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

आम सवाल

स्रोत और आगे पढ़ें

• NIST FIPS 180-4: सुरक्षित हैश मानक
• W3C Web Cryptography API: डाइजेस्ट और SHA एल्गोरिदम
• WHATWG Encoding: UTF-8 और टेक्स्ट डिकोडिंग
• W3C File API: Blob टेक्स्ट पढ़ना
• ECMAScript: String isWellFormed
• WHATWG HTML: टेक्स्ट एरिया मान और पंक्ति अंत
• W3C Secure Contexts: संभावित भरोसेमंद ओरिजिन
• OWASP: पासवर्ड संग्रह चीट शीट