Google sta aggiornando la crittografia post-quantistica utilizzata nel browser Chrome per proteggersi dagli attacchi TLS tramite computer quantistici e per mitigare gli attacchi store-now-decrypt-later. La prossima modifica sostituirà Kyber utilizzato negli scambi di chiavi ibridi con una versione più recente e leggermente modificata, rinominata Module Lattice Key Encapsulation Mechanism (ML-KEM). Questa modifica arriva circa cinque mesi dopo che Google ha implementato il sistema di incapsulamento delle chiavi TLS sicuro post-quantistico su Chrome stabile. Ciò ha anche causato alcuni problemi con gli scambi TLS. Il passaggio da Kyber a ML-KEM non è però correlato a quei primi problemi, che sono stati risolti subito dopo essersi manifestati. Piuttosto, è una scelta strategica per abbandonare un sistema sperimentale per un meccanismo completamente standardizzato e approvato dal NIST (National Institute of Standards and Technology).
Google spiega che nonostante le modifiche tecniche da Kyber a ML-KEM siano state minime, i due sono essenzialmente incompatibili. Proprio per questo motivo è stato necessario effettuare un passaggio. Come riportato da Big G nel suo blog: "le modifiche alla versione finale di ML-KEM la rendono incompatibile con la versione di Kyber precedentemente distribuita. Di conseguenza, il punto di codice in TLS per lo scambio di chiavi post-quantum ibrido sta cambiando da 0x6399 per Kyber768+X25519 a 0x11EC per ML-KEM768+X25519".
Chrome: aggiornamento arriverà con versione 133 del browser
Google ha anche dichiarato che il supporto per Kyber deve essere rimosso completamente. Infatti, la crittografia post-quantistica comporta dimensioni di dati molto più grandi rispetto agli algoritmi pre-quantistici. Ad esempio, uno scambio di chiavi basato su Kyber può occupare oltre 1.000 byte e le firme post-quantistiche come ML-DSA sono ancora più ingombranti, arrivando a oltre 14.000 byte in un tipico handshake. Se Google decidesse di mantenere il supporto per Kyber oltre a ML-KEM, le prestazioni e l'efficienza della rete su Chrome ne risentirebbero seriamente. Google osserva che gli operatori di server potrebbero supportare temporaneamente entrambi gli standard. Ciò per mantenere la sicurezza per un set più ampio di client e contribuire a rendere la transizione più fluida per i client che non hanno ancora eseguito l'aggiornamento. Tuttavia, ML-KEM dovrebbe essere l'obiettivo finale per tutte le parti interessate.
Una soluzione proposta (bozza IETF) a lungo termine è che i server annuncino quali algoritmi crittografici supportano tramite DNS, in modo che il client utilizzi la chiave appropriata fin dall'inizio, evitando round trip extra durante l'handshake. L'aggiornamento deve essere implementato in Chrome 131 (la versione attuale è 128), la cui uscita è prevista per il 6 novembre 2024. Gli utenti di canali di sviluppo come Chrome Canary, Beta e Dev dovrebbero vedere il supporto ML-KEM prima.