AES-GCM aŭ ChaCha20-Poly1305: elekti datumĉifron por VPN

Ambaŭ nomoj estas konstruaĵoj AEAD, ambaŭ estas normigitaj, kaj sur nuntempa servilo x86 ĉiu el ili saturigos gigabitan ligilon sen videbla peno. La elekto ĉesas esti arbitra kiam vi forlasas tiun servilon: malmultekostaj enkursigiloj, pli malnovaj telefonoj kaj virtualaj aparatoj ofte ne havas AES-akcelon, kaj tie la diferenco estas granda. Do la komparo ne temas pri tio, kiu ĉifro estas pli rapida, sed pri tio, kiu ĉifro bone funkcias sur ĉi tiu aro de finpunktoj, kaj ĉu la protokolo entute proponas elekton.

Sama tasko, malsamaj kernoj

Ambaŭ konstruaĵoj donas konfidencecon kaj integrecon en unu paŝo kaj aŭtentikigas asociitajn datumojn, tial VPN-protokoloj uzas ilin por la datuma kanalo. La diferenco estas interne: AES-GCM estas la bloka ĉifro AES en kalkulila reĝimo kun polinoma aŭtentikigilo super GF(2^128), dum ChaCha20-Poly1305 estas fluĉifro kun 256-bita ŝlosilo kaj aparta unufoja aŭtentikigilo.

Tio, kio gravas operacie, estas komuna: ambaŭ fiaskas katastrofe ĉe reuzo de nonce, ambaŭ bezonas administradon de nonce-spaco por ĉiu ŝlosilo, kaj neniu riparas partneron, kiu aŭtentikigas la malĝustan aferon. Profilo, kiu diras AES-256-GCM, ne estas pli sekura ol unu, kiu diras CHACHA20-POLY1305; ambaŭ estas fortaj kiam la efektivigo estas ĝusta.

Kie AES-GCM venkas

AES havas dediĉitajn instrukciojn sur la plej multaj modernaj CPU-oj: AES-NI sur x86, la kriptaj etendaĵoj sur ARMv8 kaj ekvivalentoj sur lastatempaj POWER- kaj RISC-V-dezajnoj. Kiam ili ĉeestas, GCM rulas plurajn blokojn paralele por cikla klaso, kaj la programara efektivigo estas sensignifa. Tio estas la ordinara kazo por serviloj, tabulkomputiloj kaj nunaj telefonoj, kaj tial la konsilo uzi AES estas prudenta defaŭlto en datena centro.

La problemo estas la kazo de dua ordo. Sen dediĉitaj instrukcioj AES en programaro estas malrapida, kaj tabelaj programaraj efektivigoj estas tiuj kun longa historio de kaŝmemor-tempaj problemoj. VPN-koncentrilo en virtuala maŝino, kies gastiganto ne montras AES-flagojn al la gasto, estas ĝuste ĉi tiu kazo, kaj ĝi facile mankas ĉar la gastiganta CPU havas la trajton.

Kontrolu, kion la procezo vere vidas, ne kion la CPU subtenas: grep -o aes /proc/cpuinfo | head -1 sur Linux, aŭ la ekvivalentan trajtan flagon en la CPU-modelo de la hipervizoro.

Kie ChaCha20-Poly1305 venkas

ChaCha20 estas rapida en portebla programaro ĉar ĝi uzas nur adicion, rotacion kaj XOR, kaj ĝiaj efektivigoj evitas laŭdezajne sekret-dependajn tabelserĉojn. Sur aparato sen AES-akcelo tio estas materia avantaĝo, kaj tial WireGuard elektis ĝin: la priskribo de la protokolo WireGuard listigas ChaCha20-Poly1305 kiel sian datuman ĉifron sen alternativo.

Tiu unu elekto diras ion utilan: sur aparataro, kie AES estas akcelita, WireGuard cedas iom da trairo kompare kun AES-GCM, kaj ĝiaj aŭtoroj akceptis tion kontraŭ antaŭvidebla konduto sur telefonoj, hejmaj enkursigiloj kaj ujaj gastigantoj. Se via floto estas plejparte malgrandaj ARM-skatoloj, tiu interŝanĝo favoras vin.

La kontraŭa kazo estas okupata koncentrilo x86, kie AES-GCM kun AES-NI estas la pli rapida kaj pli bone subtenata vojo, kaj kie ChaCha20 kostas mezureblan CPU por gigabito. Neniu el la du konstruaĵoj estas malforteco; la demando estas, kiun via aparataro plenumas malmultekoste.

Kion via protokolo efektive permesas al vi elekti

Rimarku la dividon en OpenVPN: la rega kanalo kaj la datuma kanalo estas interkonsentataj aparte, do la aro, kiun vi vidas por TLS, diras nenion pri la ĉifro, kiu protektas vian ŝarĝon. La kunfina resumo raportas ambaŭ, kaj legi nur unu el la du estas ofta fonto de konfuzo.

En OpenVPN la ĉifro de la datuma kanalo venas el la listo data-ciphers ĉe ambaŭ flankoj. Se la listo de la servilo kaj tiu de la kliento ne intersekciĝas, la konekto aŭ retropaŝas al tio, kion permesas data-ciphers-fallback, aŭ tute fiaskas, kaj tiu fiasko kutime estas riproĉata al la malĝusta tavolo. Metu la saman liston ĉe ambaŭ flankoj, poste konfirmu la interkonsentitan rezulton en la protokolo anstataŭ supozi, ke la ordo de la listo estis respektita.

Decidu laŭ tri faktoj pri la starigo

Unue, ĉu la finpunktoj havas AES-akcelon? Se ĉiu partnero havas ĝin, AES-GCM estas la pli malmultekosta elekto kaj la defaŭlto en la plej multaj prizorgataj agordoj. Se signifa parto estas malgrandaj enkursigiloj aŭ pli malnovaj telefonoj, ChaCha20-Poly1305 malhelpas, ke la vosto de la floto fariĝu la kapacitlimo.

Due, ĉu la protokolo entute proponas elekton? Ĉe WireGuard la decido estas farita por vi, kaj la utila laboro estas kontroli, ke la iloj ĉirkaŭ ĝi ne anstataŭigas ion alian silente. Ĉe OpenVPN kaj IPsec la respondo estas agorda linio kaj interkonsentita rezulto registrenda.

Trie, ĉu ambaŭ flankoj povas interkonsenti? Ĉifro, kiun unu partnero ne efektivigas, ne estas decido pri rendimento, ĝi estas interrompo. Tial la partnera listo gravas pli ol iu ajn mezurilo: miksita floto bezonas la komunan aron de kapabloj, ne la preferon de la plej rapida maŝino.

Se vi mezuras, tenu la aparaton, la finpunkton kaj la ŝarĝon identaj kaj ŝanĝu unu aferon. Testo, kiu komparas du servilojn en malsamaj regionoj, mezuras la vojon, ne la ĉifron, kaj mezurilo sur tekkomputilo diras nenion pri uja gastiganto, kies CPU-flagoj estas maskitaj. Komparu, poste notu, kiu ĉifro efektive estis interkonsentita: tiu registro valoras pli ol la mezurilo.