प्रॉम्प्ट और संदर्भ
एक मल्टी-टेनेंट कॉन्फ़िगरेशन सेवा को संवेदनशील डेटाबेस मानों को एन्क्रिप्ट करना होगा। प्रत्येक टेनेंट की एक स्वतंत्र लॉजिकल कुंजी होती है; प्लेटफ़ॉर्म को रूट कुंजियों को रोटेट करना, पुराने सिफरटेक्स्ट को पढ़ना और टेनेंट या रिकॉर्ड के बीच कॉपी किए गए सिफरटेक्स्ट का पता लगाना होगा। एन्वेलप, एन्क्रिप्ट/डिक्रिप्ट प्रवाह, कुंजी संस्करण, संदर्भ बाइंडिंग और माइग्रेशन को डिज़ाइन करने के लिए Go 1.26 crypto/hpke का उपयोग करें। मुख्य कौशल सही क्रिप्टोग्राफ़िक API संरचना और जीवनचक्र डिज़ाइन है, इसलिए यह एक coding प्रश्न है।
साक्षात्कारकर्ता क्या मूल्यांकन करता है
पहला, क्या आप HPKE KEM, KDF और AEAD की भूमिकाओं को समझते हैं और सार्वजनिक-कुंजी एनकैप्सुलेशन को सममित डेटा एन्क्रिप्शन से अलग पहचानते हैं।
दूसरा, क्या आप Base, PSK, या Auth मोड चुन सकते हैं और प्रमाणीकरण कुंजियों तथा गोपनीयता कुंजियों के बीच की सीमा को समझा सकते हैं।
तीसरा, क्या क्रॉस-संदर्भ डिक्रिप्शन को रोकने के लिए टेनेंट, उद्देश्य, सुइट और संस्करण info या AAD में बाउंड हैं।
चौथा, क्या रोटेशन, पुराने संस्करण के रीड, निरस्तीकरण (revocation), और पुनः एन्क्रिप्शन को संस्करण संख्या को गुप्त माने बिना डिज़ाइन किया गया है।
पांचवां, क्या छेड़छाड़, रीप्ले, यादृच्छिकता (randomness), विफलता-जानकारी और अंतर-संचालनीयता (interoperability) परीक्षण कार्यान्वयन को मान्य करते हैं।
पहले स्पष्ट करने योग्य प्रश्न
- क्या केवल गोपनीयता पर्याप्त है, या प्रेषक को क्रिप्टोग्राफ़िक रूप से प्रमाणित होना चाहिए?
- प्राप्तकर्ता की सार्वजनिक कुंजी का स्वामी कौन है, और क्या KMS, HSM और ऑडिट आवश्यकताएं मौजूद हैं?
- पुराने सिफरटेक्स्ट कितने समय तक रहते हैं, और क्या बैकग्राउंड पुनः एन्क्रिप्शन आवश्यक है?
- क्या टेनेंट और कॉन्फ़िगरेशन-कुंजी संबंधों को दृश्यमान मेटाडेटा होने की अनुमति है?
- क्या क्रॉस-भाषा डिक्रिप्शन या ऑफ़लाइन रिकवरी की आवश्यकता है?
- क्या अनुपलब्ध कुंजियों, असमर्थित संस्करणों और प्रमाणीकरण विफलताओं को अलग करने योग्य होना चाहिए?
30 सेकंड का उत्तर
“मैं एक RFC 9180 सुइट और Go 1.26 को पिन करता हूँ। सेवा प्रत्येक टेनेंट की प्राप्तकर्ता निजी कुंजी रखती है, जबकि एप्लिकेशन इसकी सार्वजनिक कुंजी के साथ एनकैप्सुलेट करते हैं। एन्वेलप सुइट और कुंजी संस्करण संग्रहीत करता है; टेनेंट और उद्देश्य info में बाउंड हैं और टेनेंट, कुंजी तथा रिकॉर्ड संस्करण AEAD AAD में बाउंड हैं। डिक्रिप्शन एन्वेलप संस्करण द्वारा पुरानी निजी कुंजी का चयन करता है। नए राइट्स रोटेट किए गए संस्करण का उपयोग करते हैं और एक बैकग्राउंड जॉब पुराने डेटा को पुनः एन्क्रिप्ट करता है। मैं Auth केवल तभी चुनता हूँ जब प्रेषक प्रमाण की आवश्यकता हो। परीक्षणों में छेड़छाड़, क्रॉस-टेनेंट स्वैप, रीप्ले, यादृच्छिकता, पुराने संस्करण और क्रॉस-भाषा वैक्टर शामिल हैं।”
विस्तृत समाधान
चरण 1: एन्वेलप परतों को अलग करें
HPKE KEM के साथ एक साझा रहस्य स्थापित करता है, KDF के साथ कुंजियाँ प्राप्त करता है, और AEAD के साथ संदेश को एन्क्रिप्ट करता है। एन्वेलप सुइट, कुंजी संस्करण, एनकैप्सुलेटेड सामग्री, नॉनस या क्रमबद्ध सिफरटेक्स्ट, और सार्वजनिक मेटाडेटा संग्रहीत करता है। रूट और प्राप्तकर्ता की निजी कुंजियाँ KMS या HSM में रहती हैं, कभी भी सिफरटेक्स्ट या एप्लिकेशन लॉग में नहीं।
चरण 2: मोड और पहचान सिमेंटिक्स चुनें
Base मोड प्रेषक प्रमाणीकरण के बिना प्राप्तकर्ता सार्वजनिक-कुंजी एन्क्रिप्शन देता है। PSK एक पूर्व-साझा कुंजी जोड़ता है। Auth स्रोत को प्रमाणित करने के लिए प्रेषक कुंजी का उपयोग करता है। प्लेटफ़ॉर्म लॉगिन पहचान का अर्थ यह नहीं है कि HPKE ने प्रेषक को प्रमाणित किया है; प्राधिकरण और क्रिप्टोग्राफ़िक मोड अलग-अलग परतें हैं।
चरण 3: संदर्भ को बाइंड करें
info में प्रोटोकॉल, सेवा, संस्करण और उद्देश्य को बाइंड करें। AEAD AAD में टेनेंट ID, कॉन्फ़िगरेशन कुंजी और रिकॉर्ड संस्करण को तब बाइंड करें जब वे फ़ील्ड एन्वेलप के साथ यात्रा करते हैं और उनका बरकरार रहना आवश्यक हो। डिक्रिप्शन समान इनपुट की पुनर्गणना करता है, इसलिए टेनेंट, उद्देश्य या संस्करण स्वैप प्रमाणीकरण में विफल हो जाता है।
envelope = suite_id | key_version | encapsulated_key | aad_fields | ciphertext
info = "config-envelope/v1" | tenant_scope | purpose
aad = tenant_id | config_key | record_versionचरण 4: कुंजी जीवनचक्र डिज़ाइन करें
प्रत्येक कुंजी संस्करण में निर्माण समय, स्थिति, डिक्रिप्शन स्कोप और विनाश नीति होती है। राइट्स स्विच करने से पहले नई सार्वजनिक कुंजी प्रकाशित करें; रीड्स एन्वेलप संस्करण द्वारा पुरानी निजी कुंजी का चयन करते हैं। पुनः एन्क्रिप्शन और ऑडिट जांच पूरी होने तक पुराने संस्करणों को केवल-पढ़ने योग्य रखें, फिर उन्हें निरस्त करें।
चरण 5: रीप्ले और सीरियलाइज़ेशन को संभालें
AEAD छेड़छाड़ का पता लगाता है लेकिन एक वैध पुराने सिफरटेक्स्ट को फिर से सबमिट किए जाने से नहीं रोकता है। यदि कॉन्फ़िगरेशन में कोई संस्करण या मोनोटोनिक अनुक्रम है, तो व्यावसायिक परत अपेक्षित संस्करण की जांच करती है। स्पष्ट लंबाई, संस्करण और सुइट फ़ील्ड का उपयोग करें और अज्ञात सुइट्स, ट्रंकेशन, या डुप्लिकेट फ़ील्ड को अस्वीकार करें।
चरण 6: त्रुटि सीमा को परिभाषित करें
बाहरी रूप से एक समान डिक्रिप्शन विफलता लौटाएं। आंतरिक रूप से संरचित कारण और कुंजी संस्करण का ऑडिट करें, कभी भी निजी कुंजियों, प्लेनटेक्स्ट या पूर्ण सिफरटेक्स्ट का नहीं। अनुपलब्ध कुंजी, असमर्थित प्रारूप और प्रमाणीकरण विफलता को अलग करना संचालन में मदद करता है, लेकिन अविश्वसनीय कॉलर को समय या संदेशों से टेनेंट या कुंजी के अस्तित्व के बारे में नहीं जानना चाहिए।
चरण 7: परीक्षण और माइग्रेशन का निर्माण करें
निश्चित RFC वैक्टर, यादृच्छिकता, एकल-बाइट छेड़छाड़, क्रॉस-टेनेंट AAD, पुराने-संस्करण रीड्स, समवर्ती रोटेशन, निरस्तीकरण के बाद विफलता और बड़े-संदेश चंकिंग का परीक्षण करें। क्रॉस-भाषा प्रणालियों को साझा सीरियलाइज़ेशन और वैक्टर की आवश्यकता होती है। पूर्व-1.26 सेवाएँ एक अनुकूलता रैपर या अपग्रेड गेट का उपयोग करती हैं; प्रयोगात्मक API गलती से उत्पादन में प्रवेश नहीं करते हैं।
एक उच्च-गुणवत्ता वाला नमूना उत्तर
“मैं HPKE को एक एन्वेलप परत के रूप में उपयोग करता हूँ: KEM और KDF एक साझा कुंजी स्थापित और प्राप्त करते हैं, और AEAD कॉन्फ़िगरेशन प्लेनटेक्स्ट की सुरक्षा करता है। एन्वेलप में सुइट, कुंजी संस्करण, एनकैप्सुलेटेड सामग्री और सिफरटेक्स्ट शामिल हैं; टेनेंट, उद्देश्य, कुंजी और रिकॉर्ड संस्करण क्रॉस-टेनेंट प्रतियों को रोकने के लिए info और AAD के माध्यम से बाउंड होते हैं। Base केवल प्राप्तकर्ता गोपनीयता देता है; प्रेषक प्रमाण की आवश्यकता होने पर मैं Auth या बाहरी हस्ताक्षर चुनता हूँ। रोटेशन पहले नए संस्करण को लिखता है, पुराने को केवल-पढ़ने के लिए रखता है, बैकग्राउंड में पुनः एन्क्रिप्ट करता है, फिर सत्यापन के बाद इसे निरस्त करता है। AEAD रीप्ले को नहीं रोकता है, इसलिए व्यावसायिक संस्करण की जांच की जाती है। निजी कुंजियाँ KMS/HSM में रहती हैं, और परीक्षणों में छेड़छाड़, निरस्तीकरण, त्रुटियां और क्रॉस-भाषा वैक्टर शामिल हैं।”
सामान्य गलतियाँ
- Base को प्रेषक प्रमाणीकरण मानना → प्राप्तकर्ता यह साबित नहीं कर सकता कि इसे किसने भेजा → Auth या बाहरी हस्ताक्षर का उपयोग करें।
- टेनेंट को केवल दृश्यमान मेटाडेटा में रखना → एक हमलावर टेनेंट्स के बीच सिफरटेक्स्ट स्वैप कर सकता है → इसे
infoया AAD में बाइंड करें। - रोटेशन के तुरंत बाद पुरानी कुंजी को हटाना → ऐतिहासिक डेटा अपठनीय हो जाता है → केवल-पढ़ने योग्य विंडो रखें और पहले पुनः एन्क्रिप्ट करें।
- यह मान लेना कि AEAD रीप्ले को रोकता है → एक वैध पुराना सिफरटेक्स्ट फिर से सबमिट किया जा सकता है → व्यावसायिक संस्करण या अनुक्रम की जांच करें।
- निजी कुंजियों को कॉन्फ़िगरेशन या लॉग में संग्रहीत करना → एन्क्रिप्शन सीमा टूट जाती है → KMS/HSM और न्यूनतम विशेषाधिकार का उपयोग करें।
- बिना संस्करण वाला बाइनरी प्रारूप बनाना → माइग्रेशन और सुइट अस्वीकृति असुरक्षित हो जाती है → स्पष्ट संस्करण, लंबाई और सुइट को एनकोड करें।
- विस्तृत डिक्रिप्शन त्रुटियाँ लौटाना → टेनेंट या कुंजी का अस्तित्व लीक हो सकता है → समान बाहरी त्रुटियाँ और आंतरिक ऑडिट।
- केवल सफलता का परीक्षण करना → छेड़छाड़ और पुराने-संस्करण की विफलताएं उत्पादन तक पहुंचती हैं → वैक्टर, क्रॉस-संदर्भ और निरस्तीकरण परीक्षण जोड़ें।
फॉलो-अप प्रश्न
फॉलो-अप 1: सभी प्लेनटेक्स्ट को सीधे RSA या ECDH से एन्क्रिप्ट क्यों नहीं करते?
HPKE स्पष्ट रूप से KEM, KDF और AEAD को संयोजित करता है, जो सममित सत्र कुंजी को एनकैप्सुलेट करने और बड़े संदेशों को संभालने के लिए उपयुक्त है। मनमाने प्लेनटेक्स्ट का प्रत्यक्ष सार्वजनिक-कुंजी एन्क्रिप्शन लंबाई, यादृच्छिकता और मोड के दुरुपयोग को आमंत्रित करता है।
फॉलो-अप 2: Auth मोड कब उपयुक्त है?
Auth का उपयोग तब करें जब प्राप्तकर्ता को क्रिप्टोग्राफ़िक प्रमाण की आवश्यकता हो कि किसी ज्ञात प्रेषक कुंजी ने भाग लिया है। यदि केवल प्राप्तकर्ता गोपनीयता की आवश्यकता है, तो अप्रबंधित प्रमाणीकरण कुंजी न जोड़ें।
फॉलो-अप 3: info और AAD में क्या अंतर है?
info कुंजी व्युत्पत्ति में भाग लेता है और प्रोटोकॉल संदर्भ को परिभाषित करता है। AAD दृश्यमान रहता है लेकिन AEAD द्वारा अखंडता-संरक्षित होता है, जिससे यह एन्वेलप मेटाडेटा के लिए उपयुक्त होता है जिसे डिक्रिप्शन के दौरान मेल खाना चाहिए।
फॉलो-अप 4: आप सुरक्षित रूप से पुनः एन्क्रिप्ट कैसे करते हैं?
एक इडेम्पोटेंट लेनदेन या पुन: प्रयास योग्य वर्कफ़्लो में पुराने संस्करण को पढ़ें और नया लिखें। नए सिफरटेक्स्ट द्वारा डिक्रिप्ट-एंड-रीड-बैक और ऑडिट जांच पास करने के बाद ही पुरानी कुंजी को निरस्त करें।
फॉलो-अप 5: आप किसी सिफरटेक्स्ट को दूसरे रिकॉर्ड में जाने से कैसे रोकते हैं?
टेनेंट, कॉन्फ़िगरेशन कुंजी, रिकॉर्ड संस्करण और उद्देश्य को AAD में रखें, और रीड्स के दौरान वर्तमान डेटाबेस मानों से AAD का पुनर्निर्माण करें। एक कॉपी किया गया एन्वेलप तब अपने प्रमाणीकरण टैग में विफल हो जाता है।
फॉलो-अप 6: क्या HPKE फ़ॉरवर्ड सीक्रेसी प्रदान करता है?
यह गुणधर्म कुंजी जीवनचक्र और मोड पर निर्भर करता है। लंबे समय तक चलने वाली स्थिर प्राप्तकर्ता निजी कुंजी के साथ, ऐतिहासिक सिफरटेक्स्ट सुरक्षा उस कुंजी पर निर्भर करती है। मजबूत फ़ॉरवर्ड सीक्रेसी के लिए एफेमरल कुंजियों, रोटेशन, विनाश और प्रोटोकॉल-स्तरीय सत्रों की आवश्यकता होती है; अकेले API नाम इसे प्रदान नहीं करता है।