उत्पादन प्रणालियों के लिए AEAD चुनना

अधिकांश उत्पादन प्रणालियों के लिए AES-GCM सही डिफ़ॉल्ट AEAD है। लगभग सभी आधुनिक x86 और ARM64 प्रोसेसरों पर AES-NI के माध्यम से इसे हार्डवेयर त्वरण मिलता है, TLS स्टैक और क्रिप्टोग्राफ़िक लाइब्रेरी में इसका व्यापक समर्थन है, और व्यापक क्रिप्टविश्लेषण तथा वास्तविक उपयोग का अनुभव इसके पक्ष में है।

AES-GCM 96-बिट नॉन्स का उपयोग करता है। यादृच्छिक रूप से बनाए गए नॉन्स के साथ, एक ही कुंजी के अंतर्गत लगभग 2^32 संदेशों के बाद बर्थडे सीमा पहुँच जाती है। उस समय नॉन्स टकराव की संभावना नगण्य नहीं रहती। उच्च-मात्रा वाली प्रणालियों के लिए काउंटर के माध्यम से नॉन्स प्रबंधन या 2^32 संदेशों के बाद कुंजी बदलना आवश्यक है।

जब AES-NI उपलब्ध न हो या नॉन्स बनाना अविश्वसनीय हो सकता हो, तब ChaCha20-Poly1305 सही विकल्प है। यह सॉफ़्टवेयर में तेज़ है, रचना के स्तर पर स्थिर-समय वाला है (समय-आधारित साइड-चैनल के प्रति प्रतिरोधी), और AES हार्डवेयर समर्थन रहित परिवेशों के लिए TLS 1.3 में अनिवार्य साइफ़र सुइट है।

जब नॉन्स का पुनः उपयोग हो सकता हो या उन्हें निर्धार्य रूप से बनाना आवश्यक हो, जैसे स्थिति-रहित सेवाओं या कुंजी रैपिंग में, तब AES-GCM-SIV (RFC 8452) सही विकल्प है। यह मानक AES-GCM की तुलना में थोड़ी प्रदर्शन लागत पर नॉन्स के दुरुपयोग से सुरक्षा प्रदान करता है।

जब अधिकतम एन्क्रिप्शन प्रवाह क्षमता आवश्यक हो और सभी परिनियोजन लक्ष्यों पर AES-NI की उपलब्धता सुनिश्चित हो, तब AEGIS-128L सही विकल्प है। उच्च-बैंडविड्थ नेटवर्क उपकरण, VPN कॉन्सन्ट्रेटर और स्टोरेज एन्क्रिप्शन प्रणालियाँ इसके लिए उपयुक्त उम्मीदवार हैं, जहाँ AEGIS AES-GCM की तुलना में उल्लेखनीय प्रदर्शन लाभ देता है।

AES-128 128-बिट सुरक्षा प्रदान करता है, जिसे वर्तमान और निकट भविष्य के सभी शास्त्रीय कंप्यूटिंग खतरों के लिए पर्याप्त माना जाता है। AES-256 भविष्य की प्रगति के विरुद्ध अतिरिक्त सुरक्षा अंतर देता है और कुछ अनुपालन ढाँचों के लिए आवश्यक है, जैसे NSA के Suite B के अंतर्गत TOP SECRET वर्गीकरण। अधिकांश अनुप्रयोगों के लिए AES-128 पर्याप्त और थोड़ा तेज़ है।

AES-GCM 96-बिट नॉन्स का उपयोग करता है, जबकि AES-GCM-SIV भी 96-बिट नॉन्स का उपयोग करता है। XSalsa20 (जिसका उपयोग libsodium secretbox में होता है) 192-बिट नॉन्स का उपयोग करता है, जिससे एक ही कुंजी के अंतर्गत बहुत अधिक संदेशों के लिए यादृच्छिक नॉन्स बनाना सुरक्षित हो जाता है। बड़े नॉन्स उच्च-मात्रा वाली प्रणालियों में आकस्मिक पुनः उपयोग का जोखिम घटाते हैं।

क्रिप्टोग्राफ़िक मूलभूत घटकों को सीधे लागू करने के बजाय स्थापित AEAD लाइब्रेरी का उपयोग करें। libsodium एक सरल AEAD API प्रदान करता है (crypto_aead_aes256gcm_encrypt, crypto_aead_chacha20poly1305_ietf_encrypt)। Google Tink AEAD मूलभूत घटकों को कुंजी बदलने और संस्करण प्रबंधन के साथ समेटता है। भाषा-विशिष्ट TLS लाइब्रेरी परिवहन सुरक्षा के लिए AEAD को अपने-आप संभालती हैं।

अलग HMAC-SHA256 के साथ AES-CBC (EtM क्रम में) स्वीकार्य है, लेकिन पुराना विकल्प है। AES-GCM में स्थानांतरण दो मूलभूत घटकों को एक से बदलकर कार्यान्वयन को सरल बनाता है और गलत संयोजन के जोखिम को समाप्त करता है। CBC-HMAC से एन्क्रिप्ट किए गए संग्रहीत डेटा को नियोजित कुंजी परिवर्तन के दौरान AES-GCM से फिर से एन्क्रिप्ट किया जाना चाहिए।

AEAD कार्यान्वयनों का परीक्षण NIST के आधिकारिक परीक्षण वेक्टर (AES-GCM के लिए) और RFC 8439 (ChaCha20-Poly1305 के लिए) के विरुद्ध किया जाना चाहिए। हमेशा जाँच करें कि प्रमाणीकरण टैग सत्यापन की विफलता पर डिक्रिप्शन आंशिक प्लेनटेक्स्ट लौटाने के बजाय त्रुटि लौटाता है। त्रुटि प्रबंधन में गलती कार्यान्वयन की एक सामान्य कमी है।

जब AES-NI उपलब्ध हो और नॉन्स अद्वितीय हों, तब AES-GCM चुनें। जब AES-NI उपलब्ध न हो या नॉन्स कम विश्वसनीय हों, तब ChaCha20-Poly1305 चुनें। जब नॉन्स के पुनः उपयोग की चिंता हो, तब AES-GCM-SIV चुनें। जब AES-NI की उपलब्धता सुनिश्चित हो और अधिकतम प्रवाह क्षमता प्राथमिकता हो, तब AEGIS चुनें। नई प्रणालियों के लिए गैर-AEAD मोड कभी न चुनें।

AES-GCM डिफ़ॉल्ट विकल्प है। ChaCha20-Poly1305 उन परिवेशों के लिए है जहाँ AES-NI उपलब्ध नहीं है। AES-GCM-SIV नॉन्स के असुरक्षित परिवेशों को संभालता है। जब AES-NI की उपलब्धता सुनिश्चित हो, तब AEGIS प्रवाह क्षमता को अधिकतम करता है। मूलभूत घटकों को स्वयं जोड़ने के बजाय libsodium या Tink जैसी लाइब्रेरी का उपयोग करें। हमेशा आधिकारिक परीक्षण वेक्टर के विरुद्ध परीक्षण करें और सुनिश्चित करें कि प्रमाणीकरण विफलताओं को सही ढंग से संभाला जाता है।