स्थैतिक कुंजी फ़ाइल में बिट संख्या OpenVPN सिफ़र की ताकत नहीं है

कोई स्कैनर या सहकर्मी OpenVPN स्थैतिक कुंजी फ़ाइल के भीतर छपी बिट संख्या की ओर इशारा करता है और पूछता है कि टनल इस आकार का सिफ़र क्यों नहीं इस्तेमाल कर रही। सवाल उचित लगता है, और जवाब कोई संख्या नहीं है: बैनर संग्रहीत कुंजी सामग्री गिनता है, जबकि सिफ़र केवल उतना ही भाग खपाता है जितना उसके कुंजी आकार को चाहिए। उस कुल को ताकत की सेटिंग मानने से ऐसे बदलाव होते हैं जो कुछ नहीं बदलते। यह प्रारूप किसी भी एकल एल्गोरिदम के इस्तेमाल से अधिक सामग्री रखने के लिए बनाया गया था।

यहाँ दो सवाल मिल जाते हैं: फ़ाइल कितनी कुंजी सामग्री संग्रहीत करती है, और सहमत सिफ़र कितना मज़बूत है। केवल दूसरा ही टनल का वर्णन करता है।

बैनर की संख्या वास्तव में क्या गिनती है

कंटेनर सिफ़र सामग्री और HMAC सामग्री को अलग संरचनाओं के रूप में क्रमबद्ध करता है, और द्विदिश रूप ऐसे दो सेट रखता है ताकि हर दिशा अपनी कुंजियाँ ले जा सके। लिखने वाला कोड छपी संख्या को क्रमबद्ध संरचनाओं की संख्या, उनके आकार और प्रति बाइट आठ बिट से निकालता है। यह संग्रहण पर अंकगणित है, यह दावा नहीं कि कोई एक सिफ़र हर संग्रहीत बाइट खपाता है। हेडर अधिकतम सिफ़र सामग्री आवंटन भी तय करता है ताकि लाइब्रेरी बदलाव प्रारूप का आकार चुपचाप न बदल सके।

इसकी तुलना प्रमाणपत्र कुंजी से करें, जहाँ बिट संख्या वास्तव में एक वस्तु का आकार बताती है। 4,096 बिट की RSA कुंजी और वह कुंजी फ़ाइल जिसका बैनर 4,096 बिट पढ़ता है, अलग कामों वाली अलग वस्तुएँ हैं, और उन्हें एक ही डायल की दो सेटिंग मानने से बुरे निष्कर्ष निकलते हैं।

एक फ़ाइल में दो कुंजी सेट

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

अगर आपको वाकई लंबी कुंजी चाहिए, तो बदलने वाली सेटिंग सिफ़र या डाइजेस्ट है, और जनरेटर वही बनाता है जो चुने गए एल्गोरिदम को चाहिए।

प्रोफ़ाइल पढ़ने से पता चलता है कि आपके पास कौन-सा मोड है

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

यही अंतर किसी खुलासे पर प्रतिक्रिया भी तय करता है। लीक हुई tls-auth कुंजी सत्र कुंजियाँ उजागर नहीं करती, लेकिन हमलावर को नियंत्रण-चैनल ट्रैफ़िक डालने देती है, इसलिए उसे फिर भी बदलना पड़ता है। लीक हुई secret कुंजी बदतर है, क्योंकि वही वह सामग्री थी जो स्वयं डेटा की रक्षा करती थी।

सुरक्षा समीक्षा में क्या दर्ज होना चाहिए

तीन चीज़ें अलग-अलग दर्ज करें: सहमत डेटा-चैनल सुरक्षा, नियंत्रण-चैनल सुरक्षा, और साथी कैसे प्रमाणित होते हैं। data-ciphers AES-256-GCM जैसी पंक्ति केवल पहले का वर्णन करती है, और वहीं रुकने वाली रिपोर्ट यह जवाब नहीं दे सकती कि नियंत्रण-चैनल बिल्कुल सुरक्षित है या नहीं। स्थैतिक कुंजी फ़ाइल tls-auth या tls-crypt के साथ इस्तेमाल होने पर दूसरी श्रेणी में आती है, और न होने पर किसी में नहीं। श्रेणियाँ मिलाने वाले समीक्षक तब बड़ी कुंजी फ़ाइल माँगते हैं जब उन्हें मज़बूत सिफ़र चाहिए।

अगर फ़ाइल उजागर हो गई है, तो उसे घुमाएँ और स्वीकृत चैनल से दोबारा वितरित करें। समझौता-ग्रस्त रहस्य में अक्षर जोड़ना घुमाना नहीं है, और यह उजागर सामग्री को वैध रहने देता है।

घुमाव का रिकॉर्ड उसी प्रोफ़ाइल के साथ रखें जिसका वह है। अगली समीक्षा पूछेगी किस कुंजी ने किस अवधि की रक्षा की, और बैनर इसका जवाब नहीं देगा।