AES-GCM atau ChaCha20-Poly1305: memilih cipher data VPN

Kedua nama itu konstruksi AEAD, keduanya terstandar, dan pada server x86 masa kini keduanya akan memenuhi tautan gigabit tanpa usaha yang terlihat. Pilihan berhenti menjadi sembarang ketika Anda meninggalkan server itu: router murah, ponsel lama, dan perangkat virtual sering tidak punya akselerasi AES, dan di sana selisihnya besar. Jadi perbandingannya bukan cipher mana yang lebih cepat, melainkan cipher mana yang berjalan baik pada kumpulan titik akhir ini, dan apakah protokolnya sama sekali menawarkan pilihan.

Pekerjaan sama, inti berbeda

Kedua konstruksi memberi kerahasiaan dan integritas dalam satu lintasan dan mengautentikasi data terkait, itulah sebabnya protokol VPN memakainya untuk kanal data. Perbedaannya ada di dalam: AES-GCM adalah cipher blok AES dalam mode penghitung dengan pengautentikasi polinomial atas GF(2^128), sedangkan ChaCha20-Poly1305 adalah cipher aliran dengan kunci 256 bit dan pengautentikasi sekali pakai yang terpisah.

Yang penting secara operasional bersifat umum: keduanya gagal secara katastrofal saat nonce dipakai ulang, keduanya perlu pengelolaan ruang nonce per kunci, dan tak satu pun memperbaiki rekan yang mengautentikasi hal yang salah. Profil yang menyebut AES-256-GCM tidak lebih aman daripada yang menyebut CHACHA20-POLY1305; keduanya kuat bila implementasinya benar.

Di mana AES-GCM menang

AES punya instruksi khusus pada sebagian besar CPU modern: AES-NI pada x86, ekstensi kripto pada ARMv8, dan padanannya pada desain POWER serta RISC-V terbaru. Bila tersedia, GCM menjalankan beberapa blok secara paralel per kelas siklus dan implementasi perangkat lunak menjadi tidak relevan. Ini kasus umum untuk server, desktop, dan ponsel saat ini, dan itulah sebabnya saran memakai AES adalah default yang wajar di pusat data.

Masalahnya adalah kasus tingkat kedua. Tanpa instruksi khusus, AES dalam perangkat lunak lambat, dan implementasi perangkat lunak berbasis tabel adalah yang punya sejarah panjang masalah waktu cache. Konsentrator VPN dalam mesin virtual yang host-nya tidak mengekspos flag AES ke tamu persis kasus ini, dan mudah terlewat karena CPU host memang punya fiturnya.

Periksa apa yang benar-benar dilihat proses, bukan apa yang didukung CPU: grep -o aes /proc/cpuinfo | head -1 di Linux, atau flag fitur padanannya pada model CPU hypervisor.

Di mana ChaCha20-Poly1305 menang

ChaCha20 cepat dalam perangkat lunak portabel karena hanya memakai penjumlahan, rotasi, dan XOR, dan implementasinya menghindari pencarian tabel yang bergantung pada rahasia secara desain. Pada perangkat tanpa akselerasi AES itu keuntungan nyata, dan itulah sebabnya WireGuard memilihnya: deskripsi protokol WireGuard mencantumkan ChaCha20-Poly1305 sebagai cipher datanya tanpa alternatif.

Satu pilihan itu mengatakan sesuatu yang berguna: pada perangkat keras yang AES-nya dipercepat, WireGuard melepas sebagian throughput dibanding AES-GCM, dan para penulisnya menerima itu sebagai tukar untuk perilaku yang dapat diprediksi pada ponsel, router rumah, dan host kontainer. Bila armada Anda sebagian besar kotak ARM kecil, pertukaran itu menguntungkan Anda.

Kasus sebaliknya adalah konsentrator x86 yang sibuk, tempat AES-GCM dengan AES-NI menjadi jalur yang lebih cepat dan lebih didukung, dan tempat ChaCha20 memakan CPU terukur per gigabit. Tak satu pun konstruksi itu kelemahan; pertanyaannya adalah mana yang dieksekusi murah oleh perangkat keras Anda.

Apa yang sebenarnya boleh Anda pilih lewat protokol

Perhatikan pemisahan di OpenVPN: kanal kontrol dan kanal data dinegosiasikan terpisah, jadi suite yang Anda lihat untuk TLS tidak mengatakan apa pun tentang cipher yang melindungi muatan Anda. Ringkasan sesi melaporkan keduanya, dan membaca hanya satu dari keduanya adalah sumber kebingungan yang umum.

Di OpenVPN cipher kanal data berasal dari daftar data-ciphers di kedua ujung. Bila daftar server dan daftar klien tidak beririsan, koneksi entah mundur ke yang diizinkan data-ciphers-fallback atau gagal total, dan kegagalan itu biasanya disalahkan pada lapisan yang keliru. Pasang daftar yang sama di kedua sisi, lalu pastikan hasil yang dinegosiasikan di log alih-alih menganggap urutan daftar dipatuhi.

Putuskan dari tiga fakta tentang penerapan

Pertama, apakah titik akhir punya akselerasi AES? Bila setiap rekan punya, AES-GCM adalah pilihan lebih murah dan default pada sebagian besar konfigurasi yang dirawat. Bila sebagian berarti adalah router kecil atau ponsel lama, ChaCha20-Poly1305 mencegah ekor armada menjadi batas kapasitas.

Kedua, apakah protokolnya sama sekali menawarkan pilihan? Dengan WireGuard keputusannya sudah diambil untuk Anda, dan pekerjaan bergunanya adalah memastikan perkakas di sekitarnya tidak diam-diam mengganti dengan hal lain. Dengan OpenVPN dan IPsec, jawabannya satu baris konfigurasi dan hasil negosiasi yang harus dicatat.

Ketiga, dapatkah kedua ujung sepakat? Cipher yang tidak diimplementasikan satu rekan bukan keputusan kinerja, melainkan pemadaman. Itulah sebabnya daftar rekan lebih penting daripada tolok ukur mana pun: armada campuran perlu irisan kemampuan, bukan preferensi mesin tercepat.

Bila Anda mengukur, jaga perangkat, titik akhir, dan beban tetap sama dan ubah satu hal. Uji yang membandingkan dua server di wilayah berbeda mengukur rute, bukan cipher, dan tolok ukur di laptop tidak mengatakan apa pun tentang host kontainer yang flag CPU-nya tertutup. Bandingkan, lalu catat cipher mana yang benar-benar dinegosiasikan: catatan itu lebih bernilai daripada tolok ukurnya.