Leonard Adleman e RSA: come Internet ha imparato a fidarsi

Perché RSA conta per la fiducia quotidiana su Internet

Quando la gente dice di “fidarsi” di un sito o di un servizio online, di solito intende tre cose pratiche:

• Privacy: estranei non possono leggere i tuoi messaggi, password o dati di pagamento mentre viaggiano su Internet.
• Identità: stai davvero parlando con la tua banca (o quel negozio), non con un impostore.
• Integrità: ciò che ricevi non è stato modificato di nascosto—che si tratti di una pagina di login, di una richiesta di bonifico o di un aggiornamento software.

RSA è diventata famosa perché ha reso possibili queste promesse su scala internet.

Sistemi di tutti i giorni che RSA ha reso possibili

Hai avvertito l'impatto di RSA anche se non ne hai mai sentito il nome. È strettamente legata a come:

• HTTPS protegge molte connessioni tra il tuo browser e un sito (l'idea del “lucchetto”).
• Il banking online è passato da “forse è meglio non farlo su Internet” a qualcosa su cui milioni di persone fanno affidamento.
• Software firmato e aggiornamenti possono dimostrare di provenire dal vero editore e che non sono stati manomessi.

Il filo comune è la fiducia senza dover conoscere di persona (o accordarsi in anticipo con) ogni server e fornitore di software con cui interagisci.

Cosa aspettarsi da questa guida

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”.

L'idea chiave: due chiavi, due ruoli

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.

Il ruolo di Leonard Adleman nella svolta RSA

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.

Cosa portò Adleman al team

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.

Dove si colloca RSA nella storia della crittografia

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'impatto duraturo

L'influenza di RSA è più grande di un singolo algoritmo. Ha reso fattibili su larga scala due essenziali internet:

• Cifratura, per proteggere i dati in transito
• Firme digitali, per verificare che software e messaggi siano autentici

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.

Il problema base che RSA risolse: comunicare in modo sicuro senza segreti precondivisi

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.

Perché i segreti condivisi non scalano

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.

Due sconosciuti, una conversazione sicura

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.

Perché “basta criptare” non è sufficiente

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à:

• Riservatezza: gli estranei non possono leggere i dati.
• Autenticità: puoi verificare con chi stai parlando (e che i messaggi non sono stati manomessi).

RSA rese possibili entrambe le cose, gettando le basi di come funziona la fiducia online su larga scala.

Nozioni base sulla crittografia a chiave pubblica (senza gergo)

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.

Chiave pubblica vs chiave privata (in parole semplici)

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.

Due compiti principali: cifratura e firme digitali

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:

• è stata firmata dal titolare della chiave privata
• non è stata alterata dopo la firma

Perché funziona (senza equazioni)

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.

Come funziona RSA a grandi linee

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.

L'idea monodirezionale (con una trappola)

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.

Perché la fattorizzazione conta

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.

Il flusso di base

1. Generare le chiavi: il tuo dispositivo crea una coppia corrispondente: una chiave pubblica e una chiave privata.
2. Pubblicare la chiave pubblica: può essere condivisa apertamente—su un sito, in un certificato o in un'app.
3. Proteggere la chiave privata: deve rimanere segreta. Se viene divulgata, il “lucchetto” è rotto.

Un dettaglio pratico che molti trascurano

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.

Cifratura vs firme digitali: due compiti diversi

RSA è famosa perché può svolgere due compiti correlati—ma distinti—: cifratura e firme digitali. Confonderli è una fonte comune di fraintendimenti.

Tre obiettivi: confidenzialità, integrità, autenticità

• Confidenzialità significa “solo la persona destinataria può leggerlo.” Esempio: invii il numero di conto alla tua banca e non vuoi che altri lo vedano.
• Integrità significa “non è stato cambiato durante il tragitto.” Esempio: un attaccante non dovrebbe poter alterare “bonifico $50” in “bonifico $50.000.”
• Autenticità significa “proviene davvero da chi dice di provenire.” Esempio: vuoi sapere che un'email o un aggiornamento software proviene effettivamente dalla tua banca o da un fornitore fidato.

La cifratura mira principalmente alla confidenzialità. Le firme digitali mirano principalmente a integrità + autenticità.

RSA per la cifratura: proteggere un messaggio (o più spesso, una chiave)

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.

RSA per le firme: provare chi ha fatto qualcosa e che non è stato alterato

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:

• Proviene davvero dal titolare della chiave privata? (autenticità)
• È stato alterato dopo la firma? (integrità)

Perché le firme contano nella vita reale

Le firme digitali compaiono nei momenti quotidiani di “approvazione”:

• Approvare transazioni: una banca può firmare messaggi così la tua app può fidarsi delle istruzioni ricevute.
• Download: un installer firmato aiuta il tuo computer a verificare che provenga dal vero editore.
• Aggiornamenti: gli aggiornamenti firmati impediscono agli attaccanti di sostituire una versione con una malevola, anche se riescono a manomettere il canale di distribuzione.

La cifratura mantiene i segreti; le firme mantengono la fiducia.

RSA e HTTPS: cosa succede quando vedi il lucchetto

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.

Una handshake TLS semplificata (cosa fa davvero il browser)

Quando visiti un sito HTTPS, il browser e il server eseguono una conversazione di configurazione chiamata TLS handshake:

• Il server invia un certificato. Questo include la chiave pubblica del sito e il nome di dominio che dichiara.
• Il browser verifica l'identità. Controlla che il certificato sia valido per quel dominio, non scaduto e firmato da una Certificate Authority (CA) fidata.
• Vengono create chiavi di sessione. Una volta che il browser è convinto di parlare con la parte giusta, le due estremità concordano chiavi simmetriche temporanee per la sessione.

Dove entra RSA

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.

Perché i tuoi dati non sono cifrati con RSA

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.

Come HTTPS abilitato da RSA ha reso il banking online praticabile

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.

Ciò di cui le banche avevano bisogno dal web

Una sessione bancaria deve proteggere tre cose contemporaneamente:

• Login: la tua password (e altri segreti) non possono essere esposti in transito.
• Transazioni: importi e conti destinatari devono arrivare esattamente come li hai inviati.
• Dati personali: dettagli di conto, indirizzi e messaggi non devono essere leggibili da chi osserva la rete.

Senza HTTPS, chiunque sulla stessa Wi‑Fi, un router compromesso o un operatore di rete malevolo potrebbe potenzialmente intercettare o manomettere il traffico.

Come HTTPS ha reso la fiducia abbastanza solida

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:

• Gli attaccanti non possono leggere il tuo traffico (niente furto facile di password per intercettazione).
• Gli attaccanti non possono alterare silenziosamente le richieste (niente “cambia $50 in $5.000” in volo).

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.

Perché l'identità conta quanto la cifratura

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.

Strati extra (utili, non sostituti)

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.

Distribuzione sicura del software: perché gli aggiornamenti firmati contano

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.

L'attacco semplice: sostituire il pacchetto

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.

Firma del codice: dimostrare chi l'ha costruito (e che non è stato cambiato)

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.

Cosa significa per gli utenti comuni

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.

Certificati e PKI: come le chiavi pubbliche diventano affidabili

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à.

Certificate Authority: connettori di fiducia, non magia

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.

Scadenza e revoca: cosa succede quando le cose cambiano

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.

Consigli pratici per la gestione 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.

Limiti, rischi e fraintendimenti comuni su RSA

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.

Modalità comuni di fallimento (ciò che succede davvero)

Alcuni schemi ricorrono frequentemente:

• Chiavi deboli: usare chiavi RSA troppo corte o impostazioni obsolete abbassa il costo dell'attacco.
• Cattiva conservazione delle chiavi: chiavi private lasciate su server compromessi, incluse in backup o inserite in repository possono essere rubate senza che la crittografia venga violata.
• Phishing e compromissione degli endpoint: se un attaccante inganna una persona affinché approvi un accesso o installa malware su un dispositivo, RSA non può aiutare; la crittografia non risolve un endpoint compromesso.
• Certificati emessi in modo errato: se una CA emette il certificato sbagliato, gli utenti possono essere inviati a un attaccante pur vedendo HTTPS valido.

Perché la lunghezza della chiave e la casualità sono importanti

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.

RSA non è “troppo lento”, ma viene usato con giudizio

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.

Il fraintendimento più grande: “RSA da sola ti rende sicuro”

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 oggi: dove è ancora utile e cosa si usa spesso al suo posto

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.

Perché i sistemi si spostano oltre RSA

La crittografia evolve per le stesse ragioni di altre tecnologie di sicurezza:

• Velocità ed efficienza: le operazioni RSA possono essere relativamente lente e richiedere chiavi grandi. Metodi più nuovi offrono la stessa sicurezza con chiavi più piccole e handshake più veloci.
• Nuove minacce e margini di sicurezza: con il progredire della ricerca, la comunità rivaluta ciò che è più sicuro e più semplice da implementare correttamente.
• Design migliori per l'uso moderno: il web ora richiede connessioni rapide, prestazioni mobile e servizi su larga scala—spingendo gli standard verso algoritmi che soddisfano questi vincoli.

Cosa si usa insieme o al posto di RSA

Spesso vedrai alternative in TLS e nelle applicazioni moderne:

• ECDSA ed Ed25519 per le firme digitali (per dimostrare l'autenticità). Sono generalmente più veloci e usano chiavi più piccole rispetto a RSA.
• ECDH per lo scambio di chiavi (concordare un segreto condiviso per iniziare una sessione cifrata). Per questo motivo molte connessioni HTTPS non si basano più su RSA per il passo principale dello “stabilire il segreto”.

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.

Quindi… RSA è obsoleta?

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.