AES-GCM या ChaCha20-Poly1305: VPN डेटा सिफ़र चुनना
हार्डवेयर त्वरण वाले सर्वर पर AES-GCM स्पष्ट पसंद है, और ChaCha20-Poly1305 उसके बिना भी अच्छी तरह चलता है। हो सकता है आपका प्रोटोकॉल आपके लिए फ़ैसला कर दे।
दोनों नाम AEAD संरचनाएँ हैं, दोनों मानकीकृत हैं, और किसी मौजूदा x86 सर्वर पर इनमें से कोई भी बिना दिखने वाले प्रयास के गीगाबिट लिंक भर देगा। चुनाव तब मनमाना होना बंद कर देता है जब आप उस सर्वर से बाहर निकलते हैं: सस्ते राउटर, पुराने फ़ोन और वर्चुअल उपकरणों में अक्सर AES त्वरण नहीं होता, और वहाँ अंतर बड़ा है। इसलिए तुलना यह नहीं है कि कौन-सा सिफ़र तेज़ है, बल्कि यह है कि कौन-सा सिफ़र इस एंडपॉइंट समूह पर अच्छा चलता है और क्या प्रोटोकॉल चुनाव की पेशकश भी करता है।
एक ही काम, अलग कोर
दोनों संरचनाएँ एक ही पास में गोपनीयता और अखंडता देती हैं और संबद्ध डेटा को प्रमाणित करती हैं, इसलिए VPN प्रोटोकॉल उन्हें डेटा चैनल के लिए इस्तेमाल करते हैं। अंतर अंदर है: AES-GCM काउंटर मोड में AES ब्लॉक सिफ़र है जिसमें GF(2^128) पर बहुपद प्रमाणक है, जबकि ChaCha20-Poly1305 256 बिट कुंजी वाला स्ट्रीम सिफ़र है जिसमें अलग एकबारगी प्रमाणक है।
परिचालन के लिहाज़ से ज़रूरी बात साझा है: दोनों nonce के दोबारा इस्तेमाल पर भयावह रूप से विफल होते हैं, दोनों को हर कुंजी के लिए nonce स्थान का प्रबंधन चाहिए, और कोई भी उस साथी को ठीक नहीं करता जो गलत चीज़ प्रमाणित करता है। AES-256-GCM कहने वाला प्रोफ़ाइल CHACHA20-POLY1305 कहने वाले से अधिक सुरक्षित नहीं है; कार्यान्वयन सही होने पर दोनों मज़बूत हैं।
AES-GCM कहाँ जीतता है
अधिकतर आधुनिक CPU पर AES के लिए समर्पित निर्देश हैं: x86 पर AES-NI, ARMv8 पर क्रिप्टो एक्सटेंशन, और हाल के POWER तथा RISC-V डिज़ाइनों पर समकक्ष। जब ये मौजूद हों तो GCM प्रति चक्र-वर्ग कई ब्लॉक समानांतर चलाता है और सॉफ़्टवेयर कार्यान्वयन अप्रासंगिक हो जाता है। यह सर्वर, डेस्कटॉप और मौजूदा फ़ोन के लिए सामान्य स्थिति है, और इसीलिए डेटा सेंटर में AES इस्तेमाल करें की सलाह उचित डिफ़ॉल्ट है।
समस्या दूसरे दर्जे की स्थिति है। समर्पित निर्देशों के बिना सॉफ़्टवेयर में AES धीमा है, और तालिका-चालित सॉफ़्टवेयर कार्यान्वयन ही वे हैं जिनका cache-समय समस्याओं का लंबा इतिहास है। ऐसी वर्चुअल मशीन में चलने वाला VPN कॉन्सेंट्रेटर जिसका होस्ट मेहमान को AES फ़्लैग नहीं दिखाता, ठीक यही स्थिति है, और इसे आसानी से चूक जाते हैं क्योंकि होस्ट CPU में यह सुविधा है।
जाँचें कि प्रक्रिया वास्तव में क्या देखती है, न कि CPU क्या समर्थन करता है: Linux पर grep -o aes /proc/cpuinfo | head -1, या हाइपरवाइज़र के CPU मॉडल में समकक्ष सुविधा फ़्लैग।
ChaCha20-Poly1305 कहाँ जीतता है
ChaCha20 पोर्टेबल सॉफ़्टवेयर में तेज़ है क्योंकि यह केवल जोड़, घूर्णन और XOR इस्तेमाल करता है, और इसके कार्यान्वयन डिज़ाइन से ही रहस्य-आधारित तालिका खोज से बचते हैं। AES त्वरण रहित उपकरण पर यह ठोस लाभ है, और इसीलिए WireGuard ने इसे चुना: WireGuard प्रोटोकॉल का विवरण ChaCha20-Poly1305 को बिना किसी विकल्प के उसका डेटा सिफ़र बताता है।
वह एक चुनाव उपयोगी बात कहता है: जहाँ AES त्वरित है वहाँ WireGuard AES-GCM की तुलना में थोड़ा थ्रूपुट छोड़ देता है, और इसके लेखकों ने फ़ोन, घरेलू राउटर और कंटेनर होस्ट पर अनुमानित व्यवहार के बदले इसे स्वीकार किया है। अगर आपका बेड़ा मुख्यतः छोटे ARM बॉक्स हैं तो यह सौदा आपके पक्ष में है।
उलटी स्थिति व्यस्त x86 कॉन्सेंट्रेटर है, जहाँ AES-NI के साथ AES-GCM तेज़ और बेहतर समर्थित रास्ता है, और जहाँ ChaCha20 प्रति गीगाबिट मापने योग्य CPU खर्च करता है। कोई भी संरचना कमज़ोरी नहीं है; सवाल यह है कि आपका हार्डवेयर किसे सस्ते में निष्पादित करता है।
आपका प्रोटोकॉल वास्तव में क्या चुनने देता है
| Protocol | What you get |
|---|---|
| WireGuard | ChaCha20-Poly1305 only; no negotiation |
| OpenVPN 2.5 and later | Data channel negotiated from data-ciphers: AES-256-GCM, AES-128-GCM, CHACHA20-POLY1305 |
| IPsec / IKEv2 | AES-GCM as a combined-mode transform, or ChaCha20-Poly1305 where both peers implement it |
| OpenVPN control channel | TLS decides; TLS 1.3 offers AES-GCM and ChaCha20-Poly1305 suites |
OpenVPN में बँटवारे पर ध्यान दें: नियंत्रण चैनल और डेटा चैनल अलग-अलग तय होते हैं, इसलिए TLS के लिए आप जो सूट देखते हैं वह आपके पेलोड की रक्षा करने वाले सिफ़र के बारे में कुछ नहीं कहता। सत्र सारांश दोनों बताता है, और दोनों में से केवल एक पढ़ना भ्रम का आम स्रोत है।
OpenVPN में डेटा चैनल का सिफ़र दोनों सिरों की data-ciphers सूची से आता है। अगर सर्वर की सूची और क्लाइंट की सूची न मिलें तो कनेक्शन या तो data-ciphers-fallback जो अनुमति देता है उस पर लौट जाता है या पूरी तरह विफल हो जाता है, और वह विफलता आम तौर पर गलत परत पर मढ़ी जाती है। दोनों ओर एक ही सूची रखें, फिर सूची का क्रम माना गया है यह मानने के बजाय लॉग में तय किया गया परिणाम पुष्ट करें।
तैनाती के तीन तथ्यों से फ़ैसला करें
पहला, क्या एंडपॉइंट में AES त्वरण है? अगर हर साथी के पास है तो AES-GCM सस्ता चुनाव और अधिकतर अनुरक्षित कॉन्फ़िगरेशन में डिफ़ॉल्ट है। अगर ठोस हिस्सा छोटे राउटर या पुराने फ़ोन हैं तो ChaCha20-Poly1305 बेड़े की पूँछ को क्षमता की सीमा बनने से रोकता है।
दूसरा, क्या प्रोटोकॉल चुनाव की पेशकश ही करता है? WireGuard के साथ फ़ैसला आपके लिए हो चुका है, और उपयोगी काम यह जाँचना है कि उसके आसपास के औज़ार चुपचाप कुछ और नहीं रख रहे। OpenVPN और IPsec के साथ जवाब एक कॉन्फ़िगरेशन पंक्ति और दर्ज करने योग्य तय परिणाम है।
तीसरा, क्या दोनों सिरे सहमत हो सकते हैं? जिस सिफ़र को एक साथी लागू नहीं करता वह प्रदर्शन का फ़ैसला नहीं, बाधा है। इसीलिए साथियों की सूची किसी भी बेंचमार्क से ज़्यादा मायने रखती है: मिश्रित बेड़े को क्षमताओं का प्रतिच्छेद चाहिए, सबसे तेज़ मशीन की पसंद नहीं।
अगर आप मापें तो उपकरण, एंडपॉइंट और भार समान रखें और एक चीज़ बदलें। अलग-अलग क्षेत्रों के दो सर्वरों की तुलना करने वाला परीक्षण मार्ग मापता है, सिफ़र नहीं, और लैपटॉप का बेंचमार्क ऐसे कंटेनर होस्ट के बारे में कुछ नहीं कहता जिसके CPU फ़्लैग छिपे हैं। तुलना करें, फिर लिखकर रखें कि वास्तव में कौन-सा सिफ़र तय हुआ: वह अभिलेख बेंचमार्क से अधिक मूल्यवान है।