Crittografia asimmetrica vs simmetrica nelle VPN: spiegato semplice con esempi

Diciamolo chiaro: nel mondo delle VPN gli acronimi non mancano e non sempre è tutto rose e fiori capirli. RSA, ECDH, PFS, AEAD, IKEv2, TLS 1.3, NoiseIK — un mix che può confondere, soprattutto se parti da zero e il tempo è poco. Ma non serve reinventare la crittografia. Il nostro obiettivo è capire come il tunnel VPN mescoli crittografia asimmetrica e simmetrica, perché servono entrambi i meccanismi, dove e quando appaiono le chiavi di sessione, quali parametri contano nel 2026 e cosa scegliere in pratica per una connessione veloce e sicura. Niente formule complicate: parleremo in modo diretto, con esempi da IPsec, OpenVPN e WireGuard. Spieghiamo con la logica: con l’asimmetria scambiamo segreti senza una chiave condivisa, con la simmetria cifriamo i dati in modo rapido e solido. Una combinazione semplice ma efficace. E sì, presenteremo dati di performance precisi, vedremo handshake post-quantistici ibridi e aggiungeremo un pratico checklist: cosa attivare, cosa disattivare e gli errori più comuni. Partiamo da come funziona tutto davvero nel tunnel.

Come funziona la crittografia nelle VPN nella pratica

Perché simmetria e asimmetria non sono in competizione

Il segreto di ogni protezione VPN moderna è che crittografia asimmetrica e simmetrica non si sfidano, ma si completano. Sono come frizione e motore in un’auto: uno avvia e cambia, l’altro spinge. L’asimmetria (RSA, ECDH) risolve il problema dello scambio del segreto tra parti che non hanno niente in comune all’inizio. Fa il "handshake", verifica identità, negozia parametri e genera la chiave di sessione condivisa. E tutto ciò senza rischiare di urlare la password in pubblico. La simmetria (AES, ChaCha20) prende il testimone dopo l’handshake per cifrare la maggior parte del traffico in modo veloce e leggero.

Perché così? Perché le operazioni asimmetriche sono pesanti e usarle troppo costerebbe in CPU e ritardi. Le simmetriche sono leggere e rapide, soprattutto con AEAD come AES-GCM e ChaCha20-Poly1305. Lo schema è chiaro: un breve handshake asimmetrico per scambiare chiavi di sessione più una lunga cifratura simmetrica dei dati. Il risultato? Alte prestazioni, resistenza all’intercettazione e un elegante equilibrio tra sicurezza e velocità. Non risparmiamo solo risorse, ma otteniamo proprietà importanti come la segretezza diretta (PFS), così se una chiave a lungo termine viene compromessa non si «sblocca» il passato.

Cosa sono le chiavi di sessione e perché servono

La chiave di sessione è un segreto usa e getta per una connessione specifica. Nasce durante l’handshake (tramite ECDH o meccanismi simili), dura per la sessione e muore alla fine o al suo rinnovo (rekey). Grazie a queste chiavi la VPN garantisce che, anche se qualcuno rubasse la chiave a lungo termine (ad esempio quella privata del server), non potrà decrittare retroattivamente il traffico passato. Questo è l’esempio pratico di Perfect Forward Secrecy — segretezza diretta in azione.

La chiave di sessione non è un singolo valore, ma un insieme di materiali: chiavi per cifratura e autenticazione in entrambe le direzioni, a volte più chiavi per livelli diversi (in IPsec: IKE SA e Child SA), più contatori, "sale" (salt) e dettagli vari necessari alla crittografia. La durata è limitata: per tempo (ad esempio 60 minuti), per quantità di dati (1–4 GB) o entrambi. Così si minimizza il rischio che analisi statistiche dei cifrari diano indizi agli attaccanti. E poi è comodo — se qualcosa va storto, si rigenerano le chiavi e si continua.

Dove vivono le chiavi e come spariscono

Le chiavi stanno in memoria del processo VPN e nei moduli crittografici del kernel o nelle schede di rete se disponibili funzioni di offload. Non devono mai finire su disco in chiaro, e anche i dump di memoria in produzione sono da evitare. Una buona pratica è proteggere le chiavi private server con HSM o TPM, e tenere quelle di sessione strettamente in RAM con cancellazione sicura alla chiusura. E soprattutto niente copie nei log: non è uno scherzo.

La "morte" della chiave è parte normale del ciclo di vita. Sessione finita? Materiali distrutti, contatori resettati, buffer puliti. Superato il limite di dati o tempo per rekey? Si rinnova con un nuovo ECDH, si ottiene un nuovo set di chiavi e si passa senza interruzioni. Nel normale flusso è impercettibile: un piccolo picco di pacchetti di controllo e il traffico riparte liscio.

Crittografia asimmetrica: RSA, ECDSA, ECDH e X25519

RSA: il classico, ma non per sempre

RSA è stato per anni l’icona della crittografia asimmetrica nelle VPN: semplice, comprensibile e diffuso. OpenVPN usa certificati RSA, in IKEv2 l’autenticazione passa dalle firme RSA. Comodo, compatibile, stabile. Ma il mondo avanza: le chiavi diventano più grandi, più costose da calcolare, e la mobilità richiede velocità. Nel 2026 RSA-2048 è ancora accettabile in molti scenari, ma per infrastrutture durature è meglio puntare a RSA-3072 o passare alle firme su curve ellittiche (ECDSA/Ed25519), dove la sicurezza aumenta per bit con meno carico CPU.

Importante: RSA raramente cifra direttamente i dati nelle VPN. Serve per autenticazione e a volte cifratura delle chiavi, ma nei protocolli moderni è sempre uno scambio ibrido con ECDH. Il trend è chiaro: RSA resta per retrocompatibilità e PKI legali, ma per handshake rapidi ed efficienza ECDSA, EDDSA (come Ed25519) e soprattutto ECDH con X25519 sono superiori.

Curve ellittiche e ECDH: velocità e sicurezza

ECDH è il cavallo da lavoro per lo scambio chiavi. Fa calcolare un segreto condiviso senza rivelare valori privati. Oggi domina X25519: veloce, resistente ad attacchi, semplice da implementare e performante su server e smartphone. Curve P-256 e P-384 sono ancora attive e standardizzate, ma X25519 è il de-facto standard nella VPN moderna.

Perché importa? Perché ECDH fornisce il "carburante" per la crittografia simmetrica di sessione. Ci si mette d’accordo sulla curva, si scambiano punti pubblici, si ottiene il segreto comune e tramite KDF si estraggono le chiavi. Il risultato è PFS, handshake con poca latenza e niente chiavi segrete a lungo termine da conservare. Tutto trasparente e pulito, senza fronzoli.

PFS, gruppi DH e scambio chiavi senza panico

Perfect Forward Secrecy è lo scudo che protegge il tuo traffico. Il concetto è semplice: anche se un attaccante ha il privato di server, non può decifrare traffico passato. Perché ogni sessione usa una chiave effimera generata con ECDHE (attenzione alla E di ephemeral). In IPsec significa usare gruppi ECP (tipo 19/20/21 per P-256/P-384/P-521) o curve moderne come X25519. OpenVPN su TLS 1.3 ha ECDHE di default, WireGuard usa X25519 e chiavi effimere incorporati.

Non serve agitarsi: basta scegliere gruppi DH moderni (o X25519), attivare PFS per tutte le child SA in IPsec, garantire buona entropia e non fare handshake su reti troppo instabili. Ricorda che PFS richiede rekey regolari, altrimenti si perde il senso. Niente di magico: solo le giuste opzioni in configurazione.

Crittografia simmetrica nel tunnel: la velocità conta

Modalità AEAD: AES-GCM e ChaCha20-Poly1305

La simmetria regge i "chilobyte e megabyte di lavoro". Nel 2026 le stelle sono le modalità AEAD: AES-GCM e ChaCha20-Poly1305. AEAD (Authenticated Encryption with Associated Data) cifra e autentica insieme, evitando errori classici tipo "cifrato ma senza controllo integrità". Risultato: meno overhead e configurazione più semplice. AES-GCM è perfetto su hardware con AES-NI (x86) o ARMv8 Crypto Extensions, riesce a spingere a gigabit per core. ChaCha20-Poly1305 brilla dove non ci sono acceleratori hardware e su processori mobili, assicurando prestazioni prevedibili e bassa latenza.

OpenVPN, WireGuard e IPsec conoscono entrambi da tempo. WireGuard usa di default ChaCha20-Poly1305, motivo per cui è così efficiente su dispositivi mobili. IPsec sfrutta spesso AES-GCM-128 o 256, in particolare con offload hardware. Non basta attivare AEAD: bisogna anche monitorare i contatori (nonce) per non superarli in una sessione. Ecco perché serve rekey per limiti di dati: non si devono esaurire i contatori.

Lunghezza chiavi e cosa significa davvero 128 vs 256

Nel mondo reale delle VPN AES-128-GCM e AES-256-GCM sono entrambi considerati molto sicuri. La differenza in "riserva teorica" non è così importante come sembra. Spesso AES-128-GCM è più veloce, specialmente su hardware più vecchio, con latenza minore e più throughput. ChaCha20-Poly1305 ha una "lunghezza" fissa e garantisce ampia sicurezza. Quindi il consiglio è semplice: server moderni con AES-NI puntano pure su AES-GCM 128 o 256, testando entrambi e osservando il carico CPU. Su mobile e container senza AES-NI si preferisce ChaCha20-Poly1305, per non complicarsi la vita.

E la "minaccia quantistica"? Colpisce di più l’asimmetria che la simmetria. Aumentare la lunghezza di chiavi simmetriche è una difesa abbastanza diretta. Ma chi usa già AES-128-GCM non deve preoccuparsi troppo. Per dati a lunga conservazione e archivi "congelati" spesso si sceglie AES-256-GCM. Però la vera sicurezza in più arriva da una buona rotazione delle chiavi, non dall’aumentare a dismisura la dimensione in bit.

Accelerazioni hardware: AES-NI, ARMv8 CE, offload NIC

La performance VPN oggi spesso dipende dalla capacità hardware di cifrare "al volo". Su x86 AES-NI è uno standard consolidato, capace di decine di gigabit sui core moderni. Anche i server ARM (e smartphone) sfruttano ARMv8 Crypto Extensions con buone velocità su AES-GCM. Non dimentichiamo l’offload sulle schede di rete: alcune supportano l’accelerazione IPsec a livello hardware, togliendo carico alla CPU. Non è magia, ma i risultati sono notevoli — su linee 10G e 25G spesso l’offload fa la differenza per il throughput.

In pratica, la scelta del cifrario deve considerare l’hardware reale. Un OpenVPN senza AES-NI può essere molto più lento di WireGuard su chip mobile dove ChaCha20-Poly1305 è nativo. Con Linux e XDP si può poi ottimizzare ulteriormente il flusso di pacchetti. E naturalmente è fondamentale profilare con perf, eBPF, metriche CPU e latenza: a volte contano più della "bellezza" teorica.

Come si combinano nei vari protocolli VPN

IPsec/IKEv2: due livelli, un obiettivo

IPsec è il "nonno dei tunnel" ma ancora forte ed efficiente. Ha un’architettura a due livelli: IKEv2 gestisce handshake, scambio chiavi e autenticazione; il traffico effettivo viene cifrato da ESP (Encapsulating Security Payload). In IKEv2 le parti negoziano algoritmi: gruppi ECDH (es. X25519), firme (ECDSA, RSA) e attraverso SA stabiliscono set di parametri. Poi si creano Child SA per il traffico reale, con AEAD (AES-GCM-128/256) e contatori abilitati.

In pratica: si configura la policy cifratura, si sceglie PFS, si imposta il rekey (ad esempio 8 ore per IKE SA, 1 ora o 1–2 GB per Child SA), si tengono conto NAT-T e MTU. Ben configurato, IPsec vola a decine di gigabit con hardware offload. Nel 2026 molti vendor sperimentano modalità post-quantistiche ibride in IKEv2, ma per ora più in test che in produzione. Lo stack principale resta ECDH X25519 con AES-GCM.

OpenVPN e TLS 1.3: handshake semplici senza fronzoli

OpenVPN ha superato da tempo il ruolo di "tunnel SSL semplice" ed è compatibile con TLS 1.3 che riduce gli handshake e abolisce fragilità passate. TLS 1.3 richiede ECDHE, che assicura PFS, e per autenticazione si usa ECDSA o RSA. Dopo l’handshake, OpenVPN usa cifratura simmetrica — AES-GCM o ChaCha20-Poly1305 — con molte distro che offrono ChaCha di default su hardware debole. La rotazione delle chiavi è controllata da parametri come reneg-sec e limiti di byte.

Nel 2026 la pratica è: puntare su TLS 1.3 con crittografia moderna, disabilitare suite obsolete, attivare verify e pinning radice se hai PKI propria. Considera MTU e MSS — OpenVPN su UDP è più robusto e stabile in reti con perdita rispetto a TCP. E ricordati di "data-ciphers": usa solo AEAD. Il resto è superfluo.

WireGuard/NoiseIK: minimalismo e modernità

WireGuard è diventato popolare per il protocollo NoiseIK essenziale, codice minimo e crittografia moderna "out of the box". Per scambio chiavi usa X25519, per cifratura ChaCha20-Poly1305, per hash BLAKE2s, e tutto si rinnova automaticamente circa ogni 120 secondi di inattività e per volume dati — rapido e invisibile. Non vuole fare tutto per tutti, ma eccelle in un compito: tunnel L3 veloce e sicuro.

La magia di WireGuard è nella semplicità delle configurazioni e nell’efficienza su mobile. Su CPU modesti fa miracoli e nel kernel Linux è ottimizzato per latenza minima. Però attenzione: le chiavi statiche sono comode ma in ambienti rigorosi è meglio integrare WireGuard con PKI e automazione distribuzione peers autorizzati. Nel 2026 si lavora su handshake PQC ibridi per WireGuard, ma il mainstream aspetta ancora standard e audit.

Tendenze quantistiche 2026: handshake ibridi

NIST PQC e Kyber/Dilithium nel contesto VPN

Dal 2022 al 2024 il NIST ha definito gli algoritmi post-quantistici e nel 2026 l’industria sperimenta già il loro uso. Per lo scambio chiavi spicca Kyber (CRYSTALS-Kyber), per firme Dilithium e Falcon. Cosa vuol dire per le VPN? Prima di tutto handshake ibridi: ECDH X25519 più Kyber, per resistere a minacce classiche e quantistiche. Le firme Dilithium possono sostituire RSA/ECDSA nelle catene di certificati, anche se ci sono sfide pratiche: dimensioni chiavi e certificati, MTU, performance e compatibilità.

Importante non esagerare. Passare del tutto al PQC è prematuro per la maggior parte delle VPN. Gli ibridi sono un compromesso ragionevole: si aggiunge Kyber a X25519, si misura latenza e comportamento reale, si valuta l’aumento del peso dell’handshake e il carico CPU. Solo quando l’infrastruttura è pronta si procede. Sbagliare in crittografia costa caro: quindi test, banchi prova e compatibilità client sono obbligatori, non optional.

Hybrid X25519+Kyber: dove già si prova

Nel 2026 si vedono modalità ibride in alcune build di OpenVPN e librerie TLS, patch sperimentali IKEv2, e anche in terminazioni NGINX/TLS per tunnel inter-servizi. Nel settore enterprise banche e telco iniziano pilot per verificare integrità DPI, comportamento bilanciatori hardware, aumento dimensione client hello e necessità di gestire MSS. Spesso si scopre che l’aumento latenza handshake è percepibile ma accettabile con MTU ottimizzato e rinnovi giusti.

Dove serve cautela? Nelle reti mobili con jitter alto e RTT instabile. Gli handshake ibridi fanno salire i pacchetti di controllo e rischio frammentazione. La soluzione è semplice: pilotare, misurare, abilitare solo su segmenti critici e mantenere fallback su X25519 finché i client non si aggiornano.

Parte pratica: MTU, performance, compatibilità

Gli algoritmi post-quantistici spesso aumentano dimensioni chiavi e handshake. Nelle VPN questo incide su MTU e frammentazione. Un dettaglio spesso trascurato a torto. Se usi GRE, VXLAN o altre incapsulazioni il margine MTU è limitato. Aggiungi handshake ibrido e arriva ICMP Fragmentation Needed ignorato da molti. Risultato: handshake bloccati o falliti. La prevenzione è semplice: abbassa MTU sull’interfaccia tunnel, attiva MSS clamping e testa il comportamento dei middlebox.

Performance è il secondo punto. Kyber e Dilithium sono veloci in CPU ma pesano in byte sulla rete. Quindi "più cicli" non significa sempre "più veloce". Compatibilità è il terzo tema: servono versioni librerie allineate su server e client e piani rollback chiari. Infine: logga, ma niente dati sensibili crittografici. Solo metadati e stati.

Gestione di chiavi e certificati

PKI, radici, intermedi, OCSP/CRL

Senza PKI le grandi VPN diventano un caos. Il certificato radice firma quello intermedio, che firma server e client. Così si crea una gerarchia di fiducia gestita. Per revoche ci sono OCSP e CRL. Nel 2026 molti adottano OCSP stapling e certificati a breve durata, riducendo la dipendenza dai CRL centralizzati. La regola è semplice: meno passi per verificare e certificati più brevi = meno rischi.

In pratica si isolano root offline, si tengono in HSM e si usano intermedi a breve durata per generare certificati server e client. Chiavi ECDSA/Ed25519 accelerano handshake. CRL si puliscono regolarmente, OCSP si pingano e cache. Il rinnovo certificati client è automatizzato via MDM o CI per evitare corse disperate a fine trimestre.

Politiche di rotazione: tempi, volumi, rekey

La rotazione è fondamentale. Per le chiavi di sessione spazio e tempo: 1 ora e 1–4 GB sono comuni, ma testa il carico tuo. IKE SA solitamente durano più dei Child SA per limitare handshake eccessivi. Certificati con durata breve riducono rischio ma alzano costi operativi se mancata automazione.

Su OpenVPN controlla reneg-sec, reneg-bytes e data-ciphers. WireGuard fa da solo rekey automatico ogni due minuti di inattività o per contatori, ma puoi monitorare peer e timestamp handshake. IPsec ha lifetimes nelle policy e protegge con PFS. Non esagerare con rekey troppo frequenti: ritardi e overhead in reti latenti non sono un regalo. Trova l’equilibrio giusto.

Conservazione sicura: HSM, TPM, permessi file

Le chiavi private a lungo termine del server vanno lontane da occhi indiscreti. HSM è il top, TPM un buon compromesso, soprattutto legati alla macchina. Se non hai hardware dedicato, controlla permessi file, utenti dei servizi e isolamento container. Non tenere le chiavi private insieme a backup di configurazioni "così come sono". Cripta i backup, separa segreti da stati comuni, verifica debolezze chiavi.

Le chiavi client sono un altro discorso. Su laptop con crittografia disco e MDM è più semplice. Su mobile usa storage sicuri del sistema. E non scordare il basics: autenticazione a due fattori dove possibile, revoca certificati immediata su CRL/OCSP, non "a tempo perso".

Performance e ottimizzazione

Scelta cifratura per hardware: desktop, mobile, cloud

La scelta del cifrario segue l’hardware. Su desktop e server con AES-NI ha senso AES-GCM 128/256. Nelle cloud ARM con estensioni crypto pure. Su mobile, router SOHO e container senza acceleratori vince spesso ChaCha20-Poly1305 per consumo e stabilità. WireGuard fa da baseline perfetto senza complicazioni.

Testa tutto. Usa iperf3 dentro tunnel, misura RTT, jitter e perdita pacchetti. Confronta AES-GCM 128 e 256 sulla tua piattaforma: a volte 128 è il 5–15% più veloce senza sacrificare sicurezza. Controlla il comportamento sotto carico: buffer pieni, code NIC, saturazione core. Spesso il collo di bottiglia non è il cifrario, ma MSS/MTU.

MTU, MSS, UDP vs TCP, NAT-T e tunnel QUIC

MTU è un killer silenzioso. Le VPN aggiungono incapsulazione, quindi payload utile cala. Se non riduci MTU e MSS rischi frammentazioni o buchi neri. Ricetta semplice: abbassa MTU sul tunnel (esempio 1380–1420 per UDP, ma testa), abilita MSS clamping e ascolta ICMP. IPsec con NAT-T usa UDP/4500, assicurati che firewall non lo blocchino.

UDP è in genere preferibile per VPN, evita problemi TCP-over-TCP. Perdite e jitter sono più tollerati e protocolli applicativi si occupano di ritrasmissioni. Tunnel QUIC e TLS su QUIC sono trend 2026, specialmente per eludere middlebox intolleranti. Ma occhio: aggiungendo livelli incapsulazione devi gestire MTU e limiti di percorso.

Visibilità end-to-end e test: iperf3, pktloss, jitter

Senza misurazioni niente ottimizzazione. Telemetria end-to-end è il tuo alleato: metriche CPU, latenza handshake, frequenza rekey, perdita pacchetti, distribuzione dimensione pacchetti, coda interfacce. Iperf3 per throughput, tc e ping per perdita e jitter, eBPF per profiling dettagliato. Scopri dove si formano delay: handshake? rekey? picchi traffico? se crittografia si blocca su un core?

E ricorda i casi d’uso reali: richieste brevi e piccoli pacchetti si comportano diversamente da flussi lunghi e stabili. Scindi i test: pacchetti da 64 KB una cosa, da 1–4 MB un’altra. Usa load su tracce registrate. Sì, è più lungo che un test velocità sempre uguale, ma scoprirai colli di bottiglia nascosti come frammentazione o configurazioni code.

Errori comuni e checklist di implementazione

Cifrari deboli e protocolli obsoleti

Primo errore: tenere in compatibilità roba da buttare. RC4, 3DES, CBC senza AEAD, gruppi DH vecchi senza PFS — da evitare in produzione e test. In TLS 1.2 e soprattutto 1.3 elimina compressione, renegotiation inutili e estensioni esotiche. IKEv1 è morto, solo IKEv2. OpenVPN usa solo data-ciphers moderni e liste chiare, niente "any".

Un altro punto: confondere autenticazione e cifratura. Un certificato RSA serve per firme e verifica, non per cifrare traffico dati. Il traffico si cifra simmetricamente con AEAD, meglio evitare CBC e HMAC per abitudine. Più semplice è, meglio è, meno errori.

Entropia debole e numeri casuali

Se RNG si rompe si rompe tutto. Mancanza di entropia a startup VM, container con poca casualità, RNG non inizializzati su device embedded — sono percorso diretto per chiavi prevedibili. Nel 2026 usa kernel moderni con getrandom, monitora stato RNG all’avvio, avvia haveged o simili solo se serve davvero e conoscendo i rischi. Meglio fonti hardware se disponibili.

Controlla librerie crittografiche e versioni. Aggiorna OpenSSL, BoringSSL, wolfSSL, LibreSSL — non per moda, ma perché vulnerabilità di basso livello colpiscono tutto il sistema. E soprattutto: non loggare materiali casuali o chiavi. Mai. Né debug in produzione né "temporaneo fino a domani".

Politiche di accesso e segmentazione rete

VPN non è una bacchetta magica. Cifra il traffico, ma non risolve da sola autorizzazioni e segmentazione. Errore tipico: dare a tutto l’ufficio accesso totale al data center. Segmenta, usa ACL, gruppi e principio del minimo privilegio. Trend moderno è zero trust: autenticato, autorizzato, assegnato a scadenza, accesso loggato.

In pratica aiuta una semplice mappa: chi può andare dove. Dopo ciò handshake, cifrari e protocolli diventano quasi routine tecnica. E l’automazione aiuta: MDM per client, GitOps per server, template unici e test configurazioni. Così non solo cifri, ma gestisci accesso, che è lo scopo di ogni VPN aziendale.

FAQ

Fondamenti

Perché la VPN usa insieme crittografia asimmetrica e simmetrica

L’asimmetria serve per scambiare segreti in modo sicuro tra parti senza segreti condivisi all’inizio. Gestisce handshake, autenticazione e genera chiave di sessione comune. Poi la simmetria cifra il traffico velocemente ed efficientemente. Così otteniamo il duo perfetto: sicurezza handshake più velocità dati. Standard in IPsec, OpenVPN e WireGuard. La segretezza diretta aggiunge valore: compromissione chiave lunga non svela vecchie sessioni. Elegante, semplice e collaudato da decenni.

Cos’è PFS e perché se ne parla tanto

PFS — Perfect Forward Secrecy — garantisce che compromissione chiave lunga non permette di decifrare traffico passato. Lo otteniamo con chiavi effimere negli handshake (ECDHE). In IPsec si usano gruppi DH con PFS su Child SA, in OpenVPN/TLS 1.3 ECDHE è di default, in WireGuard X25519 con rekey regolari. Se un giorno rubano la chiave privata del server, traffico intercettato prima resta indecifrabile. Per questo tutta l’attenzione agli handshake corretti.

Pratica

Cosa scegliere nel 2026: AES-GCM o ChaCha20-Poly1305

Se hai server con AES-NI o ARMv8 Crypto Extensions scegli AES-GCM (128 o 256) senza pensieri. Dove manca accelerazione hardware, specialmente su mobile, ChaCha20-Poly1305 è spesso più veloce ed efficiente in batteria. WireGuard usa ChaCha di default, ecco perché è veloce sugli smartphone. OpenVPN permette di definire data-ciphers e lascia al client la scelta migliore per l’hardware. Testa sempre, misurazioni sono la chiave.

Quali parametri usare per rekey

Valori tipici: tempo 30–120 minuti e volumi 1–4 GB su Child SA in IPsec, in OpenVPN reneg-sec circa un’ora e limite byte, WireGuard fa automatico rekey circa ogni due minuti di inattività o per contatori. Ma è orientativo. Considera RTT, perdite e pattern traffico. Rekey troppo frequente aumenta overhead e ritardi, troppo raro indebolisce PFS e rischia overflow contatori. Trova equilibrio nel laboratorio.

Sicurezza

Conviene già passare agli algoritmi post-quantistici nelle VPN

Completamente? Spesso è prematuro. Handshake ibridi (X25519+Kyber) sono compromesso ragionevole per pilot e segmenti critici. Mantengono compatibilità classica e aggiungono resistenza a futuri attacchi quantistici. Attenzione a dimensioni e MTU. Fai test, misura latenza reale, valuta DPI e bilanciatori. La migrazione di massa è meglio iniziarla quando client e infrastrutture sono pronte e standard più maturi.

Qual è la lunghezza chiave "giusta" oggi

Per asimmetria: RSA-2048 è accettabile ma meglio RSA-3072 o ECDSA/Ed25519. Per scambio chiavi X25519 è standard. Per simmetria: AES-GCM 128 o 256, e su hardware senza accelerazione ChaCha20-Poly1305. Chi più lungo non sempre è meglio: a volte AES-128-GCM è più pratico e veloce. Il vero scudo è PFS, rekey regolare e RNG di qualità. Ricorda: la sicurezza è sistema, non solo "numero di bit".