बड़ी कुंजी संख्या VPN को अधिक सुरक्षित क्यों नहीं बनाती

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

कुछ भी तुलना करने से पहले पूछें कि कौन-सी कुंजी गिनी जा रही है और वह किस चीज़ की रक्षा करती है।

तीन कामों वाली तीन कुंजियाँ

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

इसीलिए 256 को 2048 और 32 के साथ आकार के आधार पर क्रम में नहीं रखा जा सकता; ये अलग-अलग प्रश्नों के उत्तर हैं।

एक ही भूमिका के भीतर भी संख्या केवल प्रयुक्त एल्गोरिथ्म परिवार के सापेक्ष कुछ कहती है।

संख्या कहाँ मदद करती है और कहाँ रुक जाती है

एक एल्गोरिथ्म के भीतर बड़ी कुंजी क्रूर-शक्ति खोज की लागत बढ़ाती है, और प्रकाशित दिशानिर्देश गणना-शक्ति बदलने के साथ प्रमाणपत्र कुंजियों के लिए न्यूनतम तय करते हैं। यह वैध और सीमित तुलना है: AES-128 और AES-256 दोनों व्यापक अंतर से सीधे हमले का सामना करते हैं, इसलिए व्यवहार में अंतर शायद ही निर्णायक कारक होता है।

उस तुलना के बाहर संख्या कॉन्फ़िगरेशन त्रुटियों, प्रमाणपत्र सत्यापन या प्रोटोकॉल संस्करण के बारे में कुछ नहीं बताती।

पूरा वार्ता-निर्धारित सूट पढ़ें

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

openvpn --show-ciphers | head -20
openvpn --show-tls | head -20
openssl x509 -in server.crt -noout -text | grep -E 'Public-Key|Signature Algorithm'
wg show

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

वे भाग जिन्हें कोई संख्या कभी नहीं मापती

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

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