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

Kedua-dua nama ialah binaan AEAD, kedua-duanya piawai, dan pada pelayan x86 semasa mana-mana satu daripadanya akan memenuhi pautan gigabit tanpa usaha yang kelihatan. Pilihan berhenti menjadi sewenang-wenangnya apabila anda meninggalkan pelayan itu: penghala murah, telefon lama dan peranti maya selalunya tiada pecutan AES, dan di sana perbezaannya besar. Jadi perbandingan bukanlah sifer mana yang lebih pantas, tetapi sifer mana yang berjalan baik pada set titik akhir ini, dan sama ada protokol itu menawarkan pilihan.

Kerja sama, teras berbeza

Kedua-dua binaan memberi kerahsiaan dan integriti dalam satu laluan dan mengesahkan data berkaitan, sebab itu protokol VPN menggunakannya untuk saluran data. Perbezaannya di dalam: AES-GCM ialah sifer blok AES dalam mod pembilang dengan pengesah polinomial atas GF(2^128), manakala ChaCha20-Poly1305 ialah sifer aliran dengan kunci 256 bit dan pengesah sekali guna yang berasingan.

Apa yang penting dari segi operasi adalah perkara biasa: kedua-duanya gagal teruk apabila nonce digunakan semula, kedua-duanya memerlukan pengurusan ruang nonce bagi setiap kunci, dan tiada satu pun membaiki rakan yang mengesahkan perkara yang salah. Profil yang menyebut AES-256-GCM tidak lebih selamat daripada yang menyebut CHACHA20-POLY1305; kedua-duanya kuat apabila pelaksanaannya betul.

Di mana AES-GCM menang

AES mempunyai arahan khusus pada kebanyakan CPU moden: AES-NI pada x86, sambungan kripto pada ARMv8 dan setara padanya pada reka bentuk POWER dan RISC-V terkini. Apabila ada, GCM menjalankan beberapa blok secara selari bagi setiap kelas kitaran dan pelaksanaan perisian menjadi tidak relevan. Ini kes biasa bagi pelayan, komputer meja dan telefon semasa, dan sebab itulah nasihat menggunakan AES ialah nilai lalai yang wajar di pusat data.

Masalahnya ialah kes peringkat kedua. Tanpa arahan khusus, AES dalam perisian lambat, dan pelaksanaan perisian yang dipacu jadual ialah yang mempunyai sejarah panjang masalah masa cache. Penumpu VPN dalam mesin maya yang hosnya tidak mendedahkan bendera AES kepada tetamu ialah tepat kes ini, dan mudah terlepas kerana CPU hos mempunyai ciri itu.

Semak apa yang benar-benar dilihat oleh proses, bukan apa yang disokong oleh CPU: grep -o aes /proc/cpuinfo | head -1 pada Linux, atau bendera ciri yang setara dalam model CPU hypervisor.

Di mana ChaCha20-Poly1305 menang

ChaCha20 pantas dalam perisian mudah alih kerana ia hanya menggunakan penambahan, putaran dan XOR, dan pelaksanaannya mengelakkan carian jadual yang bergantung pada rahsia mengikut reka bentuk. Pada peranti tanpa pecutan AES itu kelebihan nyata, dan sebab itulah WireGuard memilihnya: huraian protokol WireGuard menyenaraikan ChaCha20-Poly1305 sebagai sifer datanya tanpa alternatif.

Satu pilihan itu mengatakan sesuatu yang berguna: pada perkakasan yang AES dipercepatkan, WireGuard melepaskan sedikit daya pengeluaran berbanding AES-GCM, dan penulisnya menerima itu sebagai pertukaran untuk tingkah laku yang boleh diramal pada telefon, penghala rumah dan hos kontena. Jika armada anda kebanyakannya kotak ARM kecil, pertukaran itu memihak kepada anda.

Kes sebaliknya ialah penumpu x86 yang sibuk, di mana AES-GCM dengan AES-NI ialah laluan lebih pantas dan lebih disokong, dan di mana ChaCha20 memakan CPU yang boleh diukur bagi setiap gigabit. Tiada satu pun binaan itu kelemahan; persoalannya ialah mana yang dilaksanakan oleh perkakasan anda dengan murah.

Apa yang sebenarnya dibenarkan protokol anda untuk pilih

Perhatikan pemisahan dalam OpenVPN: saluran kawalan dan saluran data dirunding secara berasingan, jadi suit yang anda lihat untuk TLS tidak mengatakan apa-apa tentang sifer yang melindungi muatan anda. Ringkasan sesi melaporkan kedua-duanya, dan membaca hanya satu daripada dua itu ialah sumber kekeliruan yang biasa.

Dalam OpenVPN sifer saluran data datang daripada senarai data-ciphers pada kedua-dua hujung. Jika senarai pelayan dan senarai klien tidak bersilang, sambungan sama ada berundur kepada apa yang dibenarkan data-ciphers-fallback atau gagal sepenuhnya, dan kegagalan itu biasanya disalahkan pada lapisan yang salah. Letakkan senarai yang sama pada kedua-dua belah, kemudian sahkan hasil rundingan dalam log dan bukannya menganggap susunan senarai telah dipatuhi.

Putuskan daripada tiga fakta tentang penggunaan

Pertama, adakah titik akhir mempunyai pecutan AES? Jika setiap rakan ada, AES-GCM ialah pilihan lebih murah dan nilai lalai dalam kebanyakan konfigurasi yang diselenggara. Jika bahagian yang bermakna ialah penghala kecil atau telefon lama, ChaCha20-Poly1305 menghalang ekor armada daripada menjadi had kapasiti.

Kedua, adakah protokol itu menawarkan pilihan? Dengan WireGuard keputusan telah dibuat untuk anda, dan kerja yang berguna ialah mengesahkan bahawa alat di sekelilingnya tidak menggantikan sesuatu yang lain secara senyap. Dengan OpenVPN dan IPsec jawapannya ialah satu baris konfigurasi dan hasil rundingan yang perlu direkodkan.

Ketiga, bolehkah kedua-dua hujung bersetuju? Sifer yang tidak dilaksanakan oleh satu rakan bukan keputusan prestasi, ia adalah gangguan. Sebab itulah senarai rakan lebih penting daripada mana-mana penanda aras: armada bercampur memerlukan persilangan keupayaan, bukan keutamaan mesin terpantas.

Jika anda mengukur, kekalkan peranti, titik akhir dan beban sama dan ubah satu perkara. Ujian yang membandingkan dua pelayan di wilayah berbeza mengukur laluan, bukan sifer, dan penanda aras pada komputer riba tidak mengatakan apa-apa tentang hos kontena yang bendera CPU-nya bertopeng. Bandingkan, kemudian catat sifer mana yang benar-benar dirunding: rekod itu lebih bernilai daripada penanda aras.