Cos’è AES-256-GCM e perché conta per le app di note

AES-256-GCM è la crittografia autenticata di Signal, 1Password, WireGuard e TLS: cosa vuol dire ogni parte del nome, perché GCM batte CBC, cosa verificare.

Mathis Belouar-Pruvot

· fondatore di Filarr · · 10 min di lettura

Risposta rapida. AES-256-GCM è una modalità di crittografia autenticata che unisce AES-256 (il cifrario simmetrico usato da governi, banche e Signal) a GCM (Galois/Counter Mode, che aggiunge il rilevamento delle manomissioni). È la modalità usata da TLS 1.3, WireGuard, Signal e 1Password. Un’app di note che dichiara una «crittografia AES-256» dovrebbe precisare GCM (o un’altra modalità autenticata): un semplice AES-256-CBC senza autenticazione è un campanello d’allarme.

Quando un’app attenta alla privacy dice «i tuoi dati sono protetti con crittografia AES-256», l’affermazione è incompleta. AES-256 è un cifrario, non uno schema di crittografia completo. La modalità operativa conta quanto il cifrario stesso, e una modalità scelta male può rendere AES-256 di fatto inutile.

Questo articolo spiega AES-256-GCM in parole semplici: cosa fa ogni componente, perché batte le modalità più vecchie come CBC, quali sono le sue trappole note e cosa verificare quando un’app di note o di archiviazione file dice di usarlo.

Cosa significa AES-256-GCM, pezzo per pezzo?

Il nome ha tre parti: AES, 256 e GCM. Ognuna ha un significato preciso.

AES (Advanced Encryption Standard) è un cifrario simmetrico standardizzato nel 2001 dal National Institute of Standards and Technology degli Stati Uniti (FIPS 197). «Simmetrico» significa che la stessa chiave crittografa e decrittografa. AES è il cifrario più analizzato al mondo e, nella sua forma completa, non è mai stato violato.

256 è la lunghezza della chiave in bit. AES è definito per tre lunghezze di chiave: 128, 192 e 256 bit. AES-256 è la variante più robusta, con uno spazio delle chiavi di 2²⁵⁶: astronomicamente più grande di quanto un attacco a forza bruta possa raggiungere in pratica, anche con un ipotetico hardware quantistico (l’algoritmo di Grover dimezza la lunghezza effettiva della chiave, lasciando ad AES-256 una sicurezza post-quantistica di 2¹²⁸, comunque irraggiungibile).

GCM (Galois/Counter Mode) è una modalità operativa. Da solo, AES crittografa un unico blocco da 128 bit. Per crittografare dati di lunghezza arbitraria serve una modalità che concateni i blocchi. GCM è una di queste e, soprattutto, offre una crittografia autenticata con dati associati (AEAD): non si limita a crittografare i tuoi dati, produce anche un tag che rileva qualsiasi manomissione.

Messo insieme, AES-256-GCM = «crittografa con AES, chiave da 256 bit, in una modalità che rileva le manomissioni».

Perché GCM conta? AES non è già sicuro?

AES è sicuro come cifrario a blocchi. Ma da soli i cifrari a blocchi non servono a niente: serve una modalità operativa, ed è la scelta della modalità a determinare le proprietà di sicurezza dell’intero sistema.

L’errore classico è usare AES in modalità CBC senza autenticazione. CBC crittografa correttamente i tuoi dati, ma non ti dice se il testo cifrato è stato manomesso. Un attaccante in grado di invertire dei bit nel blob crittografato può alterare il tuo testo in chiaro in modo prevedibile: è una famiglia di attacchi detti «padding oracle» (vedi gli attacchi BEAST e Lucky 13 contro CBC in TLS). La decrittografia riesce, ma ti restituisce un testo in chiaro manomesso.

GCM risolve il problema calcolando un tag Galois MAC (GMAC) insieme al testo cifrato. Alla decrittografia, se il tag non corrisponde, la decrittografia fallisce: non vedi mai un testo in chiaro manomesso. È la crittografia autenticata e, nel 2026, è l’unica scelta accettabile per un sistema nuovo.

ModalitàCrittografa?Rileva le manomissioni?Stato
AES-ECBSì (male)NoViolata, da non usare mai
AES-CBC (senza MAC)SìNoDa evitare
AES-CBC + HMACSìSì (se combinati bene)Accettabile ma soggetta a errori
AES-GCMSìSì (integrato)Consigliata
AES-OCBSìSì (integrato)Storicamente vincolata da brevetti
ChaCha20-Poly1305Sì (altro cifrario)Sì (integrato)Alternativa altrettanto valida

Come funziona GCM, in concreto?

GCM combina due operazioni:

  1. Crittografia in modalità contatore (CTR). GCM prende un nonce a 96 bit («number used once», numero usato una sola volta), gli concatena un contatore a 32 bit, crittografa quel blocco con AES e fa lo XOR del risultato con ogni blocco di testo in chiaro. Così AES diventa un cifrario a flusso. Ogni blocco usa un contatore diverso, quindi testi in chiaro identici producono testi cifrati diversi.

  2. MAC su campo di Galois. In parallelo alla crittografia, GCM calcola un hash polinomiale in GF(2¹²⁸) sul testo cifrato e sugli eventuali dati associati (intestazioni, metadati). Il risultato è un tag di autenticazione da 128 bit aggiunto al testo cifrato.

Per decrittografare, GCM ripete il calcolo GMAC, lo confronta con il tag ricevuto e procede alla decrittografia solo se i tag coincidono. Un solo bit invertito nel testo cifrato = tag non corrispondente = la decrittografia si rifiuta di restituire il testo in chiaro.

Le prestazioni sono eccellenti: GCM è parallelizzabile (modalità contatore) e le CPU moderne implementano in hardware sia AES sia la moltiplicazione in GF(2¹²⁸) (istruzioni Intel AES-NI e PCLMULQDQ). Su un portatile del 2026, AES-256-GCM gira a 5–10 GB/s.

Qual è la trappola mortale di AES-GCM?

GCM ha una regola critica, e infrangerla ha conseguenze reali: non riusare mai un nonce con la stessa chiave. Il nonce a 96 bit deve essere unico per ogni crittografia eseguita con una data chiave.

Se riusi un nonce, crollano sia la riservatezza sia l’autenticità di GCM. Un attaccante che vede due testi cifrati con la stessa coppia (chiave, nonce) può:

  • fare lo XOR dei due per ottenere lo XOR dei testi in chiaro (conoscere un pezzo di uno dei due basta a ricavare l’altro)
  • recuperare la sottochiave di autenticazione GMAC e poi falsificare testi cifrati arbitrari che si decrittografano in qualsiasi cosa voglia

È il cosiddetto forbidden attack, ed è il motivo per cui le implementazioni di GCM devono essere scrupolose. La NIST SP 800-38D (lo standard GCM) limita a 2³² il numero di crittografie per chiave, oltre il quale, con nonce casuali, il rischio di riuso diventa inaccettabile.

Il riuso dei nonce ha già avuto conseguenze reali: le più note in alcune prime implementazioni Bluetooth, in WPA2 (l’attacco KRACK) e nelle prime implementazioni di GCM in TLS. Un’implementazione corretta usa un contatore deterministico oppure nonce casuali per ogni messaggio, con limiti di rinnovo delle chiavi documentati.

Quando valuti la crittografia di un’app di note, la domanda giusta non è «usate AES-256-GCM?» ma «come derivate i nonce e ogni quanto ruotate le chiavi?»

Perché le app di note usano AES-256-GCM?

Per note e file, AES-256-GCM è la scelta giusta perché:

  • È standardizzato. NIST SP 800-38D, usato in TLS 1.3, WireGuard, Signal, IPsec.
  • È veloce. Accelerato in hardware su ogni CPU prodotta nell’ultimo decennio.
  • Rileva le manomissioni. Se un server (o un attaccante) modifica la tua nota crittografata, la decrittografia fallisce subito. Non leggi mai un testo in chiaro corrotto.
  • È disponibile ovunque. Ne esistono implementazioni nel modulo crypto di Node.js, in SubtleCrypto nei browser, in libsodium, OpenSSL, nella libreria standard di Go, nel crate aes-gcm di Rust.

Per un’app di note, lo schema tipico è questo:

  1. La password dell’utente passa per una funzione di derivazione della chiave lenta (PBKDF2 o Argon2id) che produce una chiave principale: vedi KEK e FEK spiegate.
  2. Ogni nota (o ogni file) riceve una sua chiave dati casuale a 256 bit.
  3. La chiave dati crittografa la nota con AES-256-GCM, usando un nonce nuovo, casuale o basato su un contatore.
  4. La chiave dati stessa viene crittografata («avvolta») con la chiave principale, sempre con AES-256-GCM.

Questa architettura con una chiave per file fa sì che una sola chiave di file compromessa esponga un solo file, non l’intera cassaforte. Filarr fa diversamente: file e note sono crittografati direttamente con un’unica chiave dell’account, con un IV casuale nuovo ogni volta, e solo due formati derivano in più una chiave propria (i file grandi importati sul desktop e i blocchi sincronizzati): i parametri esatti sono nella pagina sull’architettura di sicurezza di Filarr.

Cosa verificare in un’app di note che promette «crittografia AES-256»

Quando un’app attenta alla privacy pubblicizza una crittografia AES-256, fatti queste domande:

  1. Quale modalità? Serve GCM o un’altra modalità autenticata. CBC semplice, ECB o «AES-256» senza modalità è un campanello d’allarme.
  2. Come viene derivata la chiave? Direttamente dalla password dell’utente? È sbagliato: le password hanno troppa poca entropia. Ci vuole una funzione di derivazione della chiave (PBKDF2, Argon2id, scrypt) con un numero di iterazioni documentato.
  3. Una chiave per file o una chiave globale? Le chiavi per file (o per nota) limitano i danni: una sola chiave compromessa non espone tutto.
  4. Come vengono generati i nonce? Contatore deterministico? Casuali, e con quanti bit? «Usiamo AES-GCM» senza disciplina sui nonce è fragile.
  5. Dov’è documentata la crittografia? Un’app seria pubblica il proprio modello di minaccia e il progetto della crittografia. Se non lo trovi, considerala crittografia da marketing.
  6. Il codice è verificabile? Le implementazioni open source permettono ai ricercatori di sicurezza di verificare le affermazioni. Un AES-256 a codice chiuso è una promessa, non una prova.

Come usa AES-256-GCM Filarr?

Filarr crittografa ogni file e ogni nota con AES-256-GCM con la chiave del tuo account. Il processo completo:

  • La tua password viene rafforzata con PBKDF2-SHA-512, 600.000 iterazioni (ben oltre le 210.000 raccomandate dall’OWASP per PBKDF2-SHA512) per produrre una Key Encryption Key (KEK)
  • Il tuo account, o il tuo profilo locale, ha un’unica File Encryption Key (FEK) casuale a 256 bit
  • Ogni file e ogni nota sono crittografati con AES-256-GCM con la FEK, con un IV casuale nuovo ogni volta; i file grandi importati sul desktop e i blocchi sincronizzati derivano in più dalla FEK una chiave propria (HKDF-SHA256 con un salt casuale)
  • La FEK è crittografata con la KEK, sempre con AES-256-GCM, e una seconda copia è avvolta con la tua frase di recupero

La KEK non esce mai in chiaro dalla tua macchina, e nemmeno la FEK. Se qualcuno rubasse lo storage della nostra sincronizzazione cloud, vedrebbe solo un flusso di blob crittografati che non può decrittografare: i nostri server conservano soltanto la tua chiave avvolta. Il limite noto si sta chiudendo: dal 16 ottobre 2026 l’accesso invia una chiave derivata sul tuo dispositivo, non la tua password; durante una transizione di circa due mesi, la password transita ancora verso i nostri server per un account che da allora non ha ancora effettuato di nuovo l’accesso, o da una vecchia versione dell’app, e in quel caso un server compromesso potrebbe intercettarla. Per l’architettura completa e il modello di minaccia, vedi il modello di sicurezza di Filarr.

Per approfondire

Articoli correlati