Autenticazione Post-Quantistica per Server di Gioco: Runbook di Migrazione ML-DSA con Codice e Dati sulle Prestazioni

Le firme crittografiche che autenticano le connessioni TLS del tuo server di gioco sono a un solo passo algoritmico dall'essere falsificabili. RSA-2048 ed ECDSA-P256 — gli algoritmi dei certificati che proteggono i dati dei giocatori tra la tua CDN e il tuo server di origine — cedono all'algoritmo di Shor su un computer quantistico sufficientemente potente. Non in teoria. In una tempistica che Microsoft, Google e il governo degli Stati Uniti stanno attivamente pianificando per il 2026.

Cloudflare ha appena rilasciato l'autenticazione post-quantistica per le connessioni di origine utilizzando ML-DSA (Module-Lattice-Based Digital Signature Algorithm), standardizzato come FIPS 204. Questa è la prima implementazione in produzione di autenticazione PQ su larga scala — su una rete che gestisce circa il 20% del traffico web. Se il tuo backend di gioco si trova dietro un qualsiasi livello di terminazione TLS, questa migrazione toccherà la tua infrastruttura. E prima inizi, meno dolorosa sarà la transizione.

Questo post è il tuo runbook: cosa si rompe, come rilevarlo, come risolverlo con comandi e codice reali, e come evitare che il tuo backend di gioco diventi l'anello debole.

Perché i Server di Gioco Sono Particolarmente Vulnerabili

I backend di gioco non sono servizi web tipici. Mantengono connessioni persistenti per la sincronizzazione dello stato in tempo reale, archiviano mesi o anni di dati di progressione dei giocatori e gestiscono operazioni sensibili come la gestione dell'inventario e l'elaborazione dei pagamenti. Il modello di minaccia per gli attacchi post-quantistici contro i server di gioco è concreto:

• Credenziali dei giocatori e token di sessione che fluiscono tra il proxy CDN e l'API di origine
• Dati dell'economia di gioco — saldi di valuta virtuale, inventari di oggetti, cronologia degli scambi di valore reale sui mercati secondari
• Webhook di pagamento se il tuo backend elabora gli acquisti lato server
• Segnali anti-cheat che, una volta esposti, permettono agli attaccanti di fare reverse engineering delle tue euristiche di rilevamento

L'attacco da cui ci stiamo proteggendo non è la raccolta passiva di dati. È l'impersonificazione attiva: un attaccante con capacità quantistiche falsifica le credenziali di autenticazione della tua CDN e inietta payload malevoli direttamente nella tua API di gioco. Questa è una minaccia fondamentalmente diversa dal "raccogli ora, decifra dopo".

Abbiamo documentato cosa succede quando l'architettura di sicurezza del backend crolla sotto pressione — l'autenticazione post-quantistica è la prossima evoluzione di quella stessa postura difensiva. La domanda non è se il tuo gioco subirà attacchi sofisticati, ma se la tua infrastruttura sopravviverà.

Crittografia vs. Autenticazione: Cosa Si Rompe Realmente

C'è una distinzione critica che viene costantemente confusa: crittografia post-quantistica e autenticazione post-quantistica sono problemi separati con tempistiche e soluzioni diverse.

Crittografia post-quantistica (già implementata)

Lo scambio di chiavi TLS 1.3 con algoritmi ibridi come X25519Kyber768 è già ampiamente implementato. Cloudflare ha abilitato la crittografia PQ sia per le connessioni visitatore-CDN che per le connessioni CDN-origine nel 2022-2023. Questo protegge i dati in transito dagli attacchi "raccogli ora, decifra dopo".

Autenticazione post-quantistica (la nuova frontiera)

L'autenticazione è dove risiede il vero rischio ora. Quando il tuo server di origine presenta un certificato TLS firmato con RSA-2048 o ECDSA-P256, un computer quantistico che esegue l'algoritmo di Shor può falsificare quella firma in tempo reale. Questo consente attacchi man-in-the-middle — non registrazione passiva, ma intercettazione e manipolazione attiva del tuo traffico di gioco.

Ecco come si suddividono le due connessioni in una tipica architettura di gioco:

┌─────────────┐    Connessione 1     ┌─────────────┐    Connessione 2     ┌─────────────┐
│  Client di   │ ════════════════► │    CDN /    │ ════════════════► │   Origine   │
│  Gioco       │                    │   Proxy     │                    │  (Tua API)  │
│  (Giocatore) │                    └─────────────┘                    └─────────────┘
└─────────────┘                    │                                      │
                              Crittografia PQ ✓                    Crittografia PQ ✓
                              Autenticazione PQ (via MTC, 2027)  Autenticazione PQ (ML-DSA, ORA)
                                    │
                              Certificati di
                              autenticazione classici
                              qui sono l'attuale
                              anello debole

Connessione 2 — dalla tua CDN o proxy inverso alla tua origine — è dove l'autenticazione PQ è implementabile subito. Questa connessione trasporta le azioni dei giocatori, gli aggiornamenti dell'inventario, le richieste di matchmaking e i webhook di pagamento. Se un attaccante falsifica l'autenticazione su questa connessione, possiede il tuo backend.

Perché la Connessione 2 viene per prima

La connessione CDN-origine ha vantaggi strutturali che rendono l'autenticazione PQ pratica anni prima del web pubblico:

• Client TLS controllato: La CDN controlla il connection pooling e il comportamento dell'handshake, ammortizzando il sovraccarico PQ su migliaia di richieste
• Relazione di fiducia esistente: Hai già un rapporto di account con la tua CDN — nessuna dipendenza dall'ecosistema pubblico delle Certificate Authority
• PKI personalizzata: Puoi gestire le tue certificate authority, evitando i vincoli di WebPKI e Certificate Transparency
• Riutilizzo delle connessioni: Le CDN mantengono connessioni persistenti verso le origini, il che significa che gli handshake PQ avvengono raramente rispetto al volume totale di richieste

Ecco perché Cloudflare può rilasciare oggi l'autenticazione ML-DSA per le connessioni di origine mentre Internet pubblico aspetta i Merkle Tree Certificates (previsti per il 2027).

ML-DSA: L'Algoritmo che Alimenta l'Autenticazione PQ

ML-DSA, standardizzato come NIST FIPS 204, si basa sulla difficoltà dei problemi reticolari (lattice problems) — strutture matematiche ritenute resistenti sia agli attacchi classici che quantistici. È l'algoritmo principale in fase di implementazione per le firme digitali post-quantistiche in tutto il settore.

Set di parametri e livelli di sicurezza

Set di Parametri	Livello di Sicurezza	Chiave Pubblica	Firma	Sovraccarico Handshake
ML-DSA-44	NIST Cat 2 (~AES-128)	1.312 B	2.420 B	~4,5 KB aggiunti
ML-DSA-65	NIST Cat 3 (~AES-192)	1.952 B	3.293 B	~6,5 KB aggiunti
ML-DSA-87	NIST Cat 5 (~AES-256)	2.592 B	4.595 B	~9 KB aggiunti

Per confronto, una firma ECDSA-P256 è di 64 byte con una chiave pubblica di 64 byte. Le firme ML-DSA-44 sono circa 37 volte più grandi. Questo è il compromesso principale, ed è il numero che rende nervosi gli sviluppatori.

ML-DSA-44 è la scelta giusta per i backend di gioco. Offre sicurezza di Categoria 2 del NIST — margini confortevoli contro attacchi quantistici e classici noti — pur essendo l'opzione più performante. La dimensione maggiore della firma è gestibile perché il connection pooling rende gli handshake poco frequenti rispetto al traffico totale.

Formato seed FIPS 204: archiviazione compatta delle chiavi

Le chiavi private ML-DSA supportano un formato seed — un valore casuale di 32 byte da cui viene derivata deterministicamente l'intera chiave privata:

Seed (32 byte) ──► Espansione deterministica ──► Chiave privata completa (2.560 byte per ML-DSA-44)

Questo è un vantaggio pratico per l'infrastruttura del backend di gioco. Invece di archiviare chiavi private da 2.560 byte nel tuo secret manager o nelle variabili d'ambiente, memorizzi 32 byte e derivi la chiave completa on demand. La rotazione delle chiavi diventa una questione di generazione e distribuzione di un nuovo seed — operativamente molto più semplice rispetto alla gestione del materiale delle chiavi RSA tradizionali.

Runbook di Migrazione: Passo Dopo Passo

Passo 1: Verifica la tua configurazione TLS attuale

Prima di toccare qualsiasi cosa, capisci cosa stai eseguendo. Controlla la catena di certificati attuale del tuo server di origine e gli algoritmi di firma:

# Ispeziona il certificato che la tua origine sta presentando
openssl s_client -connect your-game-api.example.com:443 \
  -servername your-game-api.example.com \
  </dev/null 2>/dev/null \
  | openssl x509 -text -noout | grep -A2 "Signature Algorithm"

# Controlla le versioni TLS supportate e le cipher suite
nmap --script ssl-enum-ciphers -p 443 your-game-api.example.com

# Se usi mTLS, controlla quale certificato client presenta la tua CDN
# (cattura durante una richiesta di test con tcpdump o equivalente)
tcpdump -i eth0 -w tls_handshake.pcap port 443 -c 50

Documenta questa baseline. Ti servirà per il rollback e per confermare che la migrazione non abbia rotto nulla. Registra:

• Algoritmo di firma attuale (RSA-SHA256, ECDSA-SHA256, ecc.)
• Profondità della catena di certificati e tutte le date di scadenza
• Se mTLS è già in uso
• Versioni TLS supportate (dovresti già essere solo su TLS 1.3)

Passo 2: Genera catene di certificati ML-DSA

Avrai bisogno del provider Open Quantum Safe (OQS) per OpenSSL 3.0+:

# Installa il provider OQS
git clone https://github.com/open-quantum-safe/oqs-provider.git
cd oqs-provider && mkdir build && cd build
cmake -DCMAKE_INSTALL_PREFIX=/usr/local ..
make -j$(nproc) && sudo make install

# Abilita in openssl.cnf — aggiungi a [provider_sect]:
# oqsprovider = oqsprovider_sect
# oqsprovider_sect = oqsprovider

# Genera CA root ML-DSA-44 (validità 10 anni)
openssl req -x509 -new -newkey mldsa44 \
  -keyout mldsa44-ca.key -out mldsa44-ca.crt \
  -days 3650 -nodes \
  -subj "/CN=Game Backend PQ Root CA" \
  -addext "basicConstraints=critical,CA:TRUE" \
  -addext "keyUsage=critical,keyCertSign,cRLSign"

# Genera richiesta di firma del certificato del server di origine
openssl req -new -newkey mldsa44 \
  -keyout mldsa44-server.key -out mldsa44-server.csr \
  -nodes -subj "/CN=your-game-api.example.com"

# Firma il certificato server con CA PQ (validità 1 anno per igiene di rotazione)
openssl x509 -req -in mldsa44-server.csr \
  -CA mldsa44-ca.crt -CAkey mldsa44-ca.key \
  -CAcreateserial -out mldsa44-server.crt \
  -days 365 \
  -extfile <(echo "subjectAltName=DNS:your-game-api.example.com")

# Genera certificato client per mTLS (identità della tua CDN)
openssl req -new -newkey mldsa44 \
  -keyout mldsa44-client.key -out mldsa44-client.csr \
  -nodes -subj "/CN=CDN Proxy Client"

openssl x509 -req -in mldsa44-client.csr \
  -CA mldsa44-ca.crt -CAkey mldsa44-ca.key \
  -CAcreateserial -out mldsa44-client.crt -days 365

# Verifica la catena
openssl verify -CAfile mldsa44-ca.crt mldsa44-server.crt
openssl verify -CAfile mldsa44-ca.crt mldsa44-client.crt

Nota sulla gestione delle chiavi: Dove possibile, archivia il seed di 32 byte piuttosto che l'intera chiave privata di 2.560 byte. Questo semplifica la rotazione dei segreti e riduce la superficie d'attacco nei secret manager e nelle variabili d'ambiente.

Passo 3: Configura il tuo server di origine per mTLS PQ

Configurazione Nginx:

server {
    listen 443 ssl;
    server_name your-game-api.example.com;

    # Certificato server ML-DSA-44
    ssl_certificate     /etc/ssl/pq/mldsa44-server.crt;
    ssl_certificate_key /etc/ssl/pq/mldsa44-server.key;

    # Verifica client (mTLS) — fidati solo della CA PQ
    ssl_client_certificate /etc/ssl/pq/mldsa44-ca.crt;
    ssl_verify_client on;
    ssl_verify_depth 2;

    # Solo TLS 1.3 — nessun downgrade a versioni precedenti
    ssl_protocols TLSv1.3;

    location /api/ {
        proxy_pass http://game_backend_upstream;
        proxy_set_header X-Client-DN $ssl_client_s_dn;
        proxy_set_header X-Client-Verified $ssl_client_verify;
    }
}

Server di gioco personalizzato in C++ (OpenSSL 3.0 + OQS):

#include <openssl/ssl.h>
#include <openssl/err.h>

SSL_CTX* create_pq_mtls_context() {
    SSL_CTX* ctx = SSL_CTX_new(TLS_server_method());
    if (!ctx) {
        ERR_print_errors_fp(stderr);
        return nullptr;
    }

    // Imposta TLS 1.3 come versione minima — nessun downgrade possibile
    SSL_CTX_set_min_proto_version(ctx, TLS1_3_VERSION);

    // Carica il certificato server ML-DSA-44
    if (SSL_CTX_use_certificate_file(ctx,
            "/etc/ssl/pq/mldsa44-server.crt",
            SSL_FILETYPE_PEM) != 1) {
        ERR_print_errors_fp(stderr);
        SSL_CTX_free(ctx);
        return nullptr;
    }

    // Carica la chiave privata ML-DSA-44
    if (SSL_CTX_use_PrivateKey_file(ctx,
            "/etc/ssl/pq/mldsa44-server.key",
            SSL_FILETYPE_PEM) != 1) {
        ERR_print_errors_fp(stderr);
        SSL_CTX_free(ctx);
        return nullptr;
    }

    // Verifica che la chiave corrisponda al certificato
    if (SSL_CTX_check_private_key(ctx) != 1) {
        fprintf(stderr, "Key/cert mismatch\n");
        SSL_CTX_free(ctx);
        return nullptr;
    }

    // Carica la CA PQ per la verifica del certificato client
    if (SSL_CTX_load_verify_locations(ctx,
            "/etc/ssl/pq/mldsa44-ca.crt", nullptr) != 1) {
        ERR_print_errors_fp(stderr);
        SSL_CTX_free(ctx);
        return nullptr;
    }

    // Richiedi e verifica i certificati client
    SSL_CTX_set_verify(ctx,
        SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT,
        nullptr);

    return ctx;
}

// Utilizzo nel loop di accettazione del tuo server di gioco:
void handle_connection(int client_fd, SSL_CTX* ctx) {
    SSL* ssl = SSL_new(ctx);
    SSL_set_fd(ssl, client_fd);

    if (SSL_accept(ssl) <= 0) {
        // Handshake fallito — probabilmente problema con il certificato client
        ERR_print_errors_fp(stderr);
        SSL_free(ssl);
        close(client_fd);
        return;
    }

    // Verifica che il certificato client sia stato effettivamente presentato
    X509* client_cert = SSL_get_peer_certificate(ssl);
    if (!client_cert) {
        fprintf(stderr, "Nessun certificato client — rifiuto\n");
        SSL_shutdown(ssl);
        SSL_free(ssl);
        close(client_fd);
        return;
    }

    // Client autenticato tramite ML-DSA mTLS — procedi
    X509_free(client_cert);
    // ... gestisci il protocollo di gioco ...
}

Passo 4: Aggiorna il trust store della tua CDN/proxy

Se utilizzi Cloudflare, carica il tuo certificato CA ML-DSA nel Custom Origin Trust Store e configura Authenticated Origin Pulls con il tuo certificato client ML-DSA:

1. Carica mldsa44-ca.crt nel trust store personalizzato della tua CDN
2. Carica mldsa44-client.crt e mldsa44-client.key per gli authenticated origin pulls
3. Imposta la modalità SSL su Full (strict) per imporre la validazione del certificato contro il tuo trust store personalizzato

Se gestisci la tua infrastruttura proxy, dovrai distribuire il certificato CA PQ a tutti i nodi proxy, configurare i certificati client per ciascuno e impostare il monitoraggio per la scadenza dei certificati. Gestire tutto manualmente attraverso più regioni e gruppi di scaling è dove la complessità operativa si accumula — la distribuzione e la rotazione automatica dei certificati diventano essenziali.

Passo 5: Testa l'handshake PQ

# Verifica che l'handshake mTLS ML-DSA abbia successo
openssl s_client -connect your-game-api.example.com:443 \
  -servername your-game-api.example.com \
  -cert mldsa44-client.crt \
  -key mldsa44-client.key \
  -CAfile mldsa44-ca.crt \
  </dev/null 2>&1 | grep -E "(Verify return|Protocol|Cipher)"

# Output previsto:
#   Verify return code: 0 (ok)
#   Protocol  : TLSv1.3
#   Cipher    : TLS_AES_256_GCM_SHA384

# Misura la latenza dell'handshake sotto carico
# (regola il tasso di connessione per simulare le condizioni del giorno del lancio)
wrk -t4 -c100 -d30s --latency \
  --script=pq_mtls_test.lua \
  https://your-game-api.example.com/api/health

Cosa monitorare durante i test:

• Latenza dell'handshake: Aspettati 0,5–2 ms aggiuntivi per ogni nuova connessione rispetto a ECDSA-P256
• Utilizzo CPU: La verifica della firma ML-DSA è circa 2–3 volte più lenta della verifica ECDSA
• Tassi di errore: Tieni d'occhio i fallimenti di validazione dei certificati durante la transizione
• Utilizzo del connection pool: Conferma che le connessioni vengano riutilizzate (ammortizzando il costo dell'handshake)

Passo 6: Rimuovi i fallback classici

Questo è il passo che fornisce effettivamente la sicurezza quantistica. Se la tua origine accetta qualsiasi autenticazione classica (RSA/ECDSA), un attaccante con capacità quantistiche può falsificare quelle credenziali e bypassare le tue protezioni PQ.

Lo scenario di attacco downgrade:

L'attaccante intercetta l'handshake CDN ↔ Origine
    │
    ├── Forza la negoziazione verso l'autenticazione RSA classica
    ├── Falsa la firma RSA usando l'algoritmo di Shor
    └── Si impersona come CDN verso il tuo server di origine ✓

I tuoi certificati PQ sono inutili se esistono fallback classici.

La soluzione: il tuo server di origine deve fidarsi solo dei certificati ML-DSA per la connessione CDN-origine.

# SBAGLIATO: Trust store misto — i certificati classici sono ancora accettati
ssl_client_certificate /etc/ssl/mixed-ca-bundle.crt;

# GIUSTO: Trust store solo PQ — le falsificazioni classiche vengono respinte
ssl_client_certificate /etc/ssl/pq/mldsa44-ca.crt;

Avvertenza critica: Rimuovi la fiducia classica solo dopo aver confermato che tutte le connessioni CDN stanno utilizzando l'autenticazione PQ. Una rimozione prematura rompe la connettività della tua origine. Esegui la configurazione dual-stack (Passi 3–5) per almeno due settimane, monitorando che zero connessioni ricadano sull'autenticazione classica, prima di rimuovere la fiducia classica.

Impatto sulle Prestazioni: Numeri Reali per Backend di Gioco

La preoccupazione legittima: le firme ML-DSA sono grandi. Ecco cosa significa in pratica.

Sovraccarico a livello di handshake

Metrica	ECDSA-P256	ML-DSA-44	Delta
Dimensione certificato server	~500 B	~1.700 B	+240%
Dimensione firma	64 B	2.420 B	+3.681%
Byte totali handshake	~1,5 KB	~6 KB	+300%
Latenza handshake (p50)	~1 ms	~2,5 ms	+150%
CPU per verifica handshake	~0,05 ms	~0,12 ms	+140%

Perché questo non distrugge il tuo backend di gioco

Le connessioni CDN-origine utilizzano connection pooling. Una singola connessione TLS gestisce migliaia di richieste HTTP prima di essere riciclata. La latenza aggiuntiva di 1,5 ms dell'handshake viene ammortizzata su, diciamo, 10.000 richieste — sono 0,00015 ms per richiesta. Effettivamente zero.

L'impatto sulle prestazioni si concentra in due scenari:

1. Avvio a freddo / picchi di stabilimento della connessione: Lanci di giochi, eventi stagionali, momenti virali — quando la tua origine gestisce migliaia di nuove connessioni TLS al secondo. Se la tua origine gestisce attualmente 50.000 handshake ECDSA/secondo, aspettati circa 20.000–25.000 handshake ML-DSA-44/secondo su hardware equivalente. Pianifica la capacità di conseguenza.

2. Connessioni di breve durata: Se la tua architettura crea una nuova connessione TLS per ogni richiesta (per favore, non farlo), ogni richiesta paga il costo completo dell'handshake. Risolvi con connection pooling e connessioni persistenti prima di migrare all'autenticazione PQ.

Impatto sulla larghezza di banda

I ~4,5 KB aggiuntivi di dati dell'handshake per ogni nuova connessione sono trascurabili per le connessioni multiplexate HTTP/2 o HTTP/3. Per i protocolli di gioco basati su WebSocket con connessioni di lunga durata, l'handshake avviene una volta per tutta la durata della connessione — irrilevante per i budget di larghezza di banda.

Best Practice per la Migrazione PQ del Backend di Gioco

1. Abilita prima la crittografia PQ, poi l'autenticazione. Se non hai ancora attivato lo scambio di chiavi post-quantistico (X25519Kyber768) per le tue connessioni di origine, fallo prima di affrontare i certificati. È una modifica di configurazione — nessun nuovo certificato — e protegge immediatamente dagli attacchi "raccogli ora, decifra dopo".

2. Implementa ML-DSA-44, non ML-DSA-87. A meno che tu non stia proteggendo sistemi militari classificati, ML-DSA-44 offre margini di sicurezza confortevoli alla Categoria 2 del NIST. ML-DSA-87 raddoppia approssimativamente il sovraccarico dell'handshake per un beneficio di sicurezza marginale che il tuo modello di minaccia quasi certamente non richiede.

3. Esegui dual-stack durante la transizione — poi elimina il classico senza pietà. Implementa sia i certificati classici che PQ in parallelo. Monitora per almeno due settimane. Conferma zero connessioni di fallback classiche. Poi rimuovi completamente la fiducia classica. Lasciare i fallback classici in atto è l'errore più comune nella migrazione PQ — rende i tuoi costosi nuovi certificati un teatro di sicurezza.

4. Automatizza la rotazione delle chiavi dal primo giorno. Il formato seed di 32 byte di ML-DSA lo rende pratico. Includi la rotazione dei certificati nella tua pipeline di deployment. Ruota trimestralmente — non perché la crittografia si indebolisca, ma perché l'igiene operativa delle chiavi (credenziali trapelate, ingegneri che se ne vanno, CI/CD compromesso) è la tua vulnerabilità reale.

5. Profila il tuo tasso di churn delle connessioni. Esegui ss -s o equivalente sui tuoi server di origine per contare le nuove connessioni al secondo durante i picchi e i periodi di bassa attività. Moltiplica per il delta del sovraccarico dell'handshake (~1,5 ms CPU, ~4,5 KB larghezza di banda). Questo ti darà un numero concreto per la pianificazione della capacità della migrazione.

Cosa Significa Questo per il Backend del Tuo Gioco

La tempistica post-quantistica non è più accademica. Il NIST ha standardizzato ML-DSA. I principali fornitori di infrastrutture lo stanno implementando in produzione. I mandati governativi stanno accelerando l'adozione. La domanda non è se il tuo backend di gioco abbia bisogno di autenticazione PQ — ma quando inizierai la migrazione.

Per i team che gestiscono la propria infrastruttura di origine, il lavoro è reale ma delimitato: generare nuove catene di certificati, aggiornare le configurazioni del server, modificare i trust store, testare e rimuovere i fallback classici. Ogni passo richiede poche ore di lavoro. Cumulativamente, è un progetto di una o due settimane per un ingegnere backend che ha dimestichezza con TLS.

Se preferisci dedicare quelle settimane al gameplay piuttosto che all'infrastruttura crittografica, horizOn gestisce la terminazione TLS, mTLS e la gestione dei certificati come parte della sua piattaforma backend — permettendoti di distribuire funzionalità mentre la migrazione PQ viene eseguita come una modifica di configurazione anziché come un progetto infrastrutturale di più settimane.

Inizia oggi. Esegui i comandi di audit del Passo 1 contro la tua origine di produzione. Controlla quale algoritmo di firma utilizzano i tuoi certificati. Se è RSA o ECDSA, aggiungi la migrazione all'autenticazione PQ alla tua roadmap 2026-2027. I computer quantistici che arriveranno per i dati dei tuoi giocatori non aspetteranno che tu sia pronto.

---

Fonte: Autenticazione post-quantistica per le origini ora supportata