स्ट्याटिक कुञ्जी फाइलमा बिट संख्या 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 सँग प्रयोग हुँदा दोस्रो श्रेणीमा पर्छ, र प्रयोग नहुँदा कुनैमा पर्दैन। श्रेणी मिसाउने समीक्षकहरू बलियो साइफर चाहँदा ठूलो कुञ्जी फाइल माग्छन्।

यदि फाइल खुलासा भइसकेको छ भने, यसलाई घुमाउनुहोस् र स्वीकृत च्यानलबाट पुनः वितरण गर्नुहोस्। सम्झौता भएको गोप्यमा अक्षर थप्नु घुमाउनु होइन, र यसले खुलासा भएको सामग्रीलाई वैध राख्छ।

घुमाइको रेकर्ड जुन प्रोफाइलको हो त्यसैसँग राख्नुहोस्। अर्को समीक्षाले सोध्नेछ कुन कुञ्जीले कुन अवधि सुरक्षित राख्यो, र ब्यानरले त्यसको उत्तर दिँदैन।