AES-256 और OFB अलग-अलग सवालों का जवाब देते हैं, और सिफर समीक्षाएं यहीं गलती करती हैं जब इन्हें प्रतिस्पर्धी विकल्प मान लिया जाता है। एक कुंजी आकार के साथ ब्लॉक सिफर का नाम बताता है; दूसरा बताता है कि ब्लॉक सिफर लंबे संदेश के लिए धारा में कैसे बदलता है। सुरक्षा चुनने की पुस्तिका को पूरे निर्माण को देखना चाहिए, जिसमें यह भी शामिल है कि प्राप्तकर्ता बदला हुआ पैकेट कैसे पहचानता है।

निर्माण के चार भागों के नाम बताएं

हर समीक्षा चार सवालों पर आ जाती है: कौन-सा आदिम और कुंजी आकार, उसके साथ संदेशों को कैसे संसाधित किया जाता है, प्राप्तकर्ता अनधिकृत बदलाव को कैसे अस्वीकार करता है, और प्रोटोकॉल इनपुट, कुंजियों और उनके जीवनकाल को कैसे संभालता है। परिचित नामों की सूची केवल पहले का जवाब देती है। दूसरा और तीसरा वहीं हैं जहां असली अंतर रहते हैं, और चौथा वहां जहां कार्यान्वयन चुपचाप अलग हो जाते हैं। उसी क्रम में पूछें और उत्तर लिखें।

OFB NIST के ब्लॉक-सिफर मोड प्रकाशन में गोपनीयता मोड के बीच आता है, और गोपनीयता ही सब कुछ है जो यह देता है। एन्क्रिप्शन मोड को अलग MAC के साथ जोड़ने वाले प्रोटोकॉल को उन्हें ठीक से संयोजित करना होता है, और एल्गोरिदम का नाम उस संयोजन को सिद्ध नहीं करता। इसलिए मोड का नाम अकेले तैनाती का निर्णय नहीं कर सकता।

चौथा सवाल वही है जिसे ऑपरेटर चल रहे सिस्टम पर वास्तव में जांच सकता है।

प्रमाणित निर्माण को प्राथमिकता दें

प्रमाणित एन्क्रिप्शन गोपनीयता और अखंडता साथ देता है, और AEAD निर्माण संबद्ध डेटा को एन्क्रिप्ट किए बिना बदलाव से बचाते हैं। यह पैकेट सुरक्षा का गुण है, और इसका संबंध इससे नहीं है कि किसी व्यक्ति ने सफलतापूर्वक साइन इन किया या नहीं।

Netgate की Netgate की OpenVPN क्रिप्टोग्राफ़िक सेटिंग्स मार्गदर्शिका डेटा चैनल के लिए AEAD विकल्पों की ओर संकेत करती है, जिनमें AES-GCM भी है, और यही वह समर्थित नीति है जिसका पालन करना चाहिए। इंस्टॉल किए गए संस्करण और पीयर क्लाइंट जिन विकल्पों का समर्थन करते हैं उन्हें उपयोग करें, नई तैनाती में ऐतिहासिक मोड क्रम की नकल करने के बजाय। पुरानी संगतता, क्रिप्टो बैकएंड और ऑफलोड समर्थन वास्तव में उपलब्ध को सीमित करते हैं।

समर्थित निर्माण हर बार चतुर संयोजन को हराता है।

प्रस्ताव नहीं, तय परिणाम पढ़ें

स्वीकृत सूची में सिफर दिखना मौजूदा सत्र के बारे में कुछ नहीं कहता। क्लाइंट या गेटवे से तय डेटा-चैनल सुरक्षा पढ़ें, फिर उस नीति से तुलना करें जिसे आप लागू करना चाहते थे। एक पुराने पीयर के लिए अब भी पुराना विकल्प सूचीबद्ध करने वाला कॉन्फ़िगरेशन संगतता का निर्णय है, आपके सामने के सत्र के बारे में वक्तव्य नहीं।

openvpn --config client.conf --verb 4 2>&1 | grep -Ei 'cipher|data channel|auth'

गेटवे पर समकक्ष आउटपुट प्लेटफ़ॉर्म के अनुसार सुरक्षा संबंध या कनेक्शन का क्रिप्टो विवरण है। दोनों हालत में प्रस्ताव और परिणाम अलग तथ्य हैं। एक पुराने पीयर के लिए पुराना विकल्प रखने वाली सूची का मतलब यह नहीं कि हर सत्र उसका उपयोग करता है, और जो सत्र करता है वही आपको जानना था।

दोनों तथ्य साथ दर्ज करें, तारीख और क्लाइंट संस्करण के साथ।

केवल वही मापें जिसकी तुलना हो सके

थ्रूपुट छोरों के हार्डवेयर, कार्यान्वयन, त्वरण, पैकेट आकार और चुने गए कॉन्फ़िगरेशन पर निर्भर करता है। न कुंजी की लंबाई और न OFB शब्द आपको बताते हैं कि कौन-सी तैनाती तेज़ होगी। इसलिए किसी दूसरी साइट का मापन अधिकतम इस बात का संकेत है कि किसी और के पास कौन-सा हार्डवेयर है। आपके अपने आंकड़े आपके अपने छोरों से शुरू होते हैं।

अधिकृत तुलना के लिए छोरों, कार्यभार और आवश्यक नीति को स्थिर रखें, और तय सुरक्षा तथा कार्यान्वयन संस्करण दर्ज करें। फिर परिणाम को इस आधार पर आंकें कि एप्लिकेशन पूरा हुआ या नहीं, कितना खोया और छोर क्या कर रहे थे, न कि एक गति परीक्षण से क्रिप्टो लागत निकालें। दूसरी परिस्थितियों में बना आंकड़ा कहानी है, माप नहीं।

यदि पुराना पीयर नीति पूरी नहीं कर सकता, तो यह उसके मालिक के लिए संगतता का निर्णय है।

अखंडता को सौदे से बाहर रखें

अखंडता जांच बंद करना या असत्यापित सर्वर स्वीकार करना प्रदर्शन अनुकूलन नहीं है और संगतता का सुधार भी नहीं है। यह उस सुरक्षा गुण को बदल देता है जिसके लिए निर्माण चुना गया था। यही बात स्वीकृत सिफर सूची को तब तक बढ़ाने पर भी लागू होती है जब तक पुराना पीयर जुड़ न जाए: कनेक्शन सफल होता है और नीति रह ही नहीं जाती।

स्वीकृत निर्माण और उसके मालिक को पुस्तिका में लिखें, ताकि अगला बदलाव पसंद से नहीं, निर्णय से शुरू हो।

आप चाहते हैं ऐसी नीति जिसे दोनों छोर लागू कर सकें। यह बहस कि कौन-सा नाम सबसे मजबूत है, दूसरी बात है, और वह आमतौर पर बिना निर्णय के खत्म होती है।

संबंधित लेख