AES-256 vs ChaCha20 nel 2026: quale cifratura è più veloce e sicura per VPN su PC e smartphone?

Introduzione: perché confrontare AES-256 e ChaCha20 per VPN

Contesto 2026: velocità, privacy e realtà delle nostre reti

Viviamo in un’epoca in cui la VPN non è più solo una “cosa per informatici”, ma uno strumento quotidiano. Laptop da lavoro, router domestici, smartphone, tablet e persino console — tutti hanno un problema comune: come ottenere la massima velocità e stabilità senza sacrificare la sicurezza. Nel 2026, con abbonamenti domestici da 1–2 Gbit/s ormai comuni e reti 5G e Wi‑Fi 6/7 che arrivano a velocità altissime, i colli di bottiglia spesso non sono nel provider o nel router, ma nella cifratura. Quindi la domanda “AES-256 vs ChaCha20 — quale è meglio per VPN?” non è accademica, ma assolutamente pratica. Metteremo a confronto i due algoritmi leader basandoci su trend attuali, prestazioni reali su PC e smartphone, consumo energetico, accelerazioni hardware e, naturalmente, sulle sfumature dei protocolli VPN — WireGuard, OpenVPN, IKEv2/IPsec. Alla fine, avrai consigli chiari e senza fronzoli.

Dove si inseriscono esattamente gli algoritmi criptografici nello stack VPN

Vale la pena ricordare dove “vivono” questi algoritmi. AES-256 si trova spesso in modalità AES-GCM o AES-CBC (nelle configurazioni più moderne, proprio AES-GCM come moderno metodo AEAD con autenticazione). ChaCha20 è quasi sempre abbinato a Poly1305 — formando ChaCha20-Poly1305, anch’esso AEAD. In TLS 1.3 per HTTPS e QUIC (HTTP/3) sono standard entrambi i set di cifrature — AES-GCM e ChaCha20-Poly1305; in OpenVPN entrambe le opzioni sono disponibili; in IKEv2/IPsec domina AES-GCM, ma il supporto a ChaCha20-Poly1305 c’è ed è in fase di discussione più ampia. WireGuard, invece, usa esclusivamente ChaCha20-Poly1305: non c’è scelta da fare, ed è parte della sua velocità e semplicità. Di qui la pratica conseguenza: se usi WireGuard — sei praticamente su ChaCha20; se usi OpenVPN o IKEv2/IPsec — puoi scegliere e questo incide sul risultato.

Block cipher vs stream cipher: differenze di “filosofia”

AES è un cifrario a blocchi. Opera su blocchi da 128 bit, e la modalità di cifratura (GCM, CBC ecc.) determina come i blocchi si collegano e come si garantisce l’autenticazione. ChaCha20 è un cifrario a flusso della famiglia ARX (add-rotate-xor) che genera un flusso pseudocasuale da combinare con i dati. Cosa significa in pratica? Talvolta un guadagno significativo in velocità su processori senza AES hardware, più resistenza a certi attacchi a canali laterali. AES-256 ha un asso nella manica — istruzioni hardware (AES-NI su x86, Crypto Extensions su ARMv8) che trasformano la matematica complessa in microistruzioni velocissime. Perciò su desktop e server moderni AES-256-GCM spesso vola più veloce di ChaCha20, mentre su mobile e router economici succede il contrario. Non magia, solo ingegneria ragionata.

Origini e standard: a chi fidarsi e cosa seguire

AES-256: orgoglio della standardizzazione e scelta corporate

AES è stato scelto da NIST come standard (FIPS-197) già nei primi anni 2000, ottenendo poi ampio supporto nell’industria e nel settore pubblico. AES-256 ha una lunga storia di audit, certificazioni e applicazioni pratiche. Nel 2026 la maggior parte delle normative sono orientate ad AES, specialmente nel contesto FIPS 140-3: moduli crittografici certificati AES-GCM sono diffusi e ben supportati. Non sono solo formalità: certificazioni di questo tipo aprono le porte a gare importanti, infrastrutture bancarie e settore pubblico. È vero, AES-256 è teoricamente più pesante di AES-128, ma sui moderni CPU con AES-NI la differenza di velocità è spesso minima e i rischi organizzativi inferiori. Per una VPN aziendale è un argomento decisivo e non lo nascondiamo.

ChaCha20-Poly1305: classico moderno nato per la velocità

ChaCha20 deriva da Salsa20, migliorato da Daniel Bernstein e adottato dall'IETF per TLS e IPsec (ad esempio RFC 7539 per il contesto TLS). L’idea principale è velocità brillante e facilità di implementazione su dispositivi senza AES hardware. È per questo che Google ha spinto massicciamente ChaCha20-Poly1305 in Chrome mobile, e WireGuard lo ha fatto suo nucleo. Oggi lo vediamo ovunque — dai SoC mobili a single board computer e router con OpenWrt; ambienti container e cloud lo apprezzano per prestazioni prevedibili in CPU virtualizzate senza AES-NI pieno. Siamo sinceri: nel 2026 ChaCha20 non è più “un’alternativa”, ma è di fatto uno standard in ogni moderno stack VPN che punta a semplicità e velocità.

Compliance e normative: dove c’è la strada dritta e dove la sfida

Se lavori sotto normative rigide — settore bancario, enti pubblici, infrastrutture critiche — AES-GCM è quasi sempre l’unica opzione “totalmente verde”. Ci sono implementazioni ChaCha20-Poly1305 passate da audit interni e in alcune giurisdizioni è accettato senza problemi. Ma un modulo FIPS con AES è il percorso più breve per la produzione. Cosa fare? Consiglio pratico: se la compliance è prioritaria, scegli AES-256-GCM (o AES-128-GCM se serve velocità maggiore ma sicurezza ancora buona); se sei una startup, SaaS, media service o sviluppatore senza normative strette — ChaCha20-Poly1305 regala velocità e semplicità, specialmente su mobile e container. Idealmente supporta entrambi e scegli dinamicamente.

Prestazioni: chi è più veloce e in quali scenari

Desktop e server x86/x64: la forza di AES-NI e alte frequenze

Su processori Intel e AMD moderni con AES-NI AES-256-GCM mostra velocità molto elevate. In OpenVPN con configurazione corretta e multithreading si raggiungono facilmente gigabit per core. In IKEv2/IPsec con moduli kernel attivi e, se presenti, offload sulle schede di rete, si toccano 1–10 Gbit/s senza caricare troppo la CPU. ChaCha20-Poly1305 in WireGuard è molto performante e raggiunge spesso 1–5 Gbit/s su sistemi multithread, ma su x86 con forte AES-NI AES-GCM spesso vince a parità di condizioni. Eccezioni? Sì. In ambienti fortemente virtualizzati senza pieno accesso alle istruzioni AES o con frequenze ridotte, ChaCha20 può spiccare perché la sua implementazione è ottimale e prevedibile. Ma su hardware nudo e crudo AES-NI è una bestia.

ARM e SoC mobili: ChaCha20 spesso davanti, ma non sempre

Su smartphone e tablet privi di accelerazione AES hardware o con driver scarsi ChaCha20-Poly1305 batte sistematicamente AES-GCM. Minore latenza, minore riscaldamento, velocità stabile con radio 5G instabile. Però da ARMv8 Crypto Extensions in poi molto cambia: molti chip 2021–2026 hanno buon acceleratore AES. In questi casi AES-GCM su mobile raggiunge ChaCha20 e a volte lo supera in sessioni brevi. Vediamo 400–900 Mbit/s in WireGuard sui flagship e 200–500 Mbit/s in OpenVPN con AES-GCM configurato bene. Conclusione: su Android di fascia media ChaCha20 è spesso più veloce, su flagship la differenza si azzera, su dispositivi economici o vecchi ChaCha20 quasi sempre domina.

Router, single board e IoT: colli di bottiglia e miracoli di ottimizzazione

Router con OpenWrt e single board ARM sono spesso terreno di sfida tra AES e ChaCha. Se il tuo chip ha un acceleratore hardware AES (es. Qualcomm, Broadcom, Marvell) AES-GCM può volare a centinaia di Mbit liberando CPU per routing e firewall. Se l'accelerazione manca, ChaCha20 spesso vince: il cifrario a flusso ARX si adatta bene a NEON e alla cache. In IoT, dove ogni milliwatt conta, ChaCha20 è un fedele alleato. Attenzione però ai driver: a volte un acceleratore “perfetto sulla carta” in Linux è inaccessibile per limiti software, lasciando ChaCha20-Poly1305 campione pratico anche se si voleva AES.

Sicurezza: la teoria è forte, ma la pratica conta di più

Robustezza crittografica: entrambi gli algoritmi sono affidabili

Sia AES-256-GCM che ChaCha20-Poly1305 sono considerati costrutti AEAD moderni e affidabili. A livello di brute-force sono inespugnabili. La differenza nei rischi sta nelle implementazioni e nei dettagli attorno alla cifratura. GCM è molto sensibile alla riutilizzazione del nonce: un solo riutilizzo compromette confidenzialità e integrità. Anche ChaCha20-Poly1305 richiede nonce unici, ma gli errori sono meno comuni per la semplicità del codice e l’assenza di tabelle di sostituzione. Nel 2026 entrambi restano standard d’oro. Non scegliere algoritmi in base a miti, ma in base all’ambiente: hardware, protocollo, driver, processo DevOps. Gli errori DevOps sono più probabili della fantomatica supercomputer degli hacker.

Canali laterali: timing e cache

Storicamente gli attacchi timing e cache colpivano più spesso implementazioni AES software con S-Box, soprattutto su dispositivi senza AES-NI. AES-NI hardware risolve gran parte dei problemi, rendendo le operazioni costanti nel tempo. ChaCha20 è naturalmente più vicino a tempo costante grazie alle operazioni add-rotate-xor, senza tabelle né branch. Da qui la reputazione di “più sicuro su dispositivi economici e datati”. Ma diciamo la verità: le librerie di qualità nel 2026 (BoringSSL, OpenSSL 3.x, libsodium) tengono molto conto di questo e con build corrette entrambi sono sicuri. I veri rischi sono perdite di chiavi in RAM, bug di RNG, log di segreti, gestione energia instabile. Qui la colpa non è dell’algoritmo, ma dell’assemblaggio e gestione.

Modalità AEAD e errori comuni di configurazione

Scegli sempre AEAD: AES-GCM o ChaCha20-Poly1305. Evita vecchie configurazioni tipo AES-CBC+HMAC per nuovi deploy senza motivo speciale. Assicurati unicità del nonce, genera chiavi correttamente, non risparmiare entropia. In OpenVPN e IKEv2 usa suite moderne; in WireGuard sei limitato a ChaCha20-Poly1305 — e va bene così, meno tentazioni di errori di configurazione. Dettaglio importante: la lunghezza della chiave — AES-128-GCM è spesso sufficiente e più veloce di AES-256-GCM, ma se la policy impone “256 o niente”, usa 256. ChaCha20 è già a 256 bit, quindi molta semplicità. L’errore più grande? Cercare di “migliorare” default sicuri con esotismi.

Consumo energetico e calore: particolarmente rilevante sul mobile

La batteria premia l’efficienza, non la marca della cifratura

Su smartphone o laptop in carico la crittografia pesa. Differenze del 10–20% di CPU possono far guadagnare ore in mobilità. ChaCha20 spesso vince su dispositivi senza buona accelerazione AES: meno riscaldamento, frequenza più stabile, velocità costante. Ma su ARMv8 moderno con accelerazione hardware la differenza svanisce: AES-GCM può essere anche più efficiente, riconducendo il carico a blocchi dedicati SoC. Qui vale un semplice pensiero: non litigate su dogmi, testate il vostro telefono. Dieci minuti di iperf3 tramite il vostro server VPN e vedrete chi consuma meno batteria. La pratica batte i dogmi meglio di ogni articolo, questo compreso.

Throttle e velocità stabile a lungo termine

Sessione breve è una cosa, streaming due ore è un’altra. Se la cifratura scalda il chip, il sistema abbassa le frequenze (throttling) e dopo 20–30 minuti la velocità scende da 800 a 300 Mbit/s. ChaCha20 di solito scalda meno su device medi e mantiene la velocità stabile più a lungo. Su flagship con buon raffreddamento e forte accelerazione AES la situazione è equilibrata. Trick: riduci carico CPU a livello protocollo — scegli WireGuard invece di OpenVPN, usa MTU autotuning, monitorizza roaming cellulare, applica keepalive con giudizio. Questo smussa i picchi e aiuta la batteria.

5G, Wi‑Fi 6/7 e crittografia: chi sta al passo con la radio

Le reti vanno più veloci. La capacità del canale radio cresce e la cifratura diventa il nuovo collo di bottiglia. Con segnale stabile 5G raggiungerai facilmente il limite della cifratura. Su x86 con AES-NI AES-GCM mantiene gigabit e oltre senza affanno, mentre ChaCha20 in WireGuard su smartphone potente raggiunge centinaia di Mbit, più che sufficienti per lo streaming. Wi‑Fi 6/7 riduce latenza, aumenta pacchetti — sono quindi utili parallelizzazione (forza di GCM) e assenza di blocchi in kernel (forza di WireGuard). Ricetta finale: non guardare solo all’algoritmo, pensa al mix «protocollo + hardware + driver + rete».

Accelerazione hardware e dettagli low-level

AES-NI, ARMv8 Crypto Extensions, NEON: quando AES diventa “turbo”

Su x86 AES-NI è magia: ogni fase di AES è un’istruzione, velocità spaziale, canali laterali ridotti. Su ARMv8 ci sono Crypto Extensions: accelerazione hardware AES e SHA usate da Android, iOS e ARM server. AES-GCM ne esce con un boost enorme ed è “di default veloce”. NEON aiuta sia AES che ChaCha, ma AES vince di più se ci sono Crypto Extensions. Per noi significa tattica semplice: se la CPU supporta istruzioni AES e il software le usa, AES-256-GCM è spesso il leader. Verifica facilmente: openssl speed, iperf3 su VPN e vedi la differenza.

ChaCha20 e SIMD: velocità senza AES hardware

ChaCha20 non ha istruzioni hardware universali come AES-NI, ma si vettorizza bene con NEON, AVX2, AVX-512. Implementazioni in BoringSSL, OpenSSL, libsodium dal 2024 al 2026 hanno spremuto SIMD al massimo: su ARM medio ChaCha20 può facilmente battere AES-GCM, idem su x86 senza AES-NI. Bonus: carico CPU uniforme senza picchi, utile per virtualizzazione e container. ChaCha20-Poly1305 è anche molto più semplice da mantenere “a tempo costante”, facilitando audit. Da qui la sua popolarità in app dove conta prevedibilità.

Schede di rete, offload, IPsec e motori TLS

In ambito enterprise contano offload e kernel. Alcune NIC sanno scaricare AES-GCM per IPsec e TLS — e allora si entra in 10–100 Gbit/s. Offload ChaCha20 è raro, quindi su collegamenti ultraveloci AES è la scelta ovvia. In Linux lo stack XFRM per IPsec è maturo e OpenSSL 3.x sa gestire i crypto-engines. Qui AES vince non perché ChaCha20 sia debole, ma perché l’hardware è ottimizzato per AES. Se costruisci tunnel ufficio-DC >10 Gbit/s probabilmente sceglierai AES-GCM quasi sempre.

Test pratici e casi 2026: da PC a router

Desktop e laptop con AES-NI: numeri alla mano

Caso: Ryzen 5 con AES-NI, Linux 6.x, OpenVPN e WireGuard. In OpenVPN con AES-256-GCM si toccano 1,2–1,6 Gbit/s su core singolo, più con multithread; con ChaCha20-Poly1305 0,9–1,4 Gbit/s. In IKEv2/IPsec con moduli kernel attivi 3–5 Gbit/s. WireGuard (ChaCha20) 1,5–3 Gbit/s, a volte di più su kernel recenti e MTU ottimizzato. Carico CPU minore su AES, ventole più silenziose. Conclusione: su desktop con AES-NI scegli AES-GCM se usi OpenVPN/IPsec; se preferisci WireGuard resta tranquillo, ChaCha20 offre ottima velocità e configurazione più semplice. La comodità di WireGuard spesso compensa qualche centinaio di Mbit di differenza.

Smartphone di fascia media: vita reale, non benchmark

Caso: smartphone Android 2023–2025 senza Crypto Extensions potenti. WireGuard (ChaCha20) regala 300–600 Mbit/s stabili, con riscaldamento moderato e consumo batteria prevedibile. OpenVPN con AES-256-GCM arriva a 150–350 Mbit/s, a volte recupera se il produttore ha abilitato AES hardware. Sul flagship 2025–2026 con ARMv8 Crypto Extensions OpenVPN AES-GCM si eguaglia o perde del 10–20% rispetto a WireGuard, dipende da radio e frequenze. Per streaming e cloud gaming non conta solo la velocità di picco, ma la stabilità sotto roaming. WireGuard con ChaCha20 spesso è più amichevole: tunnel più rapido, migliore gestione del cambio IP, meno scatti.

Router con OpenWrt: acceleratori determinano il destino

Caso: router domestico ARM SoC senza AES hardware. OpenVPN AES-GCM viaggia a 60–120 Mbit/s, occasionalmente 150. ChaCha20-Poly1305 120–250 Mbit/s con build e flow offload ottimali. Se il chip ha AES hardware e driver aggiornati il risultato cambia: AES-GCM 300–600 Mbit/s, ChaCha20 200–400. In IKEv2/IPsec può salire ancora grazie al kernel. Consiglio semplice: verifica cosa supporta il tuo SoC (modello + “crypto engine”) e se il driver è presente in OpenWrt. L’implementazione conta più dei loghi sulla scatola. Driver valido fa re AES, la sua assenza incorona ChaCha20.

Protocolli VPN: WireGuard, OpenVPN, IKEv2/IPsec e scelte

WireGuard: ChaCha20 di default e velocità out-of-the-box

WireGuard è minimalismo, kernel, crittografia statica e ChaCha20-Poly1305 come unica cifratura per dati. Non scegli tra AES e ChaCha, hai uno stack ottimizzato per semplicità e sicurezza. Nel 2026 WireGuard è maturo, logger e key manager sono comuni, i provider lo scelgono come default. Il punto chiave è settare bene MTU, abilitare roaming e tenere controllo dell’orologio su dispositivi. Se hai client mobili e cerchi semplicità, WireGuard è quasi sempre un’ottima scelta. Eccelle con ChaCha20 proprio dove serve: reti mobili instabili e CPU modeste.

OpenVPN: flessibilità ma più pesante in CPU

OpenVPN supporta AES-GCM, ChaCha20-Poly1305 e molte altre varianti. Pro e contro. Pro: configurazione personalizzata su hardware e compliance. Contro: si può sbagliare e montare la peggior combinazione. Nel 2026 default corretto è: AES-256-GCM su x86 con AES-NI; ChaCha20-Poly1305 su ARM debole senza AES; libc e crypto library affidabili, multithreading, finestre ragionevoli. Usa UDP o QUIC, evita TCP per scalabilità. OpenVPN storicamente è più oneroso di WireGuard: su mobile perde spesso, ma su server potente con AES-NI brilla.

IKEv2/IPsec: oro corporate per bilanciamento

Forza di IKEv2/IPsec: maturità, offload hardware, supporto su router, firewall e cloud VPC. AES-GCM è naturale qui, quindi spesso la scelta migliore per 1–10 Gbit/s. ChaCha20-Poly1305 possibile ma supporto hardware raro, quindi casi pratici meno frequenti. Per tunnel L2L, data center e collegamenti interregionali AES-GCM con IKEv2/IPsec è meno soggetto a sorprese. Per mobile IKEv2 con EAP è popolare, ma offre roaming inferiori a WireGuard. Ecco perché di solito si usa un blend: IKEv2 per backbone e filiali, WireGuard per dipendenti e device.

Raccomandazioni chiare: come scegliere la cifratura adatta

Se hai desktop o server con AES-NI

Scegli AES-256-GCM su OpenVPN o IKEv2/IPsec — percorso più veloce ed efficiente, specialmente con gigabit. Se usi WireGuard, nessun problema: ChaCha20 offre velocità fantastica e facilità di gestione, il vantaggio AES-NI spesso non è critico. Per compliance AES è praticamente imprescindibile.

Se usi smartphone e tablet

Su flagship 2025–2026 con ARMv8 Crypto Extensions la differenza tra AES-GCM e ChaCha20-Poly1305 è minima. Su modelli medi o più datati ChaCha20 è di solito più efficiente e veloce. Percorso ottimale: WireGuard con ChaCha20 per mobile, sopporta bene roaming, radio instabile, sleep mode. Se serve OpenVPN, testa entrambi e scegli in base al carico CPU con iperf3.

Se usi router o single board

Guarda l’hardware. Se hai accelerazione AES con driver, vai su AES-GCM. Se no, ChaCha20-Poly1305 è la scelta. Per tunnel L2L e datacenter usa IKEv2/IPsec con AES-GCM e offload NIC se possibile. Per dispositivi domestici con CPU limitata WireGuard su ChaCha20 spesso offre latenza miglior e velocità stabile.

Errori comuni e miti: per evitare brutte sorprese

Principali errori di configurazione

Errore frequente: ignorare MTU e MSS — frammentazione uccide velocità e crea problemi “fantasma”. Secondo: mantenere suite vecchie tipo AES-CBC senza motivo. Terzo: non controllare capacità CPU — ti stupirai di quanto AES-NI velocizzi traffico reale. Quarto: dimenticare nonce unici e RNG di qualità. Quinto: testare in rete “vuota” e poi stupirsi del calo in carico reale. Ricetta: testa vari scenari, usa iperf3, bpftrace, profila CPU. E sì, aggiorna firmware e kernel — i driver evolvono velocemente.

Miti da tramandare al passato

“AES-256 è sempre più lento di AES-128” — falso, con AES-NI la differenza è spesso minima o annullata da task di background. “ChaCha20 è insicuro perché nuovo” — vecchio cliché, è stato ampiamente auditato e utilizzato sul campo da anni. “WireGuard è meno sicuro perché meno opzioni” — al contrario, meno opzioni significa meno errori. “Su mobile ChaCha20 è sempre meglio” — spesso sì, ma su ARMv8 con buon AES può esserci equilibrio o vantaggio AES-GCM. “Devo puntare a 2 Gbit/s subito” — no, su mobile spesso più importante è stabilità da 300–600 Mbit/s che un gigabit che cala dopo 20 minuti di throttling.

Ottimizzazioni e checklist prima del deploy

Checklist veloce prima di partire

• Definisci priorità: velocità, batteria, compliance, semplicità di gestione.
• Controlla flag CPU: AES-NI su x86, Crypto Extensions su ARMv8.
• Su mobile WireGuard con ChaCha20, per backbone IKEv2/IPsec con AES-GCM.
• Configura MTU/MSS, attiva roaming dove serve, monitorare timer NAT.
• Testa con iperf3 e diverse dimensioni di finestra, confronta CPU e riscaldamento.
• Aggiorna kernel, OpenSSL/BoringSSL, OpenVPN/strongSwan, WireGuard-tools.

Questa lista sembra semplice ma risolve l’80% dei problemi. Seriamente, a volte un singolo flag CPU cambia tutta la scelta degli algoritmi.

Trucchi pratici per massima velocità

• Su x86 con AES-NI usa AES-256-GCM e kernel-acceleration se possibile.
• Su ARM senza accelerazione AES abilita ChaCha20-Poly1305, disabilita servizi inutili su router.
• Per OpenVPN passa a UDP, abilita multithreading, usa stack crypto moderno.
• Per WireGuard MTU corretto, PersistentKeepalive per NAT, log attento solo a metadati senza segreti.
• In cloud verifica flag CPU virtuali e politica hypervisor su AES.

Sembrano noiosi, ma portano reali miglioramenti percentuali e a volte raddoppiano le prestazioni.

Verdetti rapidi per scenari tipici

• PC/server con AES-NI: spesso AES-256-GCM è scelta migliore.
• Smartphone medio: ChaCha20-Poly1305 in WireGuard.
• Flagship 2026: parità; scegli in base al protocollo preferito.
• Router senza accelerazione AES: ChaCha20.
• Router con accelerazione AES: AES-GCM.
• Backbone corporate >1 Gbit/s: IKEv2/IPsec + AES-GCM, offload se possibile.

Chiaro e concreto. Sempre verifica sul tuo hardware — le sorprese non mancano.

Futuro e trend 2026: dove va l’industria

Unificazione su AEAD e minimalismo di configurazione

Trend verso default più severi: AES-GCM e ChaCha20-Poly1305 come base, tutto il resto opzionale o per casi speciali. WireGuard ha consolidato la cultura “meno opzioni, meno errori”. Config OpenVPN e IPsec si accorciano, vecchie modalità scompaiono. Nel 2026 è la tendenza numero uno: default sicuri senza magie.

Crescita dell’AES hardware e tentativi di accelerare ChaCha

I produttori continueranno a inserire blocchi AES e SHA nei SoC, specialmente mobile. ChaCha20 resterà favorito dove AES non c’è o è limitato. Si vedono esperimenti di accelerazione vettoriale di ChaCha via AVX-512 e NEON migliorato, con primi incrementi visibili. Ma un “ChaCha-NI” non arriverà presto, quindi su link multi-gigabit AES manterrà vantaggio hardware netto.

Container, cloud e QUIC

Applicazioni sempre più dietro proxy inversi e tunnel QUIC. La scelta tra AES-GCM e ChaCha20-Poly1305 a livello TLS 1.3 può essere gestita dallo stack bilanciando CPU. Nei container la prevedibilità di ChaCha20 a volte vale più dei giga teorici AES, se l’hypervisor limita istruzioni. Il trend è chiaro: auto-selezione crittografia basata su hardware, meno configurazione manuale, più telemetria.

Conclusioni: risposta breve a una grande domanda

Punto chiave in un paragrafo

Su x86 con AES-NI scegli AES-256-GCM per massimo velocità e compliance; su mobile e ARM deboli ChaCha20-Poly1305 spesso garantisce stabilità, minor calore e più batteria; per WireGuard la questione è chiusa — ChaCha20 è di default; per IKEv2/IPsec e alte velocità AES-GCM è il leader oggettivo, soprattutto con offload. E sì, testa sempre sul tuo hardware — non è un cliché, è risparmio di tempo e nervi.

Cosa installare ora stesso

• PC/laptop domestico: OpenVPN/IKEv2 con AES-256-GCM o WireGuard (ChaCha20) per semplicità.
• Smartphone: WireGuard (ChaCha20); se serve OpenVPN, prova entrambi e scegli basandoti su dati reali.
• Router: se hai accelerazione AES, usa AES-GCM; altrimenti ChaCha20; per L2L usa IKEv2/IPsec.
• Cloud/VPS: se accesso AES limitato, usa ChaCha20 in WireGuard; altrimenti AES-GCM con IKEv2/IPsec.

Non è un dogma. Ma un ottimo punto di partenza.

Cosa non fare mai

• Non abilitare vecchie modalità solo per “compatibilità” senza reale necessità.
• Non ignorare MTU e MSS — sono ottimizzazioni gratuite.
• Non dimenticare di aggiornare kernel, driver e librerie crypto.
• Non basare scelte su voci — fai qualche test e osserva CPU e batteria.

Lasciamo i miti inutili al passato, il loro posto è lì.

FAQ: risposte rapide alle domande più comuni

È vero che AES-256 è sempre più sicuro di AES-128 e vale la pena pagare in velocità?

AES-256 è teoricamente più robusto e copre alcune classi di attacchi “futuri”, ma in pratica AES-128-GCM offre già oggi un’enorme sicurezza e spesso è più veloce. In politica aziendale “256 o niente” è scelta di compliance e uniformità, non dialettica di rottura. Se corsi dietro massima velocità e non hai il vincolo “solo 256”, AES-128-GCM è scelta razionale. Se hai velocità sufficiente e vuoi “con margine”, AES-256-GCM gira bene su hardware moderno con AES-NI senza grosse perdite.

Perché ChaCha20-Poly1305 è migliore su mobile e dispositivi deboli?

ChaCha20 è un cipher a flusso ARX: niente tabelle, poche branch, si adatta bene a SIMD. Questo dà velocità prevedibile su CPU senza AES hardware e riduce rischio di canali laterali da cattive implementazioni. Realtà pratica: meno calore, velocità stabile in sessioni lunghe, risparmio batteria. Inoltre WireGuard ha standardizzato ChaCha20, quindi su mobile è “di serie” con roaming e NAT. Conclusione: su smartphone medi e vecchi ChaCha20 spesso vince, su flagship è pari ad AES-GCM.

Posso abilitare AES-256 in WireGuard invece di ChaCha20?

Risposta breve: no, WireGuard usa esclusivamente ChaCha20-Poly1305, è parte del suo design. Esistono versioni sperimentali e patch, ma non adottate in produzione né supportate dalla community ampia. Questo è positivo: minimalismo WireGuard riduce errori di configurazione, accelera audit e semplifica il supporto mobile. Se ti serve AES per compliance, guarda IKEv2/IPsec o OpenVPN con AES-GCM e accelerazione hardware.

Cosa scegliere per ufficio 1–10 Gbit/s: WireGuard o IKEv2/IPsec?

Per tunnel L2L, canali inter-ufficio e backbone 1–10 Gbit/s spesso vince IKEv2/IPsec con AES-GCM, specie con offload hardware NIC e stack XFRM maturo in Linux. WireGuard offre ottime velocità su CPU potenti, ma IPsec ha più opzioni di integrazione hardware, QoS e monitoraggio, con anni di test. Per dipendenti remoti WireGuard è più comodo: meno latenza, roaming migliore, client più gradevoli.

Se voglio solo velocità su PC cosa uso?

Su x86 con AES-NI spesso AES-256-GCM in OpenVPN o IKEv2/IPsec è più veloce, con gigabit se ben configurato. Ma non sottovalutare WireGuard: ChaCha20 offre numeri quasi pari e configurazione semplicissima è un grande vantaggio. Il vero modo per non sbagliare è fare 2–3 test con iperf3 e valutare anche stabilità sotto carico e riscaldamento. Spesso la comodità WireGuard pesa più di qualche centinaio di Mbit teorici AES.

E se ho router vecchio o single board economico?

Se il dispositivo non ha AES hardware o driver adeguati, scegli ChaCha20-Poly1305. Cipher a flusso su NEON può raddoppiare prestazioni rispetto AES senza accelerazione. Se SoC ha Crypto Engine AES e OpenWrt lo supporta, opta per AES-GCM. Verifica il modello specifico: qualche aggiornamento firmware può attivare AES offload e moltiplicare la velocità.

Ha senso aspettarsi un “ChaCha20 hardware” come AES-NI?

Nei prossimi anni improbabile. I produttori puntano su AES e SHA, pilastri del settore: IPsec, TLS, standard aziendali e offload NIC. Ottimizzazioni ChaCha20 continueranno via SIMD (AVX2, AVX-512, NEON), con ottime velocità. Ma una “ChaCha-NI” non è prevista. Questo significa che ChaCha20 perde? No, su mobile, container e hardware debole resta spesso la scelta migliore; su hardware con AES hardware AES-GCM ha senso ed è favorito.