Symmetric Encryption

Mappa Globale — Symmetric Encryption

#

Symmetric vs Asymmetric

#

La crittografia simmetrica usa la stessa chiave per cifrare e decifrare. Il vantaggio principale e' la velocita': e' ordini di grandezza piu' rapida di quella asimmetrica, rendendola ideale per cifrare grandi volumi di dati. Il limite fondamentale e' il key distribution problem: come consegni la chiave al destinatario senza un canale sicuro preesistente?

La soluzione adottata da tutti i protocolli moderni (TLS, IPsec, WireGuard) e' ibrida: si usa la crittografia asimmetrica per scambiare la chiave simmetrica in modo sicuro, poi tutto il traffico dati viaggia cifrato simmetricamente. TLS 1.3 fa esattamente questo: il processo di handshake e' asincrono (ECDHE), ma i dati della sessione viaggiano con AES-256-GCM.

Mappa — Key Distribution Problem

#

Stream Cipher vs Block Cipher

#

I due paradigmi fondamentali della crittografia simmetrica differiscono nel modo in cui trattano i dati: i block cipher lavorano su blocchi di dimensione fissa, i stream cipher processano i dati un bit o byte alla volta.

flowchart LR
    subgraph BLOCK["Block Cipher (AES)"]
        direction TB
        B1["Plaintext\n128 bit"] --> B2["AES Engine"] --> B3["Ciphertext\n128 bit"]
        B4["Padding se dati < 128 bit"]
    end

    subgraph STREAM["Stream Cipher (ChaCha20)"]
        direction TB
        S1["Key + Nonce"] --> S2["Keystream\ngenerator"] --> S3["XOR"]
        S4["Plaintext"] --> S3
        S3 --> S5["Ciphertext"]
    end

    BLOCK ~~~ STREAM

Block cipher: cifra blocchi di dimensione fissa. AES usa blocchi da 128 bit. Se i dati non sono un multiplo esatto del blocco, vanno paddati (PKCS#7 e' il padding piu' comune). Piu' sicuro contro attacchi statistici se usato con la modalita' operativa corretta.

Stream cipher: genera un keystream pseudorandom (partendo da chiave + nonce) e lo combina con il plaintext tramite XOR. Nessuna necessita' di padding. Ideale per dati continui come VoIP o streaming. Esempio moderno: ChaCha20 (usato in TLS 1.3 come alternativa ad AES su CPU senza AES-NI).

Oggi la distinzione pratica e' quasi scomparsa: AES in modalita' CTR o GCM si comporta come uno stream cipher, unendo la sicurezza provata di AES alla flessibilita' degli stream.

AES (Advanced Encryption Standard)

#

AES e' l'algoritmo di cifratura simmetrica dominante da oltre vent'anni. Scelto da NIST nel 2001 per sostituire DES attraverso un concorso pubblico, non ha vulnerabilita' pratiche note ed e' considerato sicuro per i prossimi decenni.

flowchart LR
    subgraph AES_VARIANTS["Varianti AES"]
        direction LR
        A1["AES-128\n10 round\nuso generale"]
        A2["AES-192\n12 round\nmeno comune"]
        A3["AES-256\n14 round\ndati classificati\ndisk encryption\nVPN"]
    end

    BLOCK["Block size:\n128 bit\n(sempre fisso)"] --- AES_VARIANTS

AES-NI trasforma AES da operazione software a operazione hardware: su CPU moderne, AES-256-GCM raggiunge throughput di 10+ GB/s con overhead trascurabile. Questo elimina l'argomento storico di performance a favore di algoritmi piu' deboli.

Dev parallel: In PHP openssl_encrypt($data, 'aes-256-gcm', $key, OPENSSL_RAW_DATA, $iv, $tag) -- il parametro $tag e' il tag di autenticazione a 16 byte che devi conservare insieme al ciphertext. In Node: crypto.createCipheriv('aes-256-gcm', key, iv). Mai usare 'aes-256-ecb' -- ECB e' disponibile nell'API ma insicuro per definizione.

Mappa — AES in pratica

#

3DES (Triple DES)

#

3DES e' un'estensione di DES progettata per prolungarne la vita applicando l'algoritmo tre volte in sequenza. Oggi e' considerato obsoleto e non va mai usato in nuovo codice.

La struttura EDE (Encrypt-Decrypt-Encrypt) con tre chiavi diverse era un compromesso ingegnoso: risultava compatibile con DES originale (se K1=K2=K3) e aumentava la sicurezza effettiva. Il problema e' strutturale: la dimensione del blocco a 64 bit (8 byte) lo rende vulnerabile all'attacco SWEET32 dopo circa 32 GB di traffico sulla stessa chiave.

Dev parallel: Se erediti codice PHP legacy con mcrypt_encrypt('tripledes', ...) o openssl_encrypt(..., '3des-cbc', ...), e' una bandiera rossa da segnalare subito. La migrazione verso AES-256-GCM e' obbligatoria per qualsiasi sistema che gestisce dati sensibili.

Modalita' Operative

#

Le modalita' operative definiscono come un block cipher applica la cifratura a sequenze di dati piu' lunghe di un blocco. La scelta della modalita' e' critica quanto la scelta dell'algoritmo: ECB e CBC sono fondamentalmente diversi da GCM in termini di proprieta' di sicurezza.

flowchart TD
    subgraph ECB_NODE["ECB"]
        E1["P1"] --> EA1["AES(K)"] --> EC1["C1"]
        E2["P2"] --> EA2["AES(K)"] --> EC2["C2"]
    end

    subgraph CBC_NODE["CBC"]
        IV1["IV"] --> XB1["XOR"]
        CB1["P1"] --> XB1 --> BA1["AES(K)"] --> CC1["C1"]
        CC1 --> XB2["XOR"]
        CB2["P2"] --> XB2 --> BA2["AES(K)"] --> CC2["C2"]
    end

    subgraph CTR_NODE["CTR"]
        CTR1["Nonce||0"] --> CA1["AES(K)"] --> XC1["XOR"] --> CD1["C1"]
        CP1["P1"] --> XC1
        CTR2["Nonce||1"] --> CA2["AES(K)"] --> XC2["XOR"] --> CD2["C2"]
        CP2["P2"] --> XC2
    end

    ECB_NODE ~~~ CBC_NODE ~~~ CTR_NODE

ECB (Electronic Codebook)

#

Ogni blocco viene cifrato indipendentemente con la stessa chiave. E' la modalita' piu' semplice e la piu' pericolosa: blocchi di plaintext identici producono blocchi di ciphertext identici, rendendo visibili i pattern statistici nei dati. Il famoso ECB penguin problem mostra come un'immagine cifrata con ECB mantenga i contorni dell'immagine originale. Non usare mai in produzione.

CBC (Cipher Block Chaining)

#

Ogni blocco di plaintext viene combinato via XOR con il ciphertext del blocco precedente prima di essere cifrato. Il primo blocco usa un Initialization Vector (IV) random. Questo elimina il problema dei pattern ma introduce dipendenza sequenziale: la cifratura non e' parallelizzabile. CBC su TLS 1.0/1.1 e' vulnerabile a BEAST (2011) e POODLE (2014) -- TLS 1.3 ha eliminato CBC.

CTR (Counter Mode)

#

Un counter progressivo viene cifrato e il risultato fa da keystream, poi XOR con il plaintext. Trasforma AES in uno stream cipher. Completamente parallelizzabile e supporta random access (puoi decifrare il blocco N senza decifrare i blocchi precedenti). Non fornisce autenticazione integrata.

GCM (Galois/Counter Mode)

#

GCM combina CTR con GMAC (Galois Message Authentication Code) in un'unica operazione. Appartiene alla categoria AEAD (Authenticated Encryption with Associated Data): cifra e autentica simultaneamente, rendendo impossibile modificare il ciphertext senza essere rilevati. E' il default in TLS 1.3, IPsec ESP e WireGuard.

Dev parallel: Con GCM non basta conservare il ciphertext -- devi conservare anche il nonce (IV, 12 byte) e il tag di autenticazione (16 byte). Se il tag non corrisponde al momento della decifrazione, l'operazione fallisce con un errore esplicito. Questo e' un vantaggio: il tampering viene rilevato automaticamente, a differenza di CBC dove un attacco padding oracle puo' passare inosservato. MAI riusare lo stesso nonce con la stessa chiave in GCM -- e' un fallimento catastrofico che compromette sia la confidenzialita' che l'autenticazione.

CCM (Counter with CBC-MAC)

#

Alternativa a GCM per ambienti resource-constrained. Usato in 802.11i (WPA2-CCMP) e alcuni protocolli IoT. Meno performante di GCM su hardware con AES-NI, ma piu' adatto a microcontrollori a basso consumo.

Tabella Comparativa

#

Collegato a

#

• asymmetric-encryption -- risolve il key distribution problem di symmetric
• ssl-tls -- usa AES-256-GCM per i dati della sessione dopo handshake ECDHE
• cryptography -- panoramica dei servizi crittografici (integrita', confidenzialita', non-repudiation)
• hashing -- complementare: hashing per integrita', cifratura per confidenzialita'
• kms -- gestione sicura delle chiavi AES in ambienti cloud
• tpm-hsm -- hardware che protegge fisicamente le chiavi simmetriche
• vpn-ipsec -- IPsec ESP usa AES-256-GCM per cifrare i payload
• wireless-security -- WPA2-CCMP usa AES-CCM, WPA3 usa AES-GCM