CSPRNG

मान लीजिए कोई प्रोग्राम वॉलेट के लिए गुप्त मान बना रहा है। हमलावर को उसके कुछ पुराने परिणाम मिल जाते हैं। सुरक्षित जनरेटर को यह जानकारी बाकी परिणामों का अनुमान लगाने में सहायक नहीं बनने देनी चाहिए। यह किसी ग्राफ़ में अंकों का अच्छा वितरण दिखने से अधिक कठिन शर्त है। इसलिए RFC 4086 क्रिप्टोग्राफिक रूप से मजबूत क्रमों को सामान्य सिमुलेशन जनरेटरों से अलग करता है। सांख्यिकीय परीक्षण में अच्छा परिणाम भी पर्याप्त नहीं, यदि seed, यानी वह शुरुआती मान जिससे निर्माण शुरू हुआ, का अनुमान लगाया जा सके। [1]

तकनीकी दस्तावेज़ों में DRBG, अर्थात नियतात्मक यादृच्छिक बिट जनरेटर, नाम भी मिलता है। “नियतात्मक” का अर्थ है कि एक जैसी अवस्था और इनपुट से एक जैसा परिणाम निकलता है; इसलिए अवस्था को गुप्त रहना चाहिए। NIST SP 800-90A Rev. 1 खास तरीकों का वर्णन करता है: Hash_DRBG, HMAC_DRBG और CTR_DRBG। ये तकनीकी प्रक्रियाएँ हैं, इनके नाम लेने वाले हर प्रोग्राम के लिए गुणवत्ता की मुहर नहीं। सेटिंग, एंट्रॉपी का स्रोत और कोड में वास्तविक कार्यान्वयन भी जाँचना पड़ता है। [2]

अवस्था के लीक होने से दो अलग सवाल उठते हैं। क्या हमलावर पुराने गुप्त परिणाम दोबारा निकाल सकता है? क्या वह अगले परिणामों का अनुमान लगा सकता है? पुराने आउटपुट की सुरक्षा Backtracking resistance कहलाती है; भविष्य के आउटपुट की सुरक्षा Prediction resistance। दूसरे गुण के लिए NIST SP 800-90A नई एंट्रॉपी को प्रभावी रूप से जोड़ने की माँग करता है, ताकि नए परिणाम खुल चुकी अवस्था से अलग हो जाएँ। केवल गणना दोबारा चलाने से सुरक्षा लौटे, यह ज़रूरी नहीं। एक सुरक्षा गुण मौजूद होने से दूसरा अपने आप सिद्ध नहीं होता। [2]

लाइब्रेरी तैयार सॉफ़्टवेयर घटक है जिसे वॉलेट इस्तेमाल कर सकता है, लेकिन उसे कॉल करना भी विफल हो सकता है। OpenSSL 3.5 में RAND_bytes() और RAND_priv_bytes() सफलता पर 1, अन्य विफलता पर 0 और मौजूदा तरीका समर्थित न होने पर -1 लौटाते हैं। एंट्रॉपी स्रोत विफल होने पर निर्माण से इनकार किया जा सकता है। प्रोग्राम को आरक्षित मेमोरी क्षेत्र, यानी बफ़र, इस्तेमाल करने से पहले इस वापसी मान की जाँच करनी चाहिए। वरना वह ऐसा डेटा इस्तेमाल कर सकता है जो सुरक्षित ढंग से बना ही नहीं था। [3]

दोहराव परीक्षण में उपयोगी होता है: डेवलपर परिणाम की तुलना अपेक्षित मान से करना चाहता है। इसलिए libsodium का randombytes_buf_deterministic() एक ही seed से एक ही क्रम बनाता है। सामान्य इस्तेमाल में अनचाहा दोहराव समस्या है। वर्चुअल मशीन का स्नैपशॉट कंप्यूटर की अवस्था को मेमोरी सहित सहेजता है। उसे बहाल करने पर जनरेटर की अवस्था और आउटपुट भी दोहर सकते हैं। इसलिए परिवेश की प्रतियाँ जरूरी नहीं कि एक-दूसरे से स्वतंत्र गुप्त मान बनाएँ। [4]

जनरेटर अच्छा यादृच्छिक डेटा दे सकता है, जिसे ऐप आगे गलत ढंग से संसाधित करे। उसे छोटे स्वीकार्य दायरे में बदलने के लिए केवल भाग देने पर बचा शेष इस्तेमाल करने से कुछ परिणाम दूसरों से अधिक बार आ सकते हैं। libsodium का randombytes_uniform() तय ऊपरी सीमा से नीचे समान वितरण से चुनकर इस पक्षपात से बचाता है। कुंजियों को अपने एल्गोरिदम के नियम भी मानने होते हैं। सुरक्षा केवल यादृच्छिक बाइट मिलने तक सीमित नहीं है; आगे उनका इस्तेमाल भी मायने रखता है। [4]

Nonce क्रिप्टोग्राफिक प्रक्रिया में किसी एक इस्तेमाल के लिए रखा गया मान है, लेकिन उसके नियम प्रोटोकॉल तय करता है। RFC 8439 एक ही कुंजी के साथ nonce न दोहराने की माँग करता है; यादृच्छिक दिखना अद्वितीयता की गारंटी नहीं देता। दूसरी ओर RFC 6979 बताता है कि गुप्त कुंजी और हस्ताक्षर किए जाने वाले संदेश से डिजिटल हस्ताक्षर के लिए आवश्यक मान k को नियतात्मक रूप से कैसे निकाला जाए। यह विरोधाभास नहीं, अलग डिज़ाइन है। इसलिए “हर जगह यादृच्छिकता जोड़ दो” सही प्रक्रिया का विकल्प नहीं है। [5] [6]

केवल CSPRNG लिखा होने से यह पता नहीं चलता कि वॉलेट पूरी व्यवस्था का सही इस्तेमाल करता है या नहीं। तकनीकी समीक्षा में लाइब्रेरी का खास संस्करण, जनरेटर की शुरुआत, त्रुटियों का प्रबंधन और अवस्था बहाल या कॉपी होने के बाद का व्यवहार देखा जाता है। OpenSSL और libsodium के दस्तावेज़ उनके फ़ंक्शन के गुण बताते हैं, उन्हें कॉल करने वाले हर ऐप की सुरक्षा नहीं। उपयोगकर्ता के लिए आगे की कहानी भी महत्त्वपूर्ण है: पूरी तरह सुरक्षित ढंग से बना रहस्य भी धन की रक्षा नहीं कर पाता, यदि बाद में ऐसा बैकअप लीक हो जाए जिससे पहुँच बहाल की जा सकती हो। [3] [4]