Leonard Adleman contribuì a creare RSA, un sistema a chiave pubblica che rese possibili HTTPS, il banking online e gli aggiornamenti firmati. Scopri come funziona e perché è importante.
Quando la gente dice di “fidarsi” di un sito o di un servizio online, di solito intende tre cose pratiche:
RSA è diventata famosa perché ha reso possibili queste promesse su scala internet.
Hai avvertito l'impatto di RSA anche se non ne hai mai sentito il nome. È strettamente legata a come:
Il filo comune è la fiducia senza dover conoscere di persona (o accordarsi in anticipo con) ogni server e fornitore di software con cui interagisci.
Questo articolo mantiene le spiegazioni semplici: niente matematica pesante, e nessuna necessità di un background in informatica. Ci concentreremo sul punto di vista quotidiano del “perché funziona”.
RSA ha reso popolare un approccio potente: invece di un segreto condiviso, si usa una chiave pubblica che puoi condividere apertamente e una chiave privata che rimane segreta. Questa separazione rende possibile proteggere la privacy e provare l'identità in situazioni dove persone e sistemi non si sono mai incontrati prima.
Leonard Adleman è la “A” di RSA, insieme a Ron Rivest e Adi Shamir. Mentre Rivest e Shamir sono spesso accreditati per la costruzione fondamentale, il contributo di Adleman è stato essenziale: ha aiutato a trasformare il sistema in qualcosa che non fosse solo intelligente, ma convincente—un algoritmo che le persone potevano analizzare, testare e di cui fidarsi.
Gran parte del ruolo di Adleman fu mettere l'idea sotto stress. In crittografia, uno schema non è prezioso perché sembra plausibile; è prezioso perché resiste ad attacchi e a un controllo accurato. Adleman lavorò sulla validazione, contribuì a perfezionare le assunzioni e partecipò alla definizione iniziale del motivo per cui RSA doveva essere difficile da rompere.
Ugualmente importante, aiutò a tradurre “questo potrebbe funzionare” in “questo è un sistema crittografico che altri possono valutare.” Quella chiarezza—rendere il design comprensibile alla comunità di ricerca più ampia—fu cruciale per l'adozione.
Prima di RSA, la comunicazione sicura dipendeva in genere dal fatto che entrambe le parti condividessero già una chiave segreta. Questo approccio funziona nei gruppi chiusi, ma non scala quando sconosciuti devono comunicare in modo sicuro (per esempio, un acquirente e un sito che si incontrano per la prima volta).
RSA cambiò quella storia popolarizzando un pratico sistema crittografico a chiave pubblica: puoi pubblicare una chiave che gli altri possono usare, mantenendo segreta una chiave privata separata.
L'influenza di RSA è più grande di un singolo algoritmo. Ha reso fattibili su larga scala due essenziali internet:
Queste idee stanno alla base del motivo per cui HTTPS, il banking online e gli aggiornamenti software firmati sono diventati aspettative normali e non eccezioni.
Prima di RSA, la comunicazione sicura significava per lo più crittografia a segreto condiviso: entrambe le parti dovevano possedere la stessa chiave segreta già in anticipo. Funziona per piccoli gruppi, ma fallisce rapidamente quando provi a offrire un servizio pubblico usato da milioni.
Se ogni cliente avesse bisogno di una chiave segreta unica per parlare con una banca, la banca dovrebbe generare, consegnare, memorizzare, ruotare e proteggere un numero enorme di segreti. La parte più difficile non è la matematica—è il coordinamento.
Come consegni in modo sicuro la chiave segreta a ogni persona? Spedirla per posta è lento e rischioso. Dirla al telefono può essere intercettato o soggetto a ingegneria sociale. Inviarla via Internet vanifica lo scopo, perché il canale è proprio ciò che stai cercando di proteggere.
Immagina due estranei—per esempio tu e un negozio online—che non si sono mai incontrati. Vuoi inviare un pagamento in modo sicuro. Con la cifratura a segreto condiviso, avresti bisogno di una chiave privata che entrambi conoscete già. Ma non la conoscete.
La svolta di RSA fu permettere comunicazioni sicure senza una condivisione preventiva di un segreto. Invece, puoi pubblicare una chiave (chiave pubblica) che chiunque può usare per proteggere un messaggio per te, mentre tieni un'altra chiave (chiave privata) che solo tu possiedi.
Anche se potessi criptare i messaggi, devi ancora sapere a chi stai criptando. Altrimenti un attaccante può impersonare la banca o il negozio, convincerti a usare la sua chiave e leggere o alterare tutto di nascosto.
Ecco perché la comunicazione sicura su Internet necessita di due proprietà:
RSA rese possibili entrambe le cose, gettando le basi di come funziona la fiducia online su larga scala.
La crittografia a chiave pubblica è un'idea semplice con grandi conseguenze: puoi chiudere qualcosa per qualcuno senza prima accordarti su un segreto condiviso. Questo è lo spostamento fondamentale che RSA rese pratico.
Pensa a una chiave pubblica come a una serratura che sei felice di dare a chiunque. Le persone la possono usare per proteggere un messaggio per te—o (nei sistemi di firma) per verificare che qualcosa provenga davvero da te.
Una chiave privata è ciò che devi tenere per te. È la chiave che apre ciò che è stato chiuso con la tua chiave pubblica, ed è anche ciò che ti permette di creare firme che solo tu puoi generare.
Insieme, la chiave pubblica e la chiave privata formano una coppia di chiavi. Sono correlate matematicamente, ma non sono intercambiabili. Condividere la chiave pubblica è sicuro perché conoscerla non dà a qualcuno un modo pratico per ricavarne la chiave privata.
Cifratura riguarda la privacy. Se qualcuno cripta un messaggio con la tua chiave pubblica, solo la tua chiave privata può decriptarlo.
Firme digitali riguardano fiducia e integrità. Se firmi qualcosa con la tua chiave privata, chiunque abbia la tua chiave pubblica può verificare due cose:
La sicurezza non è magia—si basa su problemi matematici difficili che sono facili da eseguire in una direzione e estremamente difficili da invertire con i computer attuali. Questa proprietà “monodirezionale” è ciò che rende sicuro condividere la chiave pubblica mantenendo potente la chiave privata.
RSA si basa su un'asimmetria semplice: è facile fare la matematica “in avanti” per chiudere qualcosa, ma estremamente difficile invertire quella matematica per aprirla—a meno che non si possieda un segreto speciale.
Pensa a RSA come a una specie di lucchetto matematico. Chiunque può usare la chiave pubblica per chiudere un messaggio. Ma solo chi possiede la chiave privata può aprirlo.
Ciò che rende possibile tutto questo è una relazione scelta con cura tra le due chiavi. Vengono generate insieme e, pur essendo correlate, non è realistico derivare la chiave privata guardando solo la chiave pubblica.
A un livello alto, RSA si basa sul fatto che moltiplicare grandi numeri primi è facile, ma tornare indietro—scoprire quali primi sono stati moltiplicati—è estremamente difficile quando i numeri sono enormi.
Per numeri piccoli la fattorizzazione è veloce. Per le dimensioni usate nelle chiavi RSA reali (migliaia di bit), i migliori metodi conosciuti richiedono ancora un tempo e risorse computazionali impraticabili. Questa proprietà “difficile da invertire” impedisce agli attaccanti di ricostruire la chiave privata.
RSA di solito non viene usata per criptare file grandi o messaggi lunghi direttamente. Piuttosto, protegge piccoli segreti—in particolare una chiave di sessione generata casualmente. Questa chiave di sessione poi cifra i dati reali usando algoritmi simmetrici più veloci, più adatti per il traffico in massa.
RSA è famosa perché può svolgere due compiti correlati—ma distinti—: cifratura e firme digitali. Confonderli è una fonte comune di fraintendimenti.
La cifratura mira principalmente alla confidenzialità. Le firme digitali mirano principalmente a integrità + autenticità.
Con la cifratura RSA, qualcuno usa la tua chiave pubblica per chiudere qualcosa in modo che solo la tua chiave privata possa aprirla.
In pratica, RSA viene spesso usata per proteggere un piccolo segreto, come una chiave di sessione casuale. Quella chiave poi cifra i dati in modo efficiente.
Con le firme RSA, la direzione si inverte: il mittente usa la sua chiave privata per creare una firma, e chiunque abbia la chiave pubblica può verificare:
Le firme digitali compaiono nei momenti quotidiani di “approvazione”:
La cifratura mantiene i segreti; le firme mantengono la fiducia.
Il lucchetto nel browser è una scorciatoia per un'idea: la tua connessione a quel sito è cifrata e (di solito) autenticata. Significa che altri sulla rete—per esempio qualcuno sulla Wi‑Fi pubblica—non possono leggere o modificare di nascosto ciò che il tuo browser e il sito si scambiano.
Non significa che il sito sia sicuro in ogni senso. Il lucchetto non può dirti se un negozio è onesto, se un download è malware, o se hai digitato il dominio giusto. Non garantisce neppure che il sito proteggerà i tuoi dati una volta arrivati ai loro server.
Quando visiti un sito HTTPS, il browser e il server eseguono una conversazione di configurazione chiamata TLS handshake:
Storicamente, RSA veniva spesso usata per scambiare la chiave di sessione (il browser cripta un segreto con la chiave pubblica del server). In molte configurazioni TLS moderne, RSA è usata principalmente per l'autenticazione tramite firme (provare che il server controlla la chiave privata), mentre lo scambio di chiave avviene con altri metodi.
RSA è ottimo per stabilire fiducia e proteggere piccoli pezzi di dati durante la configurazione, ma è lento rispetto alla crittografia simmetrica. Dopo l'handshake, HTTPS passa ad algoritmi simmetrici veloci per il caricamento delle pagine, i login e le operazioni bancarie.
Il banking online ha una promessa semplice: dovresti poter eseguire il login, vedere i saldi e trasferire denaro senza che qualcun altro apprenda le tue credenziali o modifichi di nascosto ciò che invii.
Una sessione bancaria deve proteggere tre cose contemporaneamente:
Senza HTTPS, chiunque sulla stessa Wi‑Fi, un router compromesso o un operatore di rete malevolo potrebbe potenzialmente intercettare o manomettere il traffico.
HTTPS (tramite TLS) protegge la connessione in modo che i dati tra browser e banca siano cifrati e con integrità verificata. In termini pratici, questo significa:
Il ruolo storico di RSA è stato cruciale perché ha aiutato a risolvere il problema del “primo contatto”: stabilire una sessione sicura su una rete insicura.
La sola cifratura non basta se stai cifrando verso la parte sbagliata. Il banking online funziona solo se il browser può dire che sta parlando con la vera banca, non con un sito impostore o con un man-in-the-middle.
Le banche aggiungono ancora MFA, controlli dei dispositivi e monitoraggio delle frodi. Questi riducono i danni quando le credenziali vengono rubate—ma non sostituiscono HTTPS. Funzionano meglio come misure di sicurezza aggiuntive su una connessione già privata e resistente alle manomissioni.
Gli aggiornamenti software sono tanto un problema di fiducia quanto tecnico. Anche se un'app è scritta con cura, un attaccante può mirare al passaggio di distribuzione—sostituendo un installer legittimo con uno modificato o inserendo un aggiornamento manomesso nel percorso tra l'editore e l'utente. Senza un modo affidabile per autenticare ciò che hai scaricato, “aggiornamento disponibile” può diventare un punto di ingresso semplice.
Se gli aggiornamenti sono protetti solo da un link di download, un attaccante che compromette un mirror, dirotta una connessione di rete o inganna un utente verso una pagina simile può fornire un file diverso con lo stesso nome. L'utente può installarlo normalmente e il danno può essere “silenzioso”: malware incluso nell'aggiornamento, backdoor aggiunte al programma o impostazioni di sicurezza indebolite.
La firma del codice usa la crittografia a chiave pubblica (incluso RSA in molti sistemi) per allegare una firma digitale a un installer o a un pacchetto di aggiornamento.
L'editore firma il software con una chiave privata. Il tuo dispositivo (o sistema operativo) verifica quella firma usando la chiave pubblica dell'editore—spesso fornita tramite una catena di certificati. Se anche un byte è cambiato, la verifica fallisce. Questo sposta la fiducia da “da dove l'ho scaricato?” a “posso verificare chi l'ha creato e che è integro?”
Nelle pipeline di distribuzione moderne, queste idee si estendono oltre gli installer ad API, artefatti di build e rollout di deployment. Ad esempio, piattaforme come Koder.ai (una piattaforma vibe-coding per spedire app web, backend e mobile da un'interfaccia chat) si basano ancora sulle stesse fondamenta: HTTPS/TLS per i dati in transito, gestione attenta dei certificati per domini personalizzati e workflow pratici di rollback (snapshot e punti di ripristino) per ridurre il rischio quando si pubblicano modifiche.
Gli aggiornamenti firmati riducono le opportunità di manomissione non rilevata. Gli utenti ricevono avvisi più chiari quando qualcosa non va e i sistemi di aggiornamento automatico possono rifiutare file alterati prima che vengano eseguiti. Non è una garanzia che il software sia privo di bug, ma è una forte difesa contro l'impersonificazione e le manipolazioni della supply chain.
Per approfondire come firme, certificati e verifica si incastrano, vedi /blog/code-signing-basics.
Se RSA ti dà una chiave pubblica, segue una domanda naturale: di chi è quella chiave?
Un certificato è la risposta di Internet. È un piccolo file firmato che collega una chiave pubblica a un'identità—come un nome di sito (example.com), un'organizzazione o un editore software. Pensalo come una carta d'identità per una chiave: dice “questa chiave appartiene a questo nome” e include dettagli come il proprietario del certificato, la chiave pubblica stessa e le date di validità.
I certificati contano perché sono firmati da qualcun altro. Quel “qualcun altro” è di solito una Certificate Authority (CA).
Una CA è una terza parte che verifica certe prove (che possono andare dal controllo del dominio fino a verifiche aziendali più approfondite) e poi firma il certificato. Il tuo browser o sistema operativo include una lista integrata di CA fidate. Quando visiti un sito via HTTPS, il tuo dispositivo usa quella lista per decidere se accettare l'affermazione del certificato.
Questo sistema non è perfetto: le CA possono sbagliare e gli attaccanti possono tentare di ingannarle o comprometterle. Ma crea una pratica catena di fiducia che funziona su scala globale.
I certificati scadono intenzionalmente. Durate brevi limitano i danni se una chiave viene rubata e incoraggiano manutenzione regolare.
I certificati possono anche essere revocati prima della scadenza. La revoca è un modo per dire “smettetela di fidarvi di questo certificato”, per esempio se una chiave privata è stata compromessa o il certificato è stato emesso per errore. I dispositivi possono controllare lo stato di revoca (con vari gradi di affidabilità e rigore), il che è una ragione in più per curare l'igiene delle chiavi.
Tieni la tua chiave privata privata: conservala in archivi sicuri, limita l'accesso ed evita di copiarla tra sistemi a meno che non sia necessario.
Ruota le chiavi quando serve—dopo un incidente, durante aggiornamenti pianificati o per requisiti di policy. E tieni traccia delle scadenze in modo che i rinnovi non diventino emergenze dell'ultimo minuto.
RSA è un'idea fondamentale, ma non è uno scudo magico. La maggior parte delle compromissioni reali non avviene perché qualcuno “ha rotto RSA”—avviene perché i sistemi intorno a RSA falliscono.
Alcuni schemi ricorrono frequentemente:
La sicurezza di RSA dipende dalla generazione di chiavi abbastanza grandi e veramente imprevedibili. Una buona casualità è essenziale: se la generazione delle chiavi usa una fonte di numeri casuali debole, gli attaccanti possono talvolta riprodurre o restringere le possibili chiavi. Allo stesso modo, la lunghezza della chiave conta perché i progressi nel calcolo e nelle tecniche matematiche riducono progressivamente il margine di sicurezza per chiavi piccole.
Le operazioni RSA sono più pesanti rispetto ad alternative moderne, motivo per cui molti protocolli usano RSA con parsimonia—spesso per autenticazione o per scambiare un segreto temporaneo, quindi passano a crittografia simmetrica più veloce per i dati veri e propri.
La sicurezza funziona meglio come difesa in profondità: proteggi le chiavi private (idealmente in hardware), monitora le emissioni dei certificati, patcha i sistemi, usa autenticazione resistente al phishing e progetta rotazioni sicure delle chiavi. RSA è uno strumento nella catena—non l'intera catena.
RSA è uno degli strumenti crittografici più supportati su Internet. Anche se un servizio non “preferisce” più RSA, spesso mantiene la compatibilità perché è ovunque: dispositivi più vecchi, sistemi enterprise di lunga durata e infrastrutture di certificati costruite negli anni.
La crittografia evolve per le stesse ragioni di altre tecnologie di sicurezza:
Spesso vedrai alternative in TLS e nelle applicazioni moderne:
In parole povere: RSA può fare sia cifratura sia firme, ma i sistemi più nuovi spesso separano il lavoro—usando un metodo ottimizzato per le firme e un altro per stabilire le chiavi di sessione.
No. RSA è ancora ampiamente supportata e resta una scelta valida in molti contesti, specialmente dove la compatibilità è cruciale o dove le pratiche di gestione di chiavi e certificati sono già costruite attorno ad essa. L'opzione “migliore” dipende da fattori come il supporto dei dispositivi, le esigenze di performance, requisiti di conformità e come le chiavi vengono archiviate e ruotate.
Se vuoi vedere come queste scelte si manifestano nelle connessioni HTTPS reali, il passo successivo è: /blog/ssl-tls-explained.
RSA ha reso praticabile la fiducia a scala internet permettendo la crittografia a chiave pubblica, che fornisce:
Questi mattoni sono centrali per HTTPS, il banking online e gli aggiornamenti firmati.
Leonard Adleman contribuì a trasformare RSA da un'idea intelligente in un sistema crittografico che altri potevano analizzare e fidarsi. Praticamente, questo significò mettere sotto pressione le assunzioni, affinare la presentazione e rafforzare l'argomentazione sul perché rompere RSA sarebbe stato difficile in scenari d'attacco realistici.
Una chiave pubblica è pensata per essere condivisa; le persone la usano per criptare qualcosa per te o per verificare le tue firme.
Una chiave privata deve rimanere segreta; viene usata per decriptare ciò che è stato criptato per te (nelle configurazioni di cifratura RSA) e per creare firme che solo tu puoi produrre.
Se la chiave privata viene compromessa, gli attaccanti possono impersonarti e/o decifrare segreti protetti a seconda dell'uso della chiave.
La sicurezza di RSA si basa (a alto livello) su un problema matematico unidirezionale: moltiplicare grandi numeri primi è facile, ma fattorizzare il numero risultante per ritrovare i fattori primi è estremamente difficile alle dimensioni reali delle chiavi.
Le chiavi pubblica e privata sono correlate matematicamente, ma la relazione è progettata in modo che la chiave pubblica non riveli in modo pratico la chiave privata.
Risolvono obiettivi di fiducia diversi:
Una regola pratica: la cifratura mantiene i segreti; le firme dimostrano chi ha inviato qualcosa e che non è stato alterato.
In un flusso TLS/HTTPS semplificato:
RSA può essere impiegata per e storicamente veniva anche usata per proteggere il segreto di sessione in alcune configurazioni.
No. Il lucchetto indica principalmente che la connessione è crittografata e tipicamente autenticata.
Non garantisce che:
Considera HTTPS come una misura necessaria per la sicurezza del trasporto, non come un verdetto totale di fiducia.
Un certificato lega una chiave pubblica a un'identità (come un nome di dominio). I browser si fidano di questo legame perché una Certificate Authority (CA) firma il certificato e i browser/OS includono una lista di CA fidate.
Se distribuisci servizi, prevedi:
Gli aggiornamenti firmati permettono al tuo dispositivo di verificare due cose:
Questo difende contro attacchi di tipo “swap the package” (mirror compromessi, reti dirottate, pagine di download imitazione). Per un approfondimento, vedi /blog/code-signing-basics.
I fallimenti reali sono spesso operativi, non matematici:
Azioni pratiche: proteggi le chiavi private (meglio se in hardware protetto), monitora le scadenze, ruota le chiavi con criterio e controlla le emissioni dei certificati quando possibile.
