AES-GCM o ChaCha20-Poly1305: scegliere il cifrario dei dati di una VPN

Entrambi i nomi sono costruzioni AEAD, entrambi sono standardizzati, e su un server x86 attuale ciascuno dei due saturerà un collegamento gigabit senza sforzo visibile. La scelta smette di essere arbitraria quando si esce da quel server: router economici, telefoni più vecchi e apparati virtuali spesso non hanno l accelerazione AES, e lì la differenza è grande. Il confronto quindi non è quale cifrario sia più veloce, ma quale cifrario funzioni bene su questo insieme di endpoint e se il protocollo offra persino una scelta.

Lo stesso lavoro, nuclei diversi

Entrambe le costruzioni danno riservatezza e integrità in una sola passata e autenticano i dati associati, ed è per questo che i protocolli VPN le usano per il canale dati. La differenza è dentro: AES-GCM è il cifrario a blocchi AES in modalità contatore con un autenticatore polinomiale su GF(2^128), mentre ChaCha20-Poly1305 è un cifrario a flusso con chiave da 256 bit e un autenticatore monouso separato.

Ciò che conta operativamente è comune: entrambi falliscono in modo catastrofico col riuso del nonce, entrambi richiedono la gestione dello spazio del nonce per chiave, e nessuno dei due ripara un peer che autentica la cosa sbagliata. Un profilo che dice AES-256-GCM non è più sicuro di uno che dice CHACHA20-POLY1305; entrambi sono solidi quando l implementazione è corretta.

Dove vince AES-GCM

AES ha istruzioni dedicate sulla maggior parte delle CPU moderne: AES-NI su x86, le estensioni crittografiche su ARMv8 e equivalenti sui progetti recenti POWER e RISC-V. Quando ci sono, GCM esegue diversi blocchi in parallelo per classe di ciclo e l implementazione software diventa irrilevante. È il caso comune di server, desktop e telefoni attuali, ed è per questo che il consiglio di usare AES è un valore predefinito ragionevole in un data center.

Il problema è il caso di secondo ordine. Senza istruzioni dedicate AES nel software è lento, e le implementazioni software guidate da tabelle sono quelle con una lunga storia di problemi di tempo di cache. Un concentratore VPN in una macchina virtuale il cui host non espone i flag AES al guest è esattamente questo caso, ed è facile trascurarlo perché la CPU dell host ha la funzione.

Verifica ciò che il processo vede davvero, non ciò che la CPU supporta: grep -o aes /proc/cpuinfo | head -1 su Linux, o il flag di funzione equivalente nel modello di CPU dell hypervisor.

Dove vince ChaCha20-Poly1305

ChaCha20 è veloce nel software portatile perché usa solo addizione, rotazione e XOR, e le sue implementazioni evitano per progettazione le ricerche in tabelle dipendenti dal segreto. Su un dispositivo senza accelerazione AES è un vantaggio materiale, ed è la ragione per cui WireGuard l ha scelto: la descrizione del protocollo WireGuard elenca ChaCha20-Poly1305 come cifrario dei dati senza alternativa.

Quella singola scelta dice qualcosa di utile: su hardware dove AES è accelerato, WireGuard cede un po di throughput rispetto ad AES-GCM, e i suoi autori l hanno accettato in cambio di un comportamento prevedibile su telefoni, router domestici e host di container. Se la tua flotta è soprattutto piccoli box ARM, quello scambio è a tuo favore.

Il caso opposto è un concentratore x86 occupato, dove AES-GCM con AES-NI è la via più veloce e meglio supportata, e dove ChaCha20 costa CPU misurabile per gigabit. Nessuna delle due costruzioni è una debolezza; la questione è quale il tuo hardware esegue a basso costo.

Cosa ti lascia scegliere davvero il tuo protocollo

Nota la separazione in OpenVPN: il canale di controllo e il canale dati sono negoziati separatamente, quindi la suite che vedi per TLS non dice nulla sul cifrario che protegge il tuo payload. Il riepilogo di sessione riporta entrambi, e leggerne solo uno dei due è una fonte comune di confusione.

In OpenVPN il cifrario del canale dati proviene dalla lista data-ciphers su entrambe le estremità. Se la lista del server e quella del client non si intersecano, la connessione o ripiega su ciò che data-ciphers-fallback consente o fallisce del tutto, e quel fallimento viene di solito attribuito allo strato sbagliato. Metti la stessa lista su entrambi i lati, poi conferma il risultato negoziato nel log invece di dare per scontato che l ordine della lista sia stato rispettato.

Decidi da tre fatti sul deployment

Primo, gli endpoint hanno l accelerazione AES? Se ce l ha ogni peer, AES-GCM è la scelta più economica e il valore predefinito nella maggior parte delle configurazioni mantenute. Se una parte significativa sono router piccoli o telefoni vecchi, ChaCha20-Poly1305 impedisce che la coda della flotta diventi il limite di capacità.

Secondo, il protocollo offre davvero una scelta? Con WireGuard la decisione è già presa per te, e il lavoro utile è verificare che gli strumenti intorno non sostituiscano in silenzio qualcos altro. Con OpenVPN e IPsec la risposta è una riga di configurazione e un risultato negoziato da registrare.

Terzo, le due estremità possono accordarsi? Un cifrario che un peer non implementa non è una decisione di prestazioni, è un interruzione. Per questo la lista dei peer conta più di qualsiasi benchmark: una flotta mista ha bisogno dell intersezione delle capacità, non della preferenza della macchina più veloce.

Se misuri, mantieni identici dispositivo, endpoint e carico e cambia una sola cosa. Un test che confronta due server in regioni diverse misura il percorso, non il cifrario, e un benchmark su portatile non dice nulla su un host di container i cui flag di CPU sono mascherati. Confronta, poi annota quale cifrario è stato davvero negoziato: quel registro vale più del benchmark.