प्रश्न और कार्यक्षेत्र (Scope)
एक ML-DSA हस्ताक्षर-सत्यापन wrapper लागू करें जिसका कॉलर एल्गोरिदम, पब्लिक कुंजी, संदेश, हस्ताक्षर और context प्रदान करता है। आप इनपुट को कैसे मान्य करते हैं, क्रॉस-प्रोटोकॉल रीप्ले को कैसे रोकते हैं, और त्रुटियों तथा परीक्षणों को कैसे डिज़ाइन करते हैं?
इंटरव्यूअर क्या मूल्यांकन करता है
- लैटिस-क्रिप्टोग्राफी प्रिमिटिव्स को फिर से लिखने के बजाय एक मान्य FIPS 204 कार्यान्वयन का पुन: उपयोग करना।
- एल्गोरिदम पहचानकर्ता, पब्लिक कुंजी, संदेश, हस्ताक्षर और context को स्पष्ट इनपुट के रूप में रखना।
- संवेदनशील विवरण लीक किए बिना अमान्य हस्ताक्षर, विकृत (malformed) इनपुट, असमर्थित एल्गोरिदम और आंतरिक दोषों के बीच अंतर करना।
- क्रॉस-प्रोटोकॉल रीप्ले और कार्यान्वयन विचलन (drift) को रोकने के लिए context बाइंडिंग, एक संकीर्ण इंटरफ़ेस और वेक्टर परीक्षणों का उपयोग करना।
स्पष्टीकरण हेतु प्रश्न
- किस ML-DSA पैरामीटर सेट का उपयोग किया जाता है, और क्या लाइब्रेरी ने FIPS 204 वेक्टर सत्यापन पास कर लिया है?
- कौन सा प्रोटोकॉल context को परिभाषित करता है, क्या यह खाली हो सकता है, और कौन से एन्कोडिंग और लंबाई सीमाएं लागू होती हैं?
- क्या सत्यापन विफलता एक सामान्य व्यावसायिक परिणाम है या एक अलर्ट और ऑडिट इवेंट है?
- क्या संदेश स्ट्रीम किया गया है, क्या प्री-हैश इंटरफ़ेस की आवश्यकता है, और कुंजियों को कैसे रोटेट किया जाता है?
30-सेकंड उत्तर ढांचा (Framework)
मैं इस wrapper को एक मान्य ML-DSA लाइब्रेरी API पर आधारित रखूँगा। एक स्पष्ट एल्गोरिदम पहचानकर्ता से पैरामीटर सेट का चयन करें, बाइट इनपुट और context को मान्य करें, और सत्यापन के लिए संदेश के साथ प्रोटोकॉल context पास करें। केवल मान्य (valid), अमान्य (invalid), असमर्थित (unsupported), या विकृत (malformed) परिणाम लौटाएं; कभी भी अपवाद ट्रेस (exception trace) न लौटाएं। आधिकारिक वैक्टर, छेड़छाड़ (tampering), गलत पैरामीटर सेट, क्रॉस-context रीप्ले, सीमा लंबाई, समवर्तीता (concurrency) और रोटेशन का परीक्षण करें। निजी कुंजियाँ और पूर्ण संदेश कभी भी लॉग में दर्ज नहीं होते हैं।
चरण-दर-चरण गहन विश्लेषण
1. Wrapper की सीमा निर्धारित करें
FIPS 204 ML-DSA हस्ताक्षर और सत्यापन को परिभाषित करता है; RFC 9882 बताता है कि CMS हेज्ड (hedged) और नियतात्मक (deterministic) हस्ताक्षरों के लिए समान सत्यापन एल्गोरिदम का उपयोग करता है। एप्लिकेशन कोड को NTT, सैंपलिंग, या रिजेक्शन सैंपलिंग को लागू नहीं करना चाहिए। निर्भरता, पैरामीटर सेट और परीक्षण किए गए लाइब्रेरी इंटरफ़ेस को पिन करें।
2. इनपुट और context को मान्य करें
जांचें कि एल्गोरिदम पहचानकर्ता की अनुमति है, पब्लिक-कुंजी और हस्ताक्षर बाइट्स चयनित पैरामीटर सेट से मेल खाते हैं, और संदेश नीति के भीतर है। प्रोटोकॉल के अनुसार context को एन्कोड करें। Context कोई लॉग लेबल नहीं है; यह हस्ताक्षर डोमेन पृथक्करण प्रदान करता है और यह वही मान होना चाहिए जिस पर हस्ताक्षरकर्ता द्वारा सहमति व्यक्त की गई है। गायब या गलत context विकृत या अमान्य परिणाम लौटाता है; कभी भी खाली context का अनुमान न लगाएं।
3. सुरक्षित त्रुटि सेमेंटिक्स डिज़ाइन करें
लाइब्रेरी अपवादों, कुंजी सामग्री, या पार्सर विवरणों को प्रतिध्वनित करने के बजाय valid, invalid, unsupported, या malformed जैसा एक संरचित परिणाम लौटाएं। मेट्रिक्स और ऑडिट केवल एल्गोरिदम, संस्करण, परिणाम वर्ग और अनुरोध आईडी रिकॉर्ड करते हैं। आंतरिक दोष एक नियंत्रित त्रुटि चैनल और अलर्टिंग के माध्यम से जाते हैं; लाइब्रेरी क्रैश को अमान्य हस्ताक्षर के रूप में प्रच्छन्न नहीं किया जाना चाहिए।
4. वैक्टर और प्रोटोकॉल परीक्षणों के साथ व्यवहार को लॉक करें
पहले NIST ACVP या FIPS 204-संगत वैक्टर चलाएं, फिर बिट फ़्लिप, ट्रंकेशन, विभिन्न contexts, गलत एल्गोरिदम पहचानकर्ता और पुरानी कुंजियों का परीक्षण करें। क्रॉस-प्रोटोकॉल मामलों में, सुनिश्चित करें कि वही संदेश किसी भिन्न context के तहत स्वीकार न किया जाए। समवर्ती कॉलों के लिए अपरिवर्तनीय इनपुट का उपयोग करें, रोटेशन के दौरान एक स्पष्ट पुरानी-कुंजी विंडो स्वीकार करें, और समाप्ति के बाद अस्वीकार करें।
उच्च गुणवत्ता वाला नमूना उत्तर
मैं इसे ML-DSA के पुन: कार्यान्वयन के बजाय एक मान्य लाइब्रेरी के इर्द-गिर्द एक पतला wrapper बनाऊंगा। कॉलर को एक स्पष्ट एल्गोरिदम पहचानकर्ता, पैरामीटर सेट, पब्लिक कुंजी, संदेश, हस्ताक्षर और प्रोटोकॉल context प्रदान करना होगा। Wrapper प्रारूपों और आकारों को मान्य करता है, सत्यापन API को वही context पास करता है, और विफलता के बाद कभी भी किसी अन्य पैरामीटर सेट या खाली context का पुनः प्रयास नहीं करता है। यह केवल valid, invalid, unsupported, या malformed लौटाता है; आंतरिक दोष अलग से सचेत (alert) करते हैं, और लॉग कुंजियों तथा संदेशों को बाहर रखते हैं। FIPS/ACVP वैक्टर, छेड़छाड़, ट्रंकेशन, क्रॉस-context रीप्ले, कुंजी रोटेशन और समवर्तीता परीक्षण व्यवहार को लॉक करते हैं जबकि लाइब्रेरी संस्करण और पैरामीटर पिन रहते हैं।
सामान्य गलतियाँ
- ML-DSA NTT, सैंपलिंग, या रिजेक्शन सैंपलिंग को फिर से लागू करना।
- एल्गोरिदम पहचानकर्ता को अनदेखा करना और पैरामीटर सेटों में एक ही पब्लिक कुंजी का उपयोग करने का प्रयास करना।
- सत्यापन विफल होने के बाद खाली या वैकल्पिक context के साथ पुनः प्रयास करना।
- लाइब्रेरी दोषों, अमान्य हस्ताक्षरों और विकृत इनपुट को बिना किसी औचित्य के एकल परिणाम में मिला देना।
- लॉग में पूर्ण संदेश, कुंजियाँ या अपवाद ट्रेस लिखना।
- वैक्टर, छेड़छाड़, रीप्ले और रोटेशन मामलों के बिना केवल सुखद पथ (happy path) का परीक्षण करना।
अनुवर्ती प्रश्न और उत्तर
क्या हेज्ड और नियतात्मक हस्ताक्षरों के लिए अलग सत्यापन कोड की आवश्यकता होती है?
नहीं। RFC 9882 बताता है कि दोनों एक ही सत्यापन एल्गोरिदम का उपयोग करते हैं, इसलिए wrapper को हस्ताक्षर मोड के आधार पर दो सत्यापन पथों में विभाजित नहीं होना चाहिए।
Context क्रॉस-प्रोटोकॉल रीप्ले को कैसे रोकता है?
यह हस्ताक्षर को एक प्रोटोकॉल डोमेन से बांधता है। एक ही संदेश और कुंजी का विभिन्न contexts के तहत अलग-अलग सत्यापन अर्थ होता है; context गायब होने पर सत्यापनकर्ता को अनुमान या फ़ॉलबैक नहीं करना चाहिए।
आप लाइब्रेरी अपग्रेड को कैसे संभालते हैं?
पैरामीटर सेट और लाइब्रेरी संस्करण को पिन करें, आधिकारिक वैक्टर और ऐतिहासिक संगतता नमूने चलाएं, फिर परिवर्तन को कैनरी (canary) परिनियोजित करें। संस्करण और परिणाम वर्ग रिकॉर्ड करें, और यदि व्यवहार भिन्न होता है तो माइग्रेशन पूरा होने तक पुराने सत्यापनकर्ता को बनाए रखें।