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 ध्वज झाकलेले आहेत अशा कंटेनर होस्टबद्दल काहीही सांगत नाही. तुलना करा, नंतर प्रत्यक्षात कोणता सिफर ठरला ते लिहून ठेवा: ती नोंद बेंचमार्कपेक्षा अधिक मूल्यवान आहे.