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 যেখানে জেতে
বেশিরভাগ আধুনিক প্রসেসরে AES-এর জন্য নিবেদিত নির্দেশনা আছে: x86-এ AES-NI, ARMv8-এ ক্রিপ্টো এক্সটেনশন, এবং সাম্প্রতিক POWER ও RISC-V ডিজাইনে সমতুল্য। সেগুলো থাকলে GCM প্রতি চক্র-শ্রেণিতে কয়েকটি ব্লক সমান্তরালে চালায় এবং সফটওয়্যার বাস্তবায়ন অপ্রাসঙ্গিক হয়ে যায়। এটি সার্ভার, ডেস্কটপ ও বর্তমান ফোনের সাধারণ অবস্থা, তাই ডেটা সেন্টারে AES ব্যবহার করুন পরামর্শটি যুক্তিসঙ্গত ডিফল্ট।
সমস্যাটি দ্বিতীয় শ্রেণির অবস্থা। নিবেদিত নির্দেশনা ছাড়া সফটওয়্যারে AES ধীর, আর টেবিল-চালিত সফটওয়্যার বাস্তবায়নগুলোরই cache-timing সমস্যার দীর্ঘ ইতিহাস আছে। যে ভার্চুয়াল মেশিনে চলা VPN কনসেন্ট্রেটরের হোস্ট অতিথিকে কোনো AES ফ্ল্যাগ দেখায় না, সেটি ঠিক এই অবস্থা, এবং হোস্ট প্রসেসরে সুবিধাটি থাকায় এটি সহজে চোখ এড়িয়ে যায়।
প্রসেসর কী সমর্থন করে তা নয়, প্রক্রিয়াটি আসলে কী দেখে তা যাচাই করুন: Linux-এ grep -o aes /proc/cpuinfo | head -1, বা হাইপারভাইজরের প্রসেসর মডেলে সমতুল্য বৈশিষ্ট্য ফ্ল্যাগ।
ChaCha20-Poly1305 যেখানে জেতে
ChaCha20 বহনযোগ্য সফটওয়্যারে দ্রুত কারণ এটি কেবল যোগ, ঘূর্ণন ও XOR ব্যবহার করে, আর এর বাস্তবায়নগুলো নকশা অনুযায়ী গোপনীয়তা-নির্ভর টেবিল অনুসন্ধান এড়ায়। AES ত্বরণ নেই এমন ডিভাইসে এটি বাস্তব সুবিধা, এবং এ কারণেই WireGuard এটি বেছে নিয়েছিল: WireGuard প্রোটোকলের বর্ণনা ChaCha20-Poly1305-কে বিকল্পহীন ডেটা সাইফার হিসেবে তালিকাভুক্ত করে।
সেই একটি পছন্দ কাজের কথা বলে: যে হার্ডওয়্যারে AES ত্বরিত, সেখানে WireGuard AES-GCM-এর তুলনায় কিছু থ্রুপুট ছেড়ে দেয়, আর এর লেখকেরা ফোন, হোম রাউটার ও কন্টেইনার হোস্টে পূর্বানুমেয় আচরণের বিনিময়ে তা মেনে নিয়েছেন। আপনার বহর বেশিরভাগ ছোট ARM বাক্স হলে সেই বিনিময় আপনার পক্ষে।
বিপরীত অবস্থাটি হলো ব্যস্ত x86 কনসেন্ট্রেটর, যেখানে AES-NI-সহ AES-GCM দ্রুততর ও বেশি সমর্থিত পথ, এবং যেখানে ChaCha20 প্রতি গিগাবিটে মাপা যায় এমন প্রসেসর খরচ করে। কোনোটিই দুর্বলতা নয়; প্রশ্ন হলো আপনার হার্ডওয়্যার কোনটি কম খরচে চালায়।
আপনার প্রোটোকল আসলে কী বেছে নিতে দেয়
| 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-এ উত্তর হলো একটি কনফিগারেশন লাইন ও লিপিবদ্ধ করার মতো একটি দরকষাকষিকৃত ফলাফল।
তৃতীয়ত, দুই প্রান্ত একমত হতে পারে কি? একটি প্রতিপক্ষ যে সাইফার বাস্তবায়ন করে না তা পারফরম্যান্সের সিদ্ধান্ত নয়, তা একটি বিভ্রাট। তাই প্রতিপক্ষ তালিকা যেকোনো বেঞ্চমার্কের চেয়ে বেশি জরুরি: মিশ্র বহরের সক্ষমতার ছেদ দরকার, দ্রুততম মেশিনের পছন্দ নয়।
মাপতে চাইলে ডিভাইস, এন্ডপয়েন্ট ও কাজের চাপ একই রাখুন এবং একটি জিনিস বদলান। ভিন্ন অঞ্চলের দুই সার্ভার তুলনা করা পরীক্ষা পথ মাপে, সাইফার নয়, আর ল্যাপটপের বেঞ্চমার্ক এমন কন্টেইনার হোস্ট সম্পর্কে কিছুই বলে না যার প্রসেসর ফ্ল্যাগ ঢাকা। তুলনা করুন, তারপর কোন সাইফার আসলে দরকষাকষি হয়েছে লিখে রাখুন: সেই রেকর্ড বেঞ্চমার্কের চেয়ে বেশি মূল্যবান।