Entropy Mixing में जनरेटर कई इनपुट को एक साथ संसाधित करता है। उद्देश्य किसी एक स्रोत पर निर्भर रहने के बजाय अलग-अलग स्रोतों की अनिश्चितता का लाभ लेना हो सकता है। लेकिन अतिरिक्त डेटा और अतिरिक्त एंट्रॉपी एक बात नहीं हैं: ज्ञात जानकारी की कॉपी कोई नया रहस्य नहीं जोड़ती। सुरक्षा विशिष्ट स्रोतों और उन्हें जोड़ने की सत्यापित विधि पर निर्भर करती है।
एक ही घटना के दो रिकॉर्ड की कल्पना कीजिए। फ़ाइलों के नाम अलग हैं, लेकिन दूसरा रिकॉर्ड कोई स्वतंत्र अज्ञात बात नहीं जोड़ता। इसी तरह पैकेट आने और डिस्क एक्सेस के समय आपस में जुड़े हो सकते हैं। NIST SP 800-90B चेताता है कि निर्भर स्रोतों की एंट्रॉपी के अनुमान सीधे नहीं जोड़े जा सकते। पहले देखें कि हमलावर को बाकी इनपुट भी मालूम हों तो क्या अनिश्चित बचता है। [1]
हैश डेटा से गणना करके बनाई गई पहचान है। लेकिन हमलावर को सभी इनपुट मालूम हों तो वह वही परिणाम निकाल सकता है। न लंबा hash और न जोड़ा गया सार्वजनिक स्थिरांक ज्ञात डेटा को रहस्य बनाता है। RFC 4086 उपलब्ध अनिश्चितता को मिलाने और नियतात्मक तरीके से अधिक मान बनाने में अंतर करता है। सही ढंग से बनाया गया मिश्रण स्रोतों की वास्तविक देन का उपयोग करता है; अनुपस्थित एंट्रॉपी की जगह नहीं लेता। [2]
XOR बिटों की तुलना करता है: समान बिट शून्य देते हैं और अलग बिट एक। इसलिए X XOR X = 0: किसी मान को उसकी कॉपी से मिलाने पर यहाँ सारी अनिश्चितता खत्म हो जाती है। इसके विपरीत, एक इनपुट समान वितरण वाला यादृच्छिक मान हो और दूसरे से स्वतंत्र हो, तो परिणाम भी समान वितरण वाला रहता है। RFC 4086 इससे दिखाता है कि धारणाएँ क्यों महत्वपूर्ण हैं। यह घर पर वॉलेट जनरेटर बनाने का नुस्खा नहीं है। [2]
किसी खास डिज़ाइन का मूल्यांकन करते समय पूछें कि इनपुट कहाँ से आते हैं और हमलावर उनके साथ क्या कर सकता है। क्रिप्टोग्राफ़िक कुंजियाँ निकालने की विधि HKDF में salt नाम का सहायक इनपुट होता है। उसका गुप्त होना ज़रूरी नहीं है, लेकिन RFC 5869 उसे कुंजी के शुरुआती डेटा से स्वतंत्र मानता है और ऐप को हमलावर द्वारा उसके चुनाव या बदलाव को रोकने के लिए कहता है। यहाँ Salt एक पैरामीटर का नाम है। स्रोतों की सूची या यादृच्छिक दिखता परिणाम अपने आप किसी स्रोत की खराबी पर सुरक्षा की गारंटी नहीं देते। [4]
NIST SP 800-90B एक मुख्य शोर स्रोत को आधार बनाता है। वह अन्य स्रोतों के परिणाम उसके डेटा के साथ जोड़ने देता है, बशर्ते सभी डेटा conditioning नाम की अनुमोदित प्रसंस्करण विधि से गुज़रें। लेकिन इस व्यवस्था में उन स्रोतों की अतिरिक्त एंट्रॉपी नहीं गिनी जाती। इसलिए अधिक इनपुट होने से मान्य मात्रा अपने आप नहीं बढ़ती। यह खास मूल्यांकन का नियम है, ऐसा दावा नहीं कि अन्य स्रोत कभी मदद नहीं कर सकते। [1]
यह अंतर OpenSSL 3.5 में दिखता है। यह एक क्रिप्टोग्राफ़िक लाइब्रेरी है, जिसे प्रोग्राम एन्क्रिप्शन और यादृच्छिक संख्याओं जैसे कामों के लिए इस्तेमाल कर सकते हैं। RAND_add() फ़ंक्शन बफ़र, यानी डेटा रखने के लिए तय मेमोरी क्षेत्र, से डेटा मिलाता है। num बताता है कि कितने बाइट पढ़ने हैं; randomness उनकी एंट्रॉपी का अनुमान बाइट में शून्य से num तक देता है। मेमोरी क्षेत्र का आकार इस अनुमान को साबित नहीं करता। डिफ़ॉल्ट जनरेटर आम तौर पर खुद शुरू होता है और सिस्टम स्रोतों से स्वतः एंट्रॉपी की भरपाई करता है। [3]
जनरेटर में ताज़ा एंट्रॉपी जोड़ना reseeding कहलाता है। यह कोई भी डेटा जोड़ देने से अलग है। OpenSSL 3.5 के दस्तावेज़ के अनुसार, क्रिप्टोग्राफ़िक मॉड्यूल के नियमों का पालन करने वाले FIPS मोड में ऐप के डेटा को भरोसेमंद एंट्रॉपी स्रोत नहीं माना जाता। उसे केवल अतिरिक्त इनपुट के तौर पर मिलाया जाता है, पूर्ण reseed नहीं गिना जाता। इसलिए सिर्फ़ RAND_add() बुलाना उस नवीनीकरण का प्रमाण नहीं है। [3]
RFC 5869 का HKDF काम को HKDF-Extract और HKDF-Expand में बाँटता है। पहला चरण इनपुट की उपलब्ध एंट्रॉपी को एक मध्यवर्ती कुंजी में केंद्रित करता है; दूसरा उससे आवश्यक लंबाई का डेटा निकालता है। इससे कोई नया स्वतंत्र रहस्य नहीं मिलता। info पैरामीटर परिणाम को उसके उपयोग से जोड़ सकता है, जैसे यह बताना कि निकाली गई कुंजी किस काम के लिए है। यह संदर्भ अच्छे शुरुआती डेटा का विकल्प नहीं है और नई एंट्रॉपी बनने का प्रमाण भी नहीं। [4]
पूरी तस्वीर के लिए इस प्रविष्टि के साथ यह भी पढ़ें Cryptographic Entropy, CSPRNG, True Random Number Generator, Seed Generation. इस प्रविष्टि का उल्लेख यहाँ भी है Dice Roll Entropy, True Random Number Generator.