Quantum-safe cryptography: prepararsi all'era post-quantistica nelle applicazioni PHP

Nell'agosto 2024 il NIST ha finalizzato i primi tre standard di crittografia post-quantistica: FIPS 203 (ML-KEM, basato su CRYSTALS-Kyber per lo scambio di chiavi), FIPS 204 (ML-DSA, basato su CRYSTALS-Dilithium per le firme digitali) e FIPS 205 (SLH-DSA, basato su SPHINCS+ come firma stateless di fallback). Questi standard non sono pubblicazioni accademiche destinate a restare nei paper di ricerca - sono specifiche tecniche che i vendor di software e hardware stanno implementando nei loro prodotti. Google Chrome supporta ML-KEM in TLS 1.3 dalla versione 131 (novembre 2024). Apple ha implementato ML-KEM in iMessage dalla fine del 2024. Signal ha integrato il protocollo PQXDH che combina crittografia classica (X25519) con crittografia post-quantistica (ML-KEM) in un approccio ibrido. La migrazione verso la crittografia post-quantistica non è più una questione di se - è una questione di quando, e per le applicazioni che gestiscono dati con vita utile superiore a 10-15 anni, la risposta è: ora.

Per chi sviluppa applicazioni PHP per PMI italiane, la domanda naturale è: cosa devo fare adesso, concretamente? La risposta dipende dal tipo di dati che la tua applicazione gestisce. Se la tua applicazione è un e-commerce che gestisce sessioni e carrelli con una vita utile di ore, la crittografia post-quantistica non è urgente - le sessioni di oggi saranno irrilevanti tra 15 anni indipendentemente dalla crittografia usata. Ma se la tua applicazione gestisce contratti, dati finanziari, dati sanitari, proprietà intellettuale o comunicazioni riservate che avranno valore tra 10-15 anni, il rischio è reale: un attaccante che oggi intercetta e archivia il traffico cifrato con RSA potrà decifrarlo in futuro quando i computer quantistici saranno sufficientemente potenti - un attacco noto come harvest now, decrypt later.

Come funziona la minaccia quantistica alla crittografia e perché RSA è vulnerabile?

La crittografia a chiave pubblica che usiamo oggi - RSA per lo scambio di chiavi e le firme, ECDSA per le firme sulle curve ellittiche, ECDH per lo scambio di chiavi Diffie-Hellman - si basa sulla difficoltà computazionale di due problemi matematici: la fattorizzazione di numeri molto grandi (RSA) e il logaritmo discreto su curve ellittiche (ECDSA, ECDH). I computer classici impiegano tempi astronomici per risolvere questi problemi con chiavi di dimensione adeguata (RSA 2048 bit, ECDSA P-256). Ma l'algoritmo di Shor, eseguito su un computer quantistico con un numero sufficiente di qubit logici, risolve entrambi i problemi in tempo polinomiale - rendendo RSA e ECDSA computazionalmente banali da rompere.

La domanda critica è: quando avremo computer quantistici capaci di eseguire l'algoritmo di Shor su chiavi RSA 2048? Le stime della comunità di ricerca convergono su un orizzonte di 10-20 anni - con margini di incertezza significativi in entrambe le direzioni. Il NIST ha iniziato il processo di standardizzazione nel 2016 proprio perché la migrazione crittografica richiede anni di implementazione, test e deployment, e aspettare che la minaccia sia imminente significherebbe migrare sotto pressione con rischio di errori.

Un punto importante: la crittografia simmetrica (AES-256, ChaCha20) e le funzioni hash (SHA-256, SHA-3) non sono significativamente impattate dai computer quantistici. L'algoritmo di Grover riduce la sicurezza effettiva di un cifrario simmetrico della metà (AES-256 diventa equivalente ad AES-128), ma AES-128 resta computazionalmente sicuro anche per i computer quantistici. Se la tua applicazione PHP usa sodium_crypto_secretbox() (ChaCha20-Poly1305) per cifrare dati a riposo, quei dati sono già quantum-safe. Il problema è limitato alla crittografia a chiave pubblica - TLS handshake, scambio di chiavi, firme digitali e certificati. Nel mio profilo professionale trovi il dettaglio dell'esperienza in sicurezza crittografica che porto in questi assessment - la distinzione tra ciò che è vulnerabile e ciò che non lo è è cruciale per evitare panico ingiustificato e per concentrare le risorse dove servono.

Cosa devono fare concretamente gli sviluppatori PHP oggi?

La risposta pratica si articola in tre livelli di azione, ordinati per urgenza e per rapporto costo/beneficio.

Il primo livello è l'inventario crittografico: mappare quali algoritmi la tua applicazione usa, dove e per cosa. La maggior parte degli sviluppatori PHP non sa rispondere alla domanda "quale algoritmo usi per cifrare i dati dei clienti?" - la risposta è nascosta nelle configurazioni di TLS del server, nelle impostazioni di OpenSSL, nelle chiamate a openssl_encrypt() o sodium_crypto_*() nel codice, e nei pacchetti Composer che implementano crittografia (JWT, OAuth, payment gateway). L'inventario è il prerequisito per qualsiasi decisione: se non sai cosa usi, non puoi pianificare cosa migrare.

Il secondo livello è la migrazione a crittografia simmetrica dove possibile. Se la tua applicazione usa RSA per cifrare dati a riposo (un pattern che trovo nel 20% delle applicazioni auditate - tipicamente per cifrare credenziali nel database), puoi migrare a sodium_crypto_secretbox() (ChaCha20-Poly1305) o AES-256-GCM immediatamente, senza attendere i nuovi algoritmi post-quantistici. La crittografia simmetrica è già quantum-safe, è più veloce, e libsodium la rende banale da usare in PHP:

// Cifratura quantum-safe con libsodium (PHP 7.2+)
// ChaCha20-Poly1305 - simmetrico, veloce, sicuro
$key = sodium_crypto_secretbox_keygen();
$nonce = random_bytes(SODIUM_CRYPTO_SECRETBOX_NONCEBYTES);

// Cifratura
$ciphertext = sodium_crypto_secretbox($datiSensibili, $nonce, $key);
$stored = base64_encode($nonce . $ciphertext);

// Decifratura
$decoded = base64_decode($stored);
$nonce = substr($decoded, 0, SODIUM_CRYPTO_SECRETBOX_NONCEBYTES);
$ciphertext = substr($decoded, SODIUM_CRYPTO_SECRETBOX_NONCEBYTES);
$plaintext = sodium_crypto_secretbox_open($ciphertext, $nonce, $key);

Il terzo livello è la preparazione per TLS post-quantistico. Il TLS handshake è il punto dove la crittografia a chiave pubblica è più esposta all'attacco harvest now, decrypt later: un attaccante che registra il traffico TLS di oggi può, in futuro, decifrare la chiave di sessione e accedere a tutto il traffico della connessione. La soluzione è il TLS ibrido - un handshake che usa sia la crittografia classica (X25519) sia la crittografia post-quantistica (ML-KEM) per lo scambio di chiavi, in modo che la connessione sia sicura anche se uno dei due algoritmi viene rotto. Nginx con OpenSSL 3.5+ (previsto per il 2026) supporterà ML-KEM in TLS 1.3. Cloudflare ha già abilitato il supporto ML-KEM per tutte le connessioni TLS dei suoi clienti. Per i VPS dei miei clienti, la preparazione è verificare la compatibilità della versione di OpenSSL installata e pianificare l'aggiornamento quando il supporto ML-KEM sarà disponibile nel canale stable della distribuzione.

Gli algoritmi NIST finalizzati: cosa sono e come funzionano

I tre standard NIST finalizzati nell'agosto 2024 si basano su problemi matematici diversi dalla fattorizzazione e dal logaritmo discreto - problemi che i computer quantistici non sanno risolvere in modo efficiente.

ML-KEM (FIPS 203), basato su CRYSTALS-Kyber, è un meccanismo di incapsulamento di chiave (Key Encapsulation Mechanism) che sostituisce RSA e ECDH nello scambio di chiavi. Si basa sulla difficoltà del problema Learning with Errors (LWE) su reticoli algebrici - un problema matematico che non ha soluzione quantistica efficiente nota. Le chiavi ML-KEM sono significativamente più grandi di quelle RSA (la chiave pubblica ML-KEM-768 è circa 1.184 byte, contro i 256 byte di X25519), il che aumenta la dimensione del TLS handshake. Ma l'incremento è gestibile per le connessioni TCP moderne - l'overhead aggiuntivo è di circa 1-2 KB per handshake, invisibile per la maggior parte delle applicazioni.

ML-DSA (FIPS 204), basato su CRYSTALS-Dilithium, è lo schema di firma digitale che sostituisce RSA e ECDSA per le firme. Le firme ML-DSA sono più grandi (2.420 byte per ML-DSA-65, contro i 64 byte di Ed25519) ma la verifica è veloce e l'algoritmo è robusto. L'impatto principale è sulle dimensioni dei certificati TLS e sulla catena di certificazione - un certificato con firma ML-DSA pesa circa 3 KB in più rispetto a un certificato con firma RSA-2048.

SLH-DSA (FIPS 205), basato su SPHINCS+, è una firma digitale stateless basata su hash - un approccio diverso dai reticoli, che fornisce una seconda linea di difesa nel caso in cui i problemi sui reticoli si rivelassero vulnerabili in futuro. Le firme SLH-DSA sono molto più grandi (fino a 49 KB per le varianti più sicure), il che le rende inadatte per il TLS ma adatte per scenari dove la dimensione della firma non è un vincolo (firma di documenti, firmware, contratti digitali).

Per lo sviluppatore PHP, l'implicazione pratica è che questi algoritmi saranno disponibili attraverso OpenSSL e libsodium quando le librerie integreranno il supporto - il che è previsto per OpenSSL 3.5 (2026) e per una release futura di libsodium. Non è necessario implementare questi algoritmi a mano - saranno disponibili come opzioni nei medesimi API che usi già oggi per TLS e per le firme. Il lavoro di preparazione oggi è assicurarsi che il codice non sia hard-coded su algoritmi specifici (ad esempio, non fare openssl_sign($data, $signature, $key, OPENSSL_ALGO_SHA256) con l'algoritmo cablato nel codice, ma rendere l'algoritmo configurabile) in modo che la migrazione futura sia una modifica di configurazione, non una modifica del codice.

Un aspetto che le PMI italiane non considerano è l'impatto regolamentare. ENISA ha pubblicato nel 2024 raccomandazioni per la migrazione verso crittografia post-quantistica per i soggetti che rientrano nel perimetro NIS2, indicando come best practice l'uso di approcci ibridi (classico + post-quantistico) per le comunicazioni critiche. Per le aziende che gestiscono dati classificati YMYL (health, finance) o che sono soggetti NIS2, la preparazione post-quantistica non è solo un esercizio tecnico - è un requisito di compliance che inizia ad essere valutato negli audit di sicurezza. Ho documentato le implicazioni NIS2 per gli sviluppatori nel mio articolo sugli obblighi tecnici NIS2 per applicazioni web, dove la postura crittografica è uno degli elementi valutati.

La timeline realistica per le PMI italiane

La domanda che i titolari delle PMI mi fanno è: "Devo preoccuparmi adesso?" La risposta onesta è: dipende da cosa gestisci. Se la tua applicazione gestisce solo dati transazionali con vita utile breve (sessioni, carrelli, ordini del giorno), la minaccia quantistica è lontana e le azioni di oggi sono a basso impatto: aggiorna OpenSSL, usa libsodium per la crittografia simmetrica, e tieni d'occhio gli sviluppi senza panico. Se la tua applicazione gestisce dati con vita utile lunga - contratti ventennali, archivi documentali, dati sanitari, proprietà intellettuale - l'azione è più urgente: fai l'inventario crittografico adesso, migra la cifratura a riposo a crittografia simmetrica (che è quantum-safe oggi), e pianifica il TLS post-quantistico per quando gli strumenti saranno pronti nel tuo stack.

L'errore più comune è pensare che la crittografia post-quantistica sia un problema del futuro che si risolverà da solo. Non si risolverà da solo - richiederà aggiornamenti del server, del runtime PHP, delle librerie, e potenzialmente dei protocolli di comunicazione. La migrazione crittografica è un processo lento e complesso - il NIST ha impiegato 8 anni per finalizzare i primi standard - e chi inizia la preparazione adesso avrà un percorso graduale e gestibile. Chi aspetta che la minaccia sia imminente dovrà migrare in emergenza, con i rischi e i costi che ogni migrazione d'emergenza comporta - e la storia insegna che le migrazioni crittografiche d'emergenza (come la dismissione di SHA-1 o la migrazione da TLS 1.0) sono sempre più costose e più caotiche di quanto previsto. Ho descritto un approccio simile alla preparazione proattiva nel mio articolo sulla conformità NIS2 per sviluppatori di applicazioni web, dove il principio è lo stesso: prepararsi quando il costo della preparazione è basso, non quando il costo dell'impreparazione è alto. Se vuoi un assessment della postura crittografica della tua applicazione PHP - cosa è vulnerabile, cosa è già sicuro, e cosa devi pianificare per la migrazione post-quantistica - contattami per una valutazione: in una giornata mappiamo tutti gli usi di crittografia nella tua applicazione e nella tua infrastruttura e produciamo un piano di migrazione con priorità e timeline realistiche, distinguendo tra ciò che puoi fare oggi con gli strumenti disponibili e ciò che richiede di attendere la maturazione degli standard e delle implementazioni nei runtime che usi in produzione.