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 روی بیشتر پردازنده‌های مدرن دستورهای اختصاصی دارد: AES-NI روی x86، افزونه‌های رمزنگاری روی ARMv8 و معادل‌هایی روی طراحی‌های تازه POWER و RISC-V. وقتی این‌ها هستند، GCM چندین بلوک را در هر رده چرخه موازی اجرا می‌کند و پیاده‌سازی نرم‌افزاری بی‌اهمیت می‌شود. این حالت معمول سرورها، رایانه‌های رومیزی و گوشی‌های کنونی است و به همین دلیل توصیه به استفاده از AES یک پیش‌فرض معقول در مرکز داده است.
مشکل حالت مرتبه دوم است. بدون دستورهای اختصاصی، AES در نرم‌افزار کند است و پیاده‌سازی‌های نرم‌افزاری جدول‌محور همان‌هایی هستند که تاریخچه طولانی مشکلات زمان‌بندی حافظه نهان دارند. یک متمرکزکننده VPN در ماشین مجازی که میزبانش پرچم‌های AES را به مهمان نشان نمی‌دهد دقیقاً همین حالت است و به آسانی از نظر می‌افتد چون پردازنده میزبان آن ویژگی را دارد.
بررسی کنید که فرایند واقعاً چه می‌بیند، نه پردازنده از چه پشتیبانی می‌کند: grep -o aes /proc/cpuinfo | head -1 در Linux، یا پرچم ویژگی معادل در مدل پردازنده ابرناظر.
جایی که ChaCha20-Poly1305 برنده می‌شود
ChaCha20 در نرم‌افزار قابل حمل سریع است چون فقط جمع، دوران و XOR به کار می‌برد و پیاده‌سازی‌هایش به‌طور طراحی از جستجوی جدول وابسته به راز پرهیز می‌کنند. روی دستگاهی بدون شتاب AES این یک مزیت مادی است و به همین دلیل WireGuard آن را برگزید: توصیف پروتکل WireGuard ChaCha20-Poly1305 را به عنوان رمز داده آن بدون جایگزین فهرست می‌کند.
همین یک انتخاب چیز مفیدی می‌گوید: روی سخت‌افزاری که AES شتاب می‌گیرد، WireGuard در مقایسه با AES-GCM بخشی از توان عبوری را واگذار می‌کند و نویسندگانش این را در ازای رفتاری قابل پیش‌بینی روی گوشی‌ها، روترهای خانگی و میزبان‌های کانتینر پذیرفته‌اند. اگر ناوگان شما بیشتر جعبه‌های کوچک ARM است، این داد و ستد به سود شماست.
حالت مقابل یک متمرکزکننده شلوغ x86 است که در آن AES-GCM با AES-NI مسیر سریع‌تر و بهتر پشتیبانی‌شده است و 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 پاسخ یک خط پیکربندی و یک نتیجه مذاکره‌شده برای ثبت است.
سوم، آیا دو سو می‌توانند توافق کنند؟ رمزی که یک همتا پیاده‌سازی نمی‌کند تصمیم کارایی نیست، قطعی است. به همین دلیل فهرست همتاها از هر معیاری مهم‌تر است: ناوگان مختلط به اشتراک توانایی‌ها نیاز دارد، نه به ترجیح سریع‌ترین ماشین.
اگر اندازه‌گیری می‌کنید، دستگاه، نقطه پایانی و بار را یکسان نگه دارید و یک چیز را تغییر دهید. آزمونی که دو سرور در دو منطقه را مقایسه می‌کند مسیر را می‌سنجد نه رمز را، و معیار یک لپ‌تاپ هیچ چیزی درباره میزبان کانتینری که پرچم‌های پردازنده‌اش پوشانده شده نمی‌گوید. مقایسه کنید و سپس بنویسید کدام رمز واقعاً مذاکره شد: آن ثبت از معیار ارزشمندتر است.