स्टॅटिक की फाइलमधील बिट संख्या 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 सोबत वापरली जाते तेव्हा दुसऱ्या वर्गात येते, आणि वापरली जात नाही तेव्हा कोणत्यातही नाही। वर्ग मिसळणारे पुनरावलोकनकर्ते जास्त मजबूत सिफर हवा असताना मोठी की फाइल मागतात।

फाइल उघडकीस आली असेल, तर ती फिरवा आणि मंजूर मार्गाने पुन्हा वितरित करा। तडजोड झालेल्या गुप्तात अक्षरे जोडणे हे फिरवणे नाही, आणि ते उघडकीस आलेली सामग्री वैध ठेवते।

फिरवणीची नोंद ज्या प्रोफाइलची ती आहे त्यासोबत ठेवा। पुढील पुनरावलोकन विचारेल कोणत्या कीने कोणता कालावधी संरक्षित केला, आणि बॅनर त्याचे उत्तर देणार नाही।