प्रॉम्प्ट और संदर्भ
एक कंपनी के पास मोबाइल, वेब, डिवाइस और थर्ड-पार्टी API क्लाइंट हैं जो अभी भी RSA या एलिप्टिक-कर्व क्रिप्टोग्राफी का उपयोग करते हैं। पोस्ट-क्वांटम क्रिप्टोग्राफी के लिए एक माइग्रेशन योजना डिज़ाइन करें और कम्पैटिबिलिटी, परफॉर्मेंस, की-रोटेशन और रोलबैक की व्याख्या करें।
NIST ने ML-KEM, ML-DSA, और SLH-DSA के लिए FIPS 203, 204, और 205 प्रकाशित किए हैं। यह इंटरव्यू केवल नाम गिनाने का अभ्यास नहीं है: यह इस बात का परीक्षण करता है कि क्या आप दीर्घकालिक गोपनीयता, क्लाइंट लाइफ़साइकिल और ऑपरेशनल जोखिम को चरणबद्ध निर्णयों में बदल सकते हैं। IETF हाइब्रिड TLS ड्राफ्ट अभी भी एक ड्राफ्ट है, इसलिए यह सार्वभौमिक कम्पैटिबिलिटी का वादा नहीं है।
इंटरव्यूअर क्या जांच रहा है
इंटरव्यूअर वास्तविक क्रिप्टोग्राफ़िक संपत्तियों की एक सूची, की-एस्टैब्लिशमेंट (key establishment) और सिग्नेचर के बीच अंतर, हार्वेस्ट-नाउ-डिक्रिप्ट-लेटर (harvest-now-decrypt-later) जोखिम की व्याख्या, क्रिप्टो एजिलिटी के लिए डिज़ाइन, और कम्पैटिबिलिटी, विफलता दर (failure rate) व परफॉर्मेंस के लिए मापने योग्य गेट्स (gates) देखना चाहता है। आपको उन निर्णयों की भी पहचान करनी चाहिए जिनके लिए सुरक्षा, अनुपालन (compliance), वेंडर और प्रोडक्ट समीक्षा की आवश्यकता होती है।
पहले स्पष्ट किए जाने वाले प्रश्न
- किस डेटा को दस साल या उससे अधिक समय तक गोपनीय रहना चाहिए, और किन हस्ताक्षरों को दीर्घकालिक सत्यापन की आवश्यकता है?
- क्लाइंट वर्ज़न, फ़र्मवेयर अपग्रेड पाथ, ऑफ़लाइन अवधियाँ और थर्ड-पार्टी निर्भरताएँ कैसे वितरित हैं?
- RSA, ECDH, और ECDSA कॉल साइट्स, प्रमाणपत्र शृंखलाएं (certificate chains), HSMs, और बैकअप कहाँ हैं?
- क्या ट्रांसपोर्ट, डेटा-एट-रेस्ट, कोड-साइनिंग और टोकन-साइनिंग कुंजियों के लाइफ़साइकिल अलग-अलग हैं?
- हैंडशेक लेटेंसी, मैसेज साइज़, CPU, मेमोरी और विफलता दर के लिए क्या बजट हैं?
- क्या कोई पुराना एल्गोरिदम एक सीमित समय सीमा के लिए बना रह सकता है, और डाउनग्रेड व आपातकालीन रोलबैक को कौन अनुमोदित करता है?
30-सेकंड का उत्तर
“मैं पहले क्रिप्टोग्राफ़िक संपत्तियों और गोपनीयता की समय-सीमा की सूची बनाऊँगा, फिर उन्हें एक्सपोज़र, रिप्लेसमेंट कठिनाई और क्लाइंट अपडेटेबिलिटी के आधार पर रैंक करूँगा। मैं की-एस्टैब्लिशमेंट को सिग्नेचर से अलग रखूँगा और क्लासिकल, पोस्ट-क्वांटम, या हाइब्रिड मोड के लिए कैपेबिलिटी डिटेक्शन के साथ वर्ज़न वाले एल्गोरिदम सुइट्स का उपयोग करूँगा; साइलेंट डाउनग्रेड की अनुमति नहीं होगी। मैं हैंडशेक सफलता, रिस्पॉन्स साइज़, CPU, फ़ॉलबैक और की-रोटेशन मेट्रिक्स को मापते हुए नियंत्रणीय सेवाओं और नए क्लाइंट्स पर कैनरी टेस्ट करूँगा। मैं कम्पैटिबिलिटी, परफॉर्मेंस, ऑडिट और रोलबैक गेट्स पास होने के बाद ही विस्तार करूँगा, साथ ही पुराने प्रारूप के नए क्रेडेंशियल्स जारी किए बिना पुराने सत्यापन कुंजियों को बनाए रखूँगा।”
चरण-दर-चरण विस्तृत उत्तर
चरण 1: एल्गोरिदम और डेटा लाइफटाइम की सूची बनाएं
TLS, VPN, सर्विस-टू-सर्विस RPC, डेटाबेस एन्क्रिप्शन, बैकअप, सिग्नेचर, सर्टिफिकेट, फ़र्मवेयर और वेंडर SDK कॉल साइट्स को स्कैन करें। प्रत्येक संपत्ति के लिए एल्गोरिदम, की-साइज़, उद्देश्य, ओनर, रोटेशन विधि, क्लाइंट वर्ज़न और गोपनीयता अवधि रिकॉर्ड करें। उस ट्रैफ़िक को प्राथमिकता दें जिसे अभी एकत्र किया जा सकता है और जिसे दीर्घकालिक गोपनीयता की आवश्यकता है, फिर उन हस्ताक्षरों को जिन्हें कई वर्षों तक सत्यापित किया जाना चाहिए।
चरण 2: जोखिम श्रेणियां और एक लक्षित बेसलाइन बनाएं
एसेट की क्रिटिकैलिटी, हमले की साध्यता (feasibility), माइग्रेशन विंडो, अन-अपडेटेबल क्लाइंट शेयर और रिप्लेसमेंट लागत का मूल्यांकन करें। बेसलाइन में यह स्पष्ट होना चाहिए कि किन नए कनेक्शनों को पोस्ट-क्वांटम या हाइब्रिड सुरक्षा की आवश्यकता है और कौन से पुराने कनेक्शन केवल एक अनुमोदित, छोटी, निगरानी वाली कम्पैटिबिलिटी विंडो में जारी रह सकते हैं। व्यावहारिक क्वांटम कंप्यूटर की तारीख को ही एकमात्र निर्णय चर (decision variable) न बनाएं।
चरण 3: क्रिप्टोग्राफी को एक रिप्लेसेबल क्षमता बनाएं
वर्ज़न वाले एल्गोरिदम सुइट्स, की-टाइप्स और सर्टिफिकेट नीतियों के माध्यम से व्यावसायिक कोड (business code) को क्रिप्टो लाइब्रेरीज़ से स्वतंत्र रखें। सर्वर कैपेबिलिटी डिक्लेरेशन का मूल्यांकन कर सकता है, लेकिन क्लाइंट्स को कमज़ोर एल्गोरिदम चुनने की अनुमति नहीं होनी चाहिए; एक नीति सेवा को किसी सुइट को रोकने, प्रोवाइडर्स को बदलने और स्कोप रिकॉर्ड करने में सक्षम होना चाहिए। सिफरटेक्स्ट और सिग्नेचर मेटाडेटा में एक वर्ज़न होना चाहिए ताकि ऐतिहासिक प्रारूप पहचाने जा सकें।
चरण 4: की-एस्टैब्लिशमेंट और सिग्नेचर पाथ चुनें
ML-KEM की-एनकैप्सुलेशन के लिए है, जबकि ML-DSA और SLH-DSA सिग्नेचर मानक हैं; उनकी कुंजियाँ, प्रमाणपत्र और परफॉर्मेंस भिन्न होते हैं। TLS के लिए, कार्यान्वयन, ड्राफ़्ट स्थिति, गेटवे और एंडपॉइंट समर्थन की जाँच के बाद ही क्लासिकल प्लस ML-KEM हाइब्रिड हैंडशेक का मूल्यांकन करें। सिग्नेचर के लिए सर्टिफिकेट-चेन साइज़, सत्यापन लागत और संग्रह आवश्यकताओं को अलग से मान्य करें।
चरण 5: कम्पैटिबिलिटी और रोलबैक सीमाओं को परिभाषित करें
नए क्लाइंट्स को कैपेबिलिटी डिटेक्शन के माध्यम से एक सुइट चुनने दें और पुराने क्लाइंट्स को एक स्पष्ट कम्पैटिबिलिटी पूल में रखें। डाउनग्रेड अवलोकनीय (observable), समयबद्ध और प्रति किरायेदार (tenant) या डिवाइस अनुमोदित होना चाहिए; असफल हैंडशेक से असीमित फ़ॉलबैक शुरू नहीं होना चाहिए। रोलबैक को सत्यापन के लिए अभी भी आवश्यक पुरानी सार्वजनिक कुंजियों को हटाए बिना नए ट्रैफ़िक प्रवेश बिंदु को वापस ले लेना चाहिए। कारण, स्कोप और पुनः सक्षम करने के मानदंडों को रिकॉर्ड करें।
चरण 6: कैनरी प्रयोगों के साथ लागत को मापें
आंतरिक सेवाओं, अपडेट करने योग्य मोबाइल क्लाइंट्स और कम जोखिम वाले किरायेदारों पर कनेक्शन सफलता, हैंडशेक लेटेंसी, मैसेज साइज़, CPU, मेमोरी, बैंडविड्थ, सर्टिफिकेट कैशिंग और HSM थ्रूपुट का परीक्षण करें। लोड-टेस्ट पीक्स, कमज़ोर नेटवर्क, ऑफ़लाइन रिकवरी और कई क्षेत्रों का परीक्षण करें। पोस्ट-क्वांटम ओवरहेड की तुलना व्यावसायिक SLOs से करें; सुरक्षा नीति को विश्व स्तर पर अक्षम करने के बजाय वर्ज़न और क्लाइंट प्रकार के अनुसार प्रतिक्रिया दें।
चरण 7: कुंजियों, वेंडरों और ऑडिट का समन्वय करें
नई और पुरानी कुंजियों के लिए जेनरेशन, कस्टडी, रोटेशन, रिवोकेशन, बैकअप और विनाश विंडो को परिभाषित करें। HSMs, क्लाउड KMSs, सर्टिफिकेट अथॉरिटीज, प्रॉक्सी और थर्ड-पार्टी SDKs में लक्ष्य-प्रारूप समर्थन सत्यापित करें; सुइट परिवर्तनों को ऑडिट इवेंट्स के रूप में रिकॉर्ड करें। सुरक्षा नीति की ओनरशिप लेती है, प्लेटफ़ॉर्म कार्यान्वयन का मालिक है, और लीगल या कंप्लायंस लागू रिटेंशन और साक्ष्य आवश्यकताओं की पुष्टि करता है।
चरण 8: रिलीज़ गेट्स और एक दीर्घकालिक निकास निर्धारित करें
रिलीज़ गेट्स में कम्पैटिबिलिटी सफलता, परफॉर्मेंस बजट, पुराने-एल्गोरिदम ट्रैफ़िक शेयर, असामान्य फ़ॉलबैक, रोटेशन सफलता और ऑडिट पूर्णता शामिल होनी चाहिए। प्रत्येक चरण को एक स्टॉप लाइन और ओनर दें। एक बार जब पुराने प्रारूप का ट्रैफ़िक इसकी सीमा से नीचे आ जाए, तो नए पुराने क्रेडेंशियल्स जारी करना बंद करें, फिर सत्यापन विंडो के बाद स्वीकृति रद्द (revoke) करें। माइग्रेशन रिकॉर्ड रखें ताकि अगला एल्गोरिदम प्रतिस्थापन साक्ष्य के साथ शुरू हो।
ट्रेड-ऑफ़ और सीमाएं
हाइब्रिड बनाम विशुद्ध पोस्ट-क्वांटम मोड
हाइब्रिड मोड एक नए एल्गोरिदम पर निर्भरता को कम करता है लेकिन हैंडशेक साइज़, कार्यान्वयन जटिलता और बातचीत परीक्षण को बढ़ाता है। विशुद्ध पोस्ट-क्वांटम मोड लक्ष्य को अधिक सीधे व्यक्त करता है लेकिन अन-अपग्रेड करने योग्य क्लाइंट्स को बाहर कर सकता है। कम्पैटिबिलिटी मैट्रिक्स और जोखिम गेट्स को निर्णय लेने दें।
सुरक्षा सुदृढ़ता बनाम परफॉर्मेंस बजट
बड़ी कुंजियाँ, सिफरटेक्स्ट, या सिग्नेचर MTU, हैंडशेक, कैश और HSM थ्रूपुट को प्रभावित करते हैं। वास्तविक ट्रैफ़िक को मापें और मोबाइल नेटवर्क, डिवाइस CPU, और पीक समवर्ती (peak concurrency) के लिए मार्जिन आरक्षित करें। परफॉर्मेंस ट्यूनिंग को साइलेंट डाउनग्रेड के माध्यम से हासिल नहीं किया जाना चाहिए।
रोलबैक बनाम पुरानी कुंजियों को बनाए रखना
रोलबैक प्रवेश बिंदु और कुंजी विनाश अलग-अलग निर्णय हैं। ऐतिहासिक हस्ताक्षरों के लिए अभी भी पुरानी सार्वजनिक कुंजियों की आवश्यकता हो सकती है, इसलिए रोलबैक को उन्हें तुरंत नहीं हटाना चाहिए। नया जारी करना बंद करें, नए कनेक्शन प्रतिबंधित करें, केवल पढ़ने के लिए सत्यापन बनाए रखें, और साक्ष्य पर्याप्त होने पर ही नष्ट करें।
विफलता अभ्यास और विकास योजना
एक पुराना उपकरण अपग्रेड नहीं किया जा सकता
एक डिवाइस-वर्ज़न इन्वेंट्री, एक अलग गेटवे और एक स्पष्ट समाप्ति तिथि बनाएं। सत्यापित करें कि अलगाव कमज़ोर सुइट को नए क्लाइंट्स में फैलने से रोकता है, और मालिकों को अपग्रेड या प्रतिस्थापन पथ प्रदान करें।
एक बड़ा हैंडशेक कनेक्शन तोड़ देता है
वास्तविक प्रॉक्सी, लोड बैलेंसर्स और मोबाइल नेटवर्क के माध्यम से विखंडन (fragmentation), MTU, टाइमआउट और पुनः प्रयासों का परीक्षण करें। यदि नया सुइट विफल हो जाता है, तो अनुमोदित कम्पैटिबिलिटी पूल पर वापस लौटें और अलर्ट करें; क्लाइंट को अपने दम पर अतिरिक्त कमज़ोर सुइट्स का प्रयास नहीं करना चाहिए।
एक वेंडर केवल पुराने हस्ताक्षरों का समर्थन करता है
वेंडर को एक वर्ज़न वाला इंटरफ़ेस और संक्रमणकालीन प्रमाणपत्र दें, जिसमें पुराने हस्ताक्षरों के लिए सीमित जीवनकाल और अनुमतियां हों। अनियंत्रित निर्भरता को "बाद के काम" में छिपाने के बजाय अनुबंध और स्वीकृति मेट्रिक्स में अपग्रेड प्रतिबद्धता डालें।
सामान्य गलतियाँ और फॉलो-अप
गलती 1: एल्गोरिदम प्रतिस्थापन को केवल एक कॉन्फ़िगरेशन रिलीज़ मानना
फॉलो-अप: आप हर क्रिप्टो कॉल साइट, बैकअप और ऑफ़लाइन डिवाइस को कैसे ढूंढते हैं? एक मजबूत उत्तर एक एसेट इन्वेंट्री, निर्भरता ग्राफ और ओनर का नाम देता है।
गलती 2: FIPS प्रकाशन को सार्वभौमिक क्लाइंट समर्थन मानना
फॉलो-अप: लक्ष्य लाइब्रेरी, सर्टिफिकेट अथॉरिटी, HSM, गेटवे और ब्राउज़र के लिए समर्थन का प्रमाण कहाँ है? एक तैयार मानक को उपयोग करने योग्य उत्पाद कार्यान्वयन से अलग करें।
गलती 3: चुपचाप RSA पर वापस जाना (Silently falling back to RSA)
फॉलो-अप: डाउनग्रेड को कौन अनुमोदित करता है, यह कितने समय तक रहता है, इसे कैसे अलर्ट किया जाता है, और इसे क्या समाप्त करता है? एक ऑडिट योग्य कम्पैटिबिलिटी विंडो दें।
गलती 4: केवल औसत लेटेंसी मापना
फॉलो-अप: आप पीक समवर्ती, कमज़ोर नेटवर्क, पैकेट साइज़, CPU, मेमोरी और सर्टिफिकेट कैशिंग का परीक्षण कैसे करते हैं? स्तरित लोड परीक्षणों और स्टॉप लाइनों का वर्णन करें।
फॉलो-अप प्रश्न और प्रतिक्रियाएँ
की-एस्टैब्लिशमेंट और सिग्नेचर को अलग-अलग माइग्रेट क्यों करें?
की-एस्टैब्लिशमेंट सत्र की गोपनीयता की रक्षा करता है; सिग्नेचर पहचान और अखंडता की रक्षा करते हैं। उनके एल्गोरिदम, सर्टिफिकेट चेन, की-साइज़ और सत्यापन जीवनकाल भिन्न होते हैं, इसलिए अलग-अलग कैनरी एक ही रिप्लेसमेंट पर हर वर्कलोड को अवरुद्ध करने से बचाते हैं।
आप क्रिप्टो एजिलिटी कैसे साबित करते हैं?
वर्ज़न वाले सुइट्स, नीति स्विचिंग, की-मेटाडेटा, प्रोवाइडर रिप्लेसमेंट, एक कम्पैटिबिलिटी मैट्रिक्स, ऑडिट इवेंट्स और रोलबैक अभ्यास दिखाएं। एकल कॉन्फ़िगरेशन फ़ाइल को संपादित करने से यह साबित नहीं होता कि व्यावसायिक कोड, प्रमाणपत्र और डिवाइस पाथ बदले जा सकते हैं।
आप किसी पुराने एल्गोरिदम को स्वीकार करना कब बंद कर सकते हैं?
नए-क्लाइंट कवरेज, कनेक्शन सफलता, परफॉर्मेंस और ऑडिट गेट्स पास होने के बाद, पुराने ट्रैफ़िक को एट्रिब्यूट किया जाता है, और ओनर अपग्रेड पूरा करते हैं, पहले नया जारी करना बंद करें। केवल-पढ़ने के सत्यापन विंडो के बाद, स्वीकृति रद्द करें। प्रत्येक चरण के लिए एक रोलबैक स्थिति और एक ओनर की आवश्यकता होती है।