कुंजियाँ, nonces और IV सुरक्षित रूप से बनाना

तीन अलग-अलग क्रिप्टोग्राफ़िक मानों को सुरक्षित रूप से उत्पन्न करना आवश्यक है: (1) कुंजियाँ — लंबे समय तक उपयोग की जाती हैं, इसलिए उनका अप्रत्याशित और गुप्त होना आवश्यक है। (2) IV — प्रत्येक संदेश के लिए होते हैं, सार्वजनिक हो सकते हैं, लेकिन उनका अप्रत्याशित (CBC) या अद्वितीय (GCM) होना आवश्यक है। (3) नॉन्स — प्रत्येक उपयोग के लिए अद्वितीय होने चाहिए; उनका यादृच्छिक होना आवश्यक भी हो सकता है और नहीं भी।

AES-128: secrets.token_bytes(16)। AES-256: secrets.token_bytes(32)। ChaCha20: secrets.token_bytes(32)। KDF (PBKDF2/Argon2) के बिना कभी भी पासवर्ड से कुंजियाँ प्राप्त न करें। अलग-अलग एल्गोरिदम या उद्देश्यों के बीच कुंजियों का कभी पुनःउपयोग न करें।

from cryptography.hazmat.primitives.asymmetric import ec, rsa rsa_key = rsa.generate_private_key(public_exponent=65537, key_size=2048) ec_key = ec.generate_private_key(ec.SECP256R1()) # The library handles entropy sourcing internally

AES-CBC को प्रत्येक संदेश के लिए समान रूप से यादृच्छिक 16-बाइट IV चाहिए। एक ही कुंजी के साथ किसी IV का कभी पुनःउपयोग न करें। CBC मोड में IV के रूप में कभी काउंटर का उपयोग न करें। उत्पन्न करें: iv = os.urandom(16)। IV को सिफरटेक्स्ट के आगे जोड़ें — इसे गुप्त होने की आवश्यकता नहीं, केवल अप्रत्याशित होना आवश्यक है।

AES-GCM को प्रत्येक (कुंजी, संदेश) युग्म के लिए एक अद्वितीय 96-बिट नॉन्स चाहिए। नॉन्स का पुनःउपयोग GCM को विनाशकारी रूप से तोड़ देता है: हमलावर प्रमाणीकरण कुंजी प्राप्त कर सकता है और संदेशों में जालसाज़ी कर सकता है। या तो यादृच्छिक 12-बाइट नॉन्स (2^32 संदेशों पर बर्थडे सीमा) या काउंटर का उपयोग करें।

एक ही कुंजी से बड़ी मात्रा में एन्क्रिप्शन के लिए: प्रत्येक कुंजी के लिए एक स्थायी काउंटर बनाए रखें। nonce = counter.to_bytes(12, "big")। प्रत्येक एन्क्रिप्शन के बाद काउंटर बढ़ाएँ। काउंटर को स्थायी भंडारण में सहेजें — रीस्टार्ट पर रीसेट होने से पुनःउपयोग होता है।

AES-GCM-SIV और Deoxys-II नॉन्स के गलत उपयोग के प्रति प्रतिरोधी हैं: नॉन्स का पुनःउपयोग सुरक्षा को नियतात्मक एन्क्रिप्शन के स्तर तक घटा देता है (प्रमाणीकरण कुंजी उजागर नहीं होती)। जब नॉन्स की अद्वितीयता की गारंटी देना कठिन हो (वितरित सिस्टम, क्रैश के बाद रीस्टार्ट होने वाली परिस्थितियाँ), तब इनकी अनुशंसा की जाती है।

कच्ची कुंजी सामग्री का सीधे कई उद्देश्यों के लिए उपयोग न करें। उद्देश्य-विशिष्ट कुंजियाँ प्राप्त करें: from cryptography.hazmat.primitives.kdf.hkdf import HKDF। hkdf = HKDF(SHA256(), 32, salt, info=b"enc_key")। key = hkdf.derive(master_key)। प्रत्येक उद्देश्य के लिए अलग info का उपयोग करें।

HKDF का उपयोग करके किसी साझा रहस्य (जैसे, ECDH आउटपुट) से सत्र-विशिष्ट कुंजियाँ प्राप्त करें। TLS 1.3 हैंडशेक और अनुप्रयोग डेटा के लिए अलग-अलग क्लाइंट/सर्वर कुंजियाँ प्राप्त करता है। सत्र कुंजियाँ समझौते के प्रभाव को अलग रखती हैं: किसी एक सत्र की कुंजी जानने से अन्य सत्रों के बारे में कुछ पता नहीं चलता।

किसी कुंजी को सुरक्षित रूप से संग्रहीत करने के लिए, AES-KW (RFC 3394) या AES-GCM का उपयोग करके उसे Key Encryption Key (KEK) से रैप करें। रैप की गई कुंजी को डेटाबेस में संग्रहीत या प्रसारित किया जा सकता है। KEK को HSM या हार्डवेयर-समर्थित कीस्टोर (Android Keystore, Apple Secure Enclave) में संग्रहीत किया जाता है।

परिनियोजन से पहले जाँचें: (1) सभी कुंजियाँ os.urandom/secrets से प्राप्त हों। (2) कोई हार्डकोड की गई कुंजी/IV न हो। (3) एक ही कुंजी के साथ IV का कभी पुनःउपयोग न हो। (4) प्रत्येक संदेश के लिए GCM नॉन्स अद्वितीय हों। (5) कुंजी रोटेशन की समय-सारणी निर्धारित हो। (6) कुंजी प्राप्त करने के लिए अलग-अलग info स्ट्रिंग के साथ HKDF का उपयोग हो।

कुंजियों को वास्तविक यादृच्छिकता से उत्पन्न करना आवश्यक है; CBC IV को यादृच्छिकता चाहिए; GCM नॉन्स को अद्वितीय होना चाहिए। os.urandom/secrets का उपयोग करें, HKDF से कुंजियाँ प्राप्त करें और KEK से रैप करें। नॉन्स के गलत उपयोग के प्रति प्रतिरोधी AEAD आकस्मिक पुनःउपयोग से सुरक्षा प्रदान करते हैं। अगला विषय: शून्य-ज्ञान प्रमाण।