Come funzionano le chiavi di crittografia: base della sicurezza

Una chiave di crittografia è una stringa di bit casuali che blocca e sblocca i dati. Per il trasferimento moderno di file, questo significa tipicamente una chiave AES a 256 bit — 32 byte di dati casuali generati da un generatore di numeri casuali crittograficamente sicuro (CSPRNG). Lo stesso algoritmo che trasforma un video da 10 GB in testo cifrato può decifrarlo solo se gli viene fornita esattamente la stessa chiave. La sicurezza delle chiavi è dove la crittografia vive o muore: un perfetto cifrario AES-256 è inutile se la chiave è debole, prevedibile o esposta. Questo articolo illustra come le chiavi vengono create, condivise, memorizzate e distrutte in servizi reali come HexaTransfer, Tresorit e Proton Drive.

Le chiavi sono semplicemente numeri casuali

Una chiave a 256 bit è 32 byte. Se ne generi una nel browser, appare così:

const key = crypto.getRandomValues(new Uint8Array(32));
// Uint8Array(32) [183, 45, 201, 77, ...]

Ciò che la rende una "chiave" è il modo in cui un algoritmo la usa. AES-256-GCM prende una chiave a 256 bit, la espande tramite un key schedule in 15 round key, e le usa per mescolare blocchi a 128 bit attraverso 14 round. La matematica non si preoccupa da dove vengono i bit — richiede solo che siano segreti e imprevedibili.

"Imprevedibile" è la metà più difficile. Se un aggressore può indovinare lo stato del tuo RNG, può rigenerare la tua chiave. Il bug OpenSSL di Debian del 2006 ha ridotto l'entropia delle chiavi a 15 bit per due anni prima di essere scoperto — un esempio classico di cosa succede quando la casualità fallisce.

Casualità crittograficamente sicura

I browser forniscono crypto.getRandomValues() che attinge dal CSPRNG del SO: /dev/urandom su Linux, BCryptGenRandom su Windows, SecRandomCopyBytes su macOS. Questi a loro volta mescolano più fonti di entropia — tempistiche degli interrupt, tempi di ricerca su disco, chip RNG hardware come Intel RDRAND.

Non usare Math.random() per le chiavi. È un Mersenne Twister prevedibile e lo stato può spesso essere recuperato da pochi output.

Lato server, crypto.randomBytes() in Node.js e secrets.token_bytes() in Python avvolgono il CSPRNG del SO e sono sicuri. Gli standard NIST SP 800-90A e SP 800-90B definiscono i requisiti CSPRNG; il kernel Linux 5.17+ usa un design basato su BLAKE2s che li soddisfa.

Chiavi simmetriche: una chiave, due direzioni

Gli algoritmi simmetrici come AES usano una chiave sia per la cifratura che per la decifratura. Le opzioni di dimensione della chiave:

• 128 bit — 2^128 valori possibili, sicuro per la maggior parte degli scopi, approvato per SECRET da NSA CNSSP-15.
• 192 bit — raro, usato in alcuni contesti governativi.
• 256 bit — 2^256 valori, approvato per TOP SECRET, default attuale per i servizi di trasferimento file.

Raddoppiare la dimensione della chiave non raddoppia la difficoltà di brute force — la eleva al quadrato. 2^128 è già fuori portata (l'età dell'universo per 10 miliardi con tutti i computer della Terra). 256 bit è un margine di sicurezza contro i computer quantistici, dove l'algoritmo di Grover dimezza efficacemente la forza delle chiavi simmetriche.

Il problema difficile con le chiavi simmetriche: far arrivare la stessa chiave a entrambe le parti senza che nessuno la intercetti.

Chiavi asimmetriche: il trucco della coppia

La crittografia a chiave pubblica risolve la distribuzione delle chiavi. Ogni parte genera una coppia di chiavi matematicamente collegate: una chiave pubblica (condivisa apertamente) e una privata (tenuta segreta). Qualsiasi cosa cifrata con la chiave pubblica può essere decifrata solo con la chiave privata.

Tipi di chiavi asimmetriche comuni:

• RSA-2048 — modulo a 2048 bit, ampiamente supportato, lento. Usato nei certificati TLS.
• RSA-4096 — più robusto, ancora più lento.
• Curve25519 (X25519) — chiave a curva ellittica a 256 bit, veloce, usato da Signal e WireGuard.
• Ed25519 — chiave di firma a 256 bit, usato da SSH e firma dei commit Git.

La chiave privata da sola è 32–512 byte a seconda dell'algoritmo. Le chiavi private RSA sono più grandi perché contengono più numeri primi; le chiavi private Curve25519 sono solo 32 byte casuali.

Crittografia ibrida: combinare i due per i sistemi reali

Nessun sistema pratico cifra file di grandi dimensioni direttamente con RSA. Ogni protocollo reale — TLS, PGP, Age, Signal, ogni servizio di trasferimento file serio — usa la crittografia ibrida:

1. Genera una chiave AES casuale a 256 bit ("session key" o "file key").
2. Cifra il file con AES-256-GCM.
3. Cifra la session key con la chiave pubblica del destinatario.
4. Invia entrambi.

Il destinatario decifra la session key con la sua chiave privata, poi la usa per decifrare il file. Ottieni la velocità della crittografia simmetrica e la comodità di distribuzione delle chiavi della crittografia asimmetrica.

Per il trasferimento di file basato su browser, la "chiave pubblica" viene spesso sostituita con il frammento URL: il mittente genera una session key, la incorpora nell'URL dopo #, e il browser del destinatario la legge localmente. Più semplice, e funziona senza che i destinatari abbiano una coppia di chiavi.

Derivare chiavi dalle password

Gli utenti digitano password; gli algoritmi vogliono bit uniformemente casuali. Una key derivation function (KDF) colma il divario:

• PBKDF2-HMAC-SHA-256 — itera una funzione hash. OWASP 2023 raccomanda 600.000 iterazioni. Disponibile nella Web Crypto API.
• scrypt — memory-hard, resiste agli attacchi GPU. Parametri: N=2^17, r=8, p=1.
• Argon2id — migliore pratica attuale, vincitore del Password Hashing Competition 2015. Parametri: memory=64 MB, iterations=3, parallelism=4.

Una KDF aggiunge un salt (casuale, memorizzato accanto al testo cifrato) e un work factor (iterazioni) per rallentare il brute force. Una password casuale di 12 caratteri attraverso Argon2id con 64 MB di memoria richiederebbe a una GPU farm migliaia di anni per esaurire lo spazio. Una password debole come estate2024 cade in secondi indipendentemente dalla KDF — la KDF non può aggiungere entropia che non c'era.

Dove vivono le chiavi: le opzioni di memorizzazione

Le chiavi devono esistere da qualche parte, e quel posto è una decisione critica per la sicurezza:

• Memoria del browser (solo sessione). Il default per i trasferimenti effimeri. La chiave viene generata, usata e scartata entro il caricamento della pagina.
• Frammento URL. Condiviso tramite il link, memorizzato nella cronologia del browser del destinatario. La durata limitata è importante.
• Local storage / IndexedDB. Persistente ma accessibile a qualsiasi JavaScript sull'origine. Rischioso a meno che non sia cifrato con un'altra chiave.
• Keychain del SO — macOS Keychain, Windows DPAPI, Linux libsecret. Con supporto hardware su alcune piattaforme.
• Hardware Security Module (HSM) — YubiKey, cloud HSM (AWS CloudHSM, Azure Dedicated HSM). Le chiavi non lasciano mai l'hardware.
• Key Management Service (KMS) — AWS KMS, Google Cloud KMS, HashiCorp Vault. Centralizzato, verificabile, a circa $1/chiave/mese.

Per il trasferimento file zero-knowledge, la chiave vive nel frammento URL e nel browser del mittente. Il server non la memorizza mai.

Rotazione e distruzione delle chiavi

Le chiavi longeve accumulano rischi. La migliore pratica è la rotazione:

• Certificati TLS: rotazione a 90 giorni (default di Let's Encrypt), massimo 398 giorni per le CA pubbliche dal 2020.
• Chiavi di cifratura dei dati: tipicamente ruotate ogni 90 giorni–1 anno nei sistemi conformi (PCI DSS 4.0 Requisito 3.6).
• Chiavi master: ruotate annualmente o al cambio del personale.

Anche la distruzione è importante. Semplicemente eliminare i file delle chiavi dal disco non è sufficiente — gli SSD possono conservare dati nelle aree di wear-leveling. La distruzione sicura richiede sovrascrittura o comandi di cancellazione HSM dedicati. La cancellazione crittografica — buttare via la chiave in modo che i dati cifrati diventino permanentemente illeggibili — è spesso l'approccio più pulito per i dati in blocco.

I servizi di trasferimento file tipicamente usano chiavi per file che esistono solo per la durata del trasferimento (da 24 ore a 7 giorni) e vengono scartate insieme al testo cifrato alla scadenza.

Riconoscere le pratiche deboli sulle chiavi

Tre modalità di fallimento comuni da tenere d'occhio:

• Chiavi hard-coded nel codice client. Se la chiave è la stessa per ogni utente, non è una chiave — è offuscamento.
• Chiavi memorizzate accanto al testo cifrato sullo stesso server o database. Una violazione espone entrambi.
• Nessuna rotazione delle chiavi. I sistemi legacy con chiavi di cifratura vecchie di un decennio hanno circa un decennio di rischio di violazione accumulato.

Un servizio affidabile pubblica un white paper crittografico che copre generazione, memorizzazione, rotazione e distruzione delle chiavi — e si sottopone ad audit di terze parti da parte di aziende come Cure53 o Trail of Bits.

Mettere tutto in prospettiva

Per la condivisione sicura di file: scegli un servizio che genera chiavi a 256 bit lato client tramite crypto.getRandomValues(), le incorpora solo nel frammento URL (mai inviate al server), supporta chiavi derivate da password tramite PBKDF2 o Argon2id, e scade automaticamente sia la chiave che il testo cifrato entro 24 ore.

Provalo su hexatransfer.com — gratis, senza registrazione, fino a 10 GB.