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 झन्डा छोपिएको कन्टेनर होस्टबारे केही भन्दैन। तुलना गर्नुहोस्, त्यसपछि वास्तवमा कुन साइफर वार्ता भयो लेख्नुहोस्: त्यो अभिलेख बेन्चमार्कभन्दा बढी मूल्यवान छ।