OpenVPN EC बनाम ED: ये नाम ताकत की सीढ़ी क्यों नहीं हैं
EC, ED, ECDHE और auth अलग-अलग सवालों के जवाब देते हैं। कुछ भी तुलना या बदलने से पहले OpenVPN प्रोफ़ाइल को हर नाम के काम के हिसाब से छाँटिए।
एक ही प्रोफ़ाइल में ec, ed, ecdh, ecdsa, auth और TLS सिफ़रों की एक सूची साथ-साथ रखिए, और फ़ाइल छह स्थितियों वाले ताकत-डायल जैसी दिखने लगती है। लेकिन ऐसा नहीं है। हर नाम अलग सवाल का जवाब देता है, और जो दो प्रोफ़ाइल इनमें से किसी एक में अलग हैं, ज़रूरी नहीं कि वे एक-दूसरे से ज़्यादा मज़बूत या कमज़ोर हों। नामों को उनके काम के हिसाब से छाँटने में लगभग पाँच मिनट लगते हैं और यह चालू कॉन्फ़िगरेशन में लोगों द्वारा किए जाने वाले ज़्यादातर बुरे बदलावों को रोकता है।
नीचे की छँटाई उलझन से ही शुरू होती है, फिर बाहर की ओर प्रोफ़ाइल के उन हिस्सों तक जाती है जो वास्तव में तय करते हैं कि आपके ट्रैफ़िक की रक्षा क्या करता है। हर खंड बारी-बारी से एक ग़लत पढ़त लेता है और दिखाता है कि नाम असल में किससे जुड़ा है।
दो अक्षर, दो अलग सवाल
सबसे ज़्यादा बहस पैदा करने वाली जोड़ी EC और ED है, और बहस आमतौर पर मान लेती है कि वे एक ही सवाल के प्रतिद्वंद्वी जवाब हैं। वे एक ही अक्ष पर भी नहीं हैं। EC गणित के एक परिवार का वर्णन करता है: अंडाकार वक्र क्रिप्टोग्राफ़ी, जहाँ सुरक्षा किसी बड़े परिमित क्षेत्र में नहीं बल्कि वक्र पर असतत लघुगणक की कठिनाई से आती है।
ED उसी परिवार के भीतर वक्र का आकार बताता है। Twisted Edwards वक्र ऐसा निरूपण हैं जो गति और कई कार्यान्वयन ग़लतियों के प्रति प्रतिरोध के लिए चुना गया है, और Ed25519 वह नाम है जो लोग आमतौर पर कहते हैं। वक्र अंडाकार वक्र क्रिप्टोग्राफ़ी का प्रतिद्वंद्वी नहीं है; यह अंडाकार वक्र लिखने का एक तरीका है। ED को "नया, ज़्यादा मज़बूत EC" पढ़ना पहला ग़लत मोड़ है, और उसके बाद सब कुछ उसी दिशा में ग़लत होता है।
हस्ताक्षर करना और अदला-बदली करना अलग-अलग काम हैं
परिवार का सवाल तय होने के बाद, बाकी नाम दो स्तंभों में बँट जाते हैं जो कभी एक-दूसरे की जगह नहीं लेते। एक स्तंभ हस्ताक्षर करता है, दूसरा किसी साझा रहस्य पर सहमत होता है।
| Name in the profile | Job it does | What it is not |
|---|---|---|
ecdsa | Signature scheme using elliptic-curve keys | Not a key-exchange method |
eddsa, Ed25519 | Signature scheme for twisted Edwards curves | Not interchangeable with ECDSA |
ecdh, X25519 | Ephemeral key agreement | Not a signature and not a cipher |
auth | HMAC digest for packet authentication | Not the data cipher |
EdDSA और ECDSA दोनों हस्ताक्षर करते हैं, लेकिन ये अलग-अलग कुंजी प्रारूपों वाली अलग योजनाएँ हैं, इसलिए एक के लिए जारी प्रमाणपत्र दूसरे के रूप में काम नहीं आता। EdDSA थोड़े से वक्रों के समूह के लिए परिभाषित है; P-256 उनमें से एक नहीं है, इसीलिए P-256 प्रमाणपत्र ECDSA से सत्यापित होता है और कभी Ed25519 से नहीं।
अदला-बदली स्तंभ में EdDH नाम का कोई समतुल्य नहीं है। Curve25519 कुंजी पर क्षणिक सहमति X25519 है, और वह किसी विशेष वक्र के साथ ECDH है, ठीक वैसे ही जैसे P-256 के साथ। Ed25519 का सख़्त अर्थ हस्ताक्षर योजना है, हालाँकि दोनों वक्र जुड़े होने के कारण नाम अदला-बदली के लिए ढीले ढंग से इस्तेमाल होता है: हस्ताक्षर के लिए इस्तेमाल होने वाला Edwards रूप और X25519 के लिए इस्तेमाल होने वाला Montgomery रूप एक ही अंतर्निहित समूह का वर्णन करते हैं।
EC प्रोफ़ाइल में dh फ़ाइल क्यों नहीं होती
dh फ़ाइल में परिमित क्षेत्र Diffie-Hellman के लिए पहले से बनाए गए पैरामीटर होते हैं, और वे पैरामीटर इसलिए होते हैं कि एक बड़ी अभाज्य संख्या और एक जनरेटर को कहीं से आना ही है। अंडाकार वक्र की अदला-बदली को उनकी ज़रूरत नहीं होती: नामित वक्र ही पैरामीटर-समूह है, और दोनों पक्ष उसे पहले से जानते हैं। EC प्रोफ़ाइल के इस निर्देश को छोड़ पाने की पूरी वजह यही है।
दो स्थितियाँ अब भी ऐसी प्रोफ़ाइल में dh पंक्ति बनाती हैं जो बाकी मामलों में आधुनिक दिखती है। पहली है दूसरा श्रोता या पुराना साथी जो वास्तव में परिमित क्षेत्र के समूहों पर बातचीत करता है। दूसरी है RSA युग के टेम्पलेट से कॉपी किया गया और कभी न हटाया गया बचा हुआ पाठ। जो प्रोफ़ाइल अदला-बदली के लिए वक्र का नाम देती है और फिर भी 2048-बिट dh फ़ाइल लोड करती है, वह ऐसा करने से ज़्यादा सुरक्षित नहीं हो जाती; वह एक बेकार नमूना ढो रही है।
TLS 1.3 ने नाम से कुंजी अदला-बदली हटा दी
TLS_AES_256_GCM_SHA384 की TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 से तुलना कीजिए और छोटा नाम गिरावट जैसा लगता है। यह नाम बदलना है, और वजह संरचनात्मक है: TLS 1.3 ने स्थिर RSA और परिमित क्षेत्र की Diffie-Hellman कुंजी अदला-बदली हटा दी, इसलिए क्षणिक अंडाकार वक्र अदला-बदली ही बचा हुआ एकमात्र ग़ैर-PSK विकल्प है। हर सूट में उसका नाम देना एक ही तथ्य को दर्जन भर बार दोहराना होगा।
प्रमाणपत्र का प्रकार जुड़ी हुई वजह से नाम से ग़ायब हो गया। 1.3 में प्रमाणपत्र हैंडशेक के हस्ताक्षर को प्रमाणित करता है, कुंजी समझौते को नहीं, इसलिए वह अब सूट नहीं चुनता। इसी वजह से कॉन्फ़िगरेशन में 1.3 के लिए अलग सिफ़र सूची है: सूटों के नाम बदले गए और उन्हें फिर से व्यवस्थित किया गया, कमज़ोर नहीं किया गया।
एक नतीजा साफ़ कहने लायक है। ECDHE कुंजी अदला-बदली का एल्गोरिद्म है और कभी सिफ़र नहीं। "अंडाकार" कहा गया सूट इस बारे में कुछ कहता है कि दोनों साथी साझा कुंजी तक कैसे पहुँचे, और इस बारे में कुछ नहीं कि फिर पेलोड को क्या एन्क्रिप्ट करता है।
auth पैकेट प्रमाणित करता है, पेलोड नहीं
auth निर्देश उस HMAC डाइजेस्ट को चुनता है जो पैकेट प्रमाणित करता है, और उसका ऐतिहासिक डिफ़ॉल्ट SHA1 है। ग़ैर-AEAD डेटा सिफ़र के साथ OpenVPN सिफ़रटेक्स्ट पर डाइजेस्ट निकालकर उसे जोड़ता है, यह एन्क्रिप्ट-फिर-MAC व्यवस्था ही पैडिंग से छेड़छाड़ को अव्यावहारिक बनाती है।
यहाँ मिथक यह है कि auth को SHA512 तक बढ़ाने से टनल मज़बूत होती है। यह एन्क्रिप्शन की ताकत नहीं बढ़ाता, और अगर तय किया गया डेटा सिफ़र AES-256-GCM जैसा AEAD मोड है, तो डाइजेस्ट डेटा पैकेट पर बिलकुल लागू नहीं होता। GCM टैग पहले ही उन्हें प्रमाणित करता है, और auth मान कंट्रोल-चैनल के HMAC और अब भी इस्तेमाल हो रहे किसी भी ग़ैर-AEAD सिफ़र के लिए बचा रहता है।
इसलिए निर्देश मायने रखता है, लेकिन फ़ाइल में उसकी जगह जो इशारा करती है उससे कहीं संकरे स्थान पर मायने रखता है। यह जाँचना कि असल में कौन-सा सिफ़र तय हुआ, आपको बताता है कि यह लागू होता है या नहीं।
प्रोफ़ाइल को स्तंभ से पढ़िए, क्रम से नहीं
तीन सवाल परतों को साफ़-साफ़ अलग करते हैं, और हर एक का जवाब तय किए गए सत्र का अलग हिस्सा देता है। कौन-सा सिफ़र पेलोड की रक्षा करता है? कौन-सा टैग या डाइजेस्ट हर पैकेट की ज़मानत देता है, और इस्तेमाल हो रहे सिफ़र को ऐसा कुछ चाहिए भी या नहीं? किसका प्रमाणपत्र हैंडशेक को बंद करता है, और क्या कंट्रोल चैनल अतिरिक्त रूप से tls-auth या tls-crypt से सुरक्षित है?
EC या ED लेबल में कुछ भी उन तीन में से किसी एक को तय नहीं करता, और सूट का नाम अकेले भी उनमें से किसी को तय नहीं करता। तय किया गया नतीजा ही एकमात्र सबूत है, इसलिए शब्दावली से ताकत का अनुमान लगाने के बजाय उसे पढ़िए:
openssl x509 -in client.crt -noout -text | grep -E 'Signature Algorithm|Public Key Algorithm'
grep -i 'control channel' /var/log/openvpn.logपहला कमांड आपको बताता है कि आपका प्रमाणपत्र असल में कौन-सी हस्ताक्षर योजना इस्तेमाल करता है, और यह जानने का यही एकमात्र भरोसेमंद तरीका है कि आप ECDSA चला रहे हैं या Ed25519। दूसरा वह कंट्रोल-चैनल पंक्ति दिखाता है जो क्लाइंट ने सत्र के लिए दर्ज की, जिसमें TLS संस्करण और वह सूट शामिल है जिस पर वह ठहरा। अगर प्रोफ़ाइल का कोई बदलाव इन दोनों आउटपुट में से किसी एक से भी जायज़ नहीं ठहरता, तो वह शायद गुण की नहीं, नाम की तब्दीली है।