AES, RSA e ECC a confronto: quale algoritmo scegliere | Meteora Web • Meteora Web Agency

Vi è mai capitato di dover scegliere tra AES, RSA o ECC e sentirvi come davanti a un menu in cinese? Succede anche a clienti che gestiscono dati sensibili. Noi, di Meteora Web, lavoriamo ogni giorno con la crittografia — su server, app, database. E la domanda non è "qual è il migliore", ma "qual è il giusto per il tuo caso". In questa guida confrontiamo i tre grandi nomi della crittografia moderna: simmetrica, asimmetrica classica, asimmetrica a curve ellittiche. Tutto con esempi pratici, codice funzionante e la solita schiettezza.

Symmetric vs Asymmetric: la differenza che conta

Prima di parlare di singoli algoritmi, serve chiarezza sui due mondi. La crittografia simmetrica usa la stessa chiave per cifrare e decifrare. È veloce, efficiente, ma il problema è lo scambio della chiave. La crittografia asimmetrica usa una coppia di chiavi (pubblica e privata): risolve lo scambio, ma è più lenta. Nella pratica si usano entrambe: la asimmetrica per scambiare una chiave di sessione, poi la simmetrica per cifrare il grosso dei dati. TLS fa esattamente questo.

AES è il re della simmetrica. RSA ed ECC sono i due giganti dell'asimmetrica. Vediamoli uno per uno.

AES (Advanced Encryption Standard)

AES è un cifrario a blocchi con chiavi da 128, 192 o 256 bit. È lo standard mondiale, usato dal governo USA (NSA incluso) per informazioni classificate. Non ci sono backdoor note, non ci sono vulnerabilità pratiche se usato correttamente.

Modalità di funzionamento

AES da solo cifra blocchi da 16 byte. Per messaggi più lunghi servono modalità di operazione. Le più comuni:

ECB: sconsigliata. Stessi blocchi danno stesso ciphertext, visibile a occhio. Non usatela mai.
CBC: meglio, ma richiede padding e IV, non fornisce autenticazione.
GCM: la scelta moderna. Cifra e autentica in unico passaggio, con IV casuale. No padding. Ideale per TLS e file.

Dove si usa

File encrypt (BitLocker, LUKS), database (MySQL TDE, MongoDB Encryption at Rest), VPN (IPsec), comunicazioni (TLS). Se parliamo di memorizzare dati sensibili, AES-256-GCM è la via.

Esempio pratico in Python

from Crypto.Cipher import AES
from Crypto.Random import get_random_bytes

key = get_random_bytes(32)  # AES-256
cipher = AES.new(key, AES.MODE_GCM)
ciphertext, tag = cipher.encrypt_and_digest(b"Messaggio segreto")
nonce = cipher.nonce
# Per decifrare:
cipher_dec = AES.new(key, AES.MODE_GCM, nonce=nonce)
plaintext = cipher_dec.decrypt_and_verify(ciphertext, tag)

RSA (Rivest–Shamir–Adleman)

RSA è il nonno dell'asimmetrica. La sicurezza si basa sulla difficoltà di fattorizzare numeri grandi. Più la chiave è lunga, più è sicura (ma più lenta). Oggi si usano 2048 o 4096 bit. RSA è ancora ovunque: nelle firme digitali, nei certificati HTTPS, in SSH, PGP.

Punti di forza

Standardizzato da decenni, librerie mature.
Funziona sia per cifratura che per firma.
Non richiede curve speciali o hardware specifico.

Punti deboli

Chiavi lunghe (4096 bit sono ~1 KB di dati) e operazioni lente.
Non adatto a dispositivi embedded o IoT.
Vulnerabile al quantum computing (Shor's algorithm rompe la fattorizzazione).

Esempio pratico in Python

from Crypto.PublicKey import RSA
from Crypto.Cipher import PKCS1_OAEP

key = RSA.generate(2048)
public_key = key.publickey()

cipher = PKCS1_OAEP.new(public_key)
encrypted = cipher.encrypt(b"Messaggio per Bob")

cipher_dec = PKCS1_OAEP.new(key)
plaintext = cipher_dec.decrypt(encrypted)

Nota: RSA non può cifrare più della lunghezza della chiave. Ecco perché nei protocolli reali si usa per cifrare una chiave AES di sessione (ibrida).

ECC (Elliptic Curve Cryptography)

ECC è la versione moderna della crittografia asimmetrica. Si basa sul logaritmo discreto su curve ellittiche. Il vantaggio: chiavi molto più corte a parità di sicurezza. Una chiave ECC da 256 bit offre sicurezza equivalente a RSA 3072 bit. Questo significa performance migliori, meno banda, minore consumo di batteria.

Curve più diffuse

secp256r1 (P-256): standard NIST, usata in TLS, SSH, Bitcoin.
Curve25519 (X25519): più veloce, resistente a side-channel, usata in Signal, WireGuard, TLS 1.3 (ECDHE).
secp384r1, secp521r1: per sicurezza ultra-high.

Dove si usa

ECDH (key exchange), ECDSA (firme digitali) — ovunque. Le criptovalute (Bitcoin, Ethereum) usano ECDSA con secp256k1. Gli smartphone moderni, le smart card, i browser. ECC sta diventando lo standard de facto per l'asimmetrica.

Esempio pratico in Python (ECDSA firma)

from Crypto.Signature import DSS
from Crypto.Hash import SHA256
from Crypto.PublicKey import ECC

key = ECC.generate(curve='P-256')
message = b"Transazione da firmare"
h = SHA256.new(message)
signer = DSS.new(key, 'fips-186-3')
signature = signer.sign(h)

# Verifica
pub_key = key.public_key()
verifier = DSS.new(pub_key, 'fips-186-3')
try:
    verifier.verify(h, signature)
    print("Firma valida")
except ValueError:
    print("Firma non valida")

Confronto: AES vs RSA vs ECC

Caratteristica	AES	RSA	ECC
Tipo	Simmetrica	Asimmetrica	Asimmetrica
Lunghezza chiave (bit)	128, 256	2048, 4096	256, 384
Velocità cifratura	Altissima	Lenta	Media
Velocità firma	N/A	Lenta	Veloce
Scambio chiave	N/A	Sì (ma lento)	Sì (ECDH veloce)
Resistenza post-quantum	No (ma chiave lunga aiuta)	No	No
Casi d'uso tipici	Dati a riposo, trasporto	Firme, certificati legacy	Moderno web, mobile, IoT

Quando usare cosa – regole pratiche

Ecco come ragioniamo noi su ogni progetto:

Se devi cifrare file o database statici: AES-256-GCM. Non serve asimmetrica. Fine.
Se devi scambiare una chiave o fare un handshake: ECDH con Curve25519 (X25519). Evita RSA se puoi.
Se devi firmare un messaggio o un certificato: ECDSA con P-256 o Ed25519. Per retrocompatibilità con vecchi sistemi, RSA ancora ok.
Se hai vincoli legacy (certificati X.509 vecchi, CA che usano RSA): tieniti RSA 2048 o 4096, ma inizia a pianificare la migrazione.
Se progetti un sistema per il 2030: guarda già alla crittografia post-quantum (CRYSTALS-Kyber, Dilithium). RSA e ECC classici saranno rotti da computer quantistici abbastanza grandi.

In sintesi – cosa fare adesso

Controlla la tua applicazione: che crittografia usa? Se sta ancora usando RSA per cifrare dati bulk, o AES in modo ECB, hai un problema. Cambia subito.
Migra a ECC dove possibile: per le nuove comunicazioni, usa TLS 1.3 con curve X25519 e firme Ed25519. È più veloce, più sicuro, più sostenibile.
Non implementare mai la crittografia da zero. Usa librerie consolidate (PyCryptodome, OpenSSL, libsodium). Il codice sopra è didattico, ma in produzione usa funzioni di alto livello.
Testa la tua implementazione. Strumenti come Kali Linux possono aiutare a verificare che il tuo server accetti solo cifrari forti.
Proteggi anche il fattore umano. La crittografia non serve a nulla se l'utente casca in un phishing. Formazione e policy vanno di pari passo.