Esplora le idee fondamentali di Adi Shamir su RSA e la condivisione segreta, e scopri come una matematica elegante modella la sicurezza reale, i rischi e la gestione delle chiavi.
Adi Shamir è uno dei rari ricercatori le cui idee non sono rimaste confinate a paper e conferenze: sono diventate i mattoni della sicurezza quotidiana. Se hai mai usato HTTPS, verificato un aggiornamento software o fatto affidamento su una firma digitale per fidarti online, hai beneficiato di lavori a cui lui ha contribuito.
Shamir è co‑autore di RSA, un sistema a chiave pubblica che ha reso pratico per estranei scambiarsi messaggi sicuri e provare identità su scala. Ha anche creato la Condivisione Segreta di Shamir, un metodo per dividere un segreto (come una chiave crittografica) in pezzi in modo che nessuna singola persona o server abbia il controllo completo.
Entrambe le idee condividono un tema: un'intuizione matematica pulita può sbloccare una capacità di sicurezza pratica che le organizzazioni possono effettivamente distribuire.
Questo articolo si concentra su quel ponte: dai concetti eleganti agli strumenti che supportano sistemi reali. Vedrai come RSA ha reso possibili firme e comunicazioni sicure, e come la condivisione segreta aiuta i team a distribuire la fiducia con regole “k-of-n” (per esempio, qualsiasi 3 su 5 detentori di chiavi possono approvare un'azione critica).
Spiegheremo le idee di base senza equazioni pesanti o teoria dei numeri avanzata. L'obiettivo è la chiarezza: capire cosa questi sistemi cercano di ottenere, perché i progetti sono intelligenti e dove si trovano i punti critici.
Ci sono però dei limiti. Una matematica forte non garantisce automaticamente una forte sicurezza. I fallimenti reali spesso derivano da errori di implementazione, cattiva gestione delle chiavi, procedure operative deboli o assunzioni irrealistiche sulle minacce. Il lavoro di Shamir ci aiuta a vedere entrambi i lati: il potere di un buon design crittografico e la necessità di un'esecuzione pratica e attenta.
Una vera svolta crittografica non è solo “abbiamo reso la crittografia più veloce.” È una nuova capacità che cambia ciò che le persone possono fare in modo sicuro. Pensala come l'ampliamento dell'insieme di problemi che gli strumenti di sicurezza possono risolvere—specialmente su scala, tra estranei e sotto vincoli del mondo reale come reti inaffidabili e errori umani.
I classici “codici segreti” si concentrano sul nascondere un messaggio. La crittografia moderna mira più in grande e in modo più pratico:
Questo cambiamento è importante perché molti fallimenti non riguardano l'intercettazione: riguardano manomissioni, impersonificazioni e dispute su “chi ha fatto cosa”.
Con la crittografia simmetrica, entrambe le parti condividono la stessa chiave segreta. È efficiente ed è ancora molto usata (per esempio, per cifrare grandi file o traffico di rete). La parte difficile è pratica: come fanno due parti a condividere in modo sicuro quella chiave—soprattutto se non si sono mai incontrate?
La crittografia a chiave pubblica divide la chiave in due parti: una chiave pubblica che puoi condividere apertamente e una chiave privata che conservi segreta. Le persone possono cifrare messaggi per te usando la tua chiave pubblica e solo la tua chiave privata può decifrarli. Oppure puoi firmare qualcosa con la tua chiave privata in modo che chiunque possa verificarla con la tua chiave pubblica.
Quando le chiavi pubbliche sono diventate pratiche, la comunicazione sicura ha smesso di richiedere un segreto precondiviso o un corriere fidato. Questo ha abilitato sistemi sicuri su scala internet: login protetti, traffico web cifrato, aggiornamenti software verificabili e firme digitali che supportano identità e responsabilità.
Questo è il tipo di “nuova capacità” che merita l'etichetta di svolta.
RSA ha una delle migliori storie d'origine in crittografia: tre ricercatori—Ron Rivest, Adi Shamir e Leonard Adleman—che cercavano di trasformare un'idea nuova (crittografia a chiave pubblica) in qualcosa di realmente utilizzabile.
Nel 1977 pubblicarono uno schema che divenne rapidamente la risposta pratica più famosa alla semplice domanda: “Come possono due persone comunicare in modo sicuro senza condividere prima un segreto?” I loro nomi formarono l'acronimo.
Lo spostamento concettuale di RSA è facile da descrivere in termini quotidiani. Puoi pubblicare un lucchetto che chiunque può usare (la tua chiave pubblica), mentre tieni per te l'unica chiave che lo apre (la tua chiave privata).
Quindi se qualcuno vuole inviarti un messaggio segreto, non ha bisogno di incontrarti prima. Prende il tuo lucchetto pubblico, lo mette sul messaggio e lo invia. Solo tu possiedi la chiave privata che può aprirlo.
Quella promessa “pubblica il lucchetto, nascondi la chiave” è il motivo per cui RSA sembrava magico all'epoca—e perché è diventato fondamentale per i sistemi sicuri.
RSA si basa su un tipo speciale di puzzle:
In RSA, la chiave pubblica permette a chiunque di “mescolare i colori” per proteggere un messaggio, mentre la chiave privata è la ricetta nascosta che rende fattibile l'operazione inversa.
RSA appare in alcuni ruoli chiave:
Anche se strumenti più recenti sono diventati popolari, l'idea semplice di RSA—lucchetto pubblico, chiave privata—spiega ancora molto su come si costruisce la fiducia moderna su internet.
RSA sembra misterioso fino a quando non si guarda a due idee quotidiane: far ruotare i numeri attorno a un intervallo fissato e fare affidamento su un problema che sembra estremamente lento da invertire.
L'aritmetica modulare è quello che succede quando i numeri “ricominciano da capo”, come le ore dell'orologio. In un orologio a 12 ore, 10 + 5 non dà 15; arriva alle 3.
RSA usa la stessa idea di avvolgimento, solo con un “orologio” molto più grande. Si sceglie un numero grande (detto modulo) e si fanno calcoli i cui risultati sono sempre ridotti nel range da 0 fino al modulo meno 1.
Perché questo conta: l'aritmetica modulare ti permette di eseguire operazioni facili in una direzione, mantenendo difficile il percorso inverso—esattamente il tipo di asimmetria che serve in crittografia.
La crittografia spesso dipende da un compito che:
Per RSA, l'“informazione speciale” è la chiave privata. Senza di essa, l'attaccante affronta un problema ritenuto estremamente costoso.
La sicurezza di RSA si basa sulla difficoltà della fattorizzazione: prendere un numero grande e trovare i due grandi numeri primi che sono stati moltiplicati per crearlo.
Moltiplicare due grandi primi è semplice. Ma se qualcuno ti dà soltanto il prodotto e ti chiede i primi originali, quel passo inverso sembra richiedere uno sforzo enorme man mano che i numeri crescono.
Questa difficoltà di fattorizzazione è la ragione principale per cui RSA può funzionare: le informazioni pubbliche sono sicure da condividere, mentre la chiave privata resta pratica da usare ma difficile da ricostruire.
RSA non è protetto da una prova matematica che la fattorizzazione sia impossibile. È protetto da decenni di evidenze: ricercatori intelligenti hanno provato molti approcci e i migliori metodi noti restano troppo lenti con dimensioni adeguate.
Questo è ciò che significa “presunto difficile”: non garantito per sempre, ma affidabile perché romperlo efficientemente richiederebbe una scoperta nuova e importante.
La dimensione della chiave controlla quanto è grande quell'“orologio” modulare. Chiavi più grandi rendono generalmente la fattorizzazione molto più costosa, spingendo gli attacchi oltre tempi e budget realistici. Ecco perché chiavi RSA più corte sono state pensionate e perché la scelta della lunghezza della chiave è, in pratica, una scelta sullo sforzo richiesto agli avversari.
Le firme digitali rispondono a una domanda diversa rispetto alla cifratura. La cifratura protegge il segreto: “Solo il destinatario può leggere questo?” Una firma protegge la fiducia: “Chi ha creato questo, ed è stato modificato?”
Una firma digitale tipicamente prova due cose:
Con RSA, il firmatario usa la sua chiave privata per produrre un piccolo blocco di dati—la firma—legato al messaggio. Chiunque abbia la chiave pubblica corrispondente può verificarla.
Importante: non si “firma direttamente l'intero file”. In pratica, i sistemi firmano un hash (un'impronta compatta) del file. Per questo la firma funziona tanto per un messaggio piccolo quanto per un download di più gigabyte.
Le firme RSA sono usate ovunque i sistemi debbano verificare l'identità su scala:
Fare la matematica RSA da soli non basta. Le firme RSA reali si basano su regole standardizzate di padding e codifica (come PKCS#1 o RSA-PSS). Pensale come guide che prevengono attacchi sottili e rendono le firme inequivocabili.
Puoi cifrare senza provare chi ha inviato il messaggio, e puoi firmare senza nascondere il messaggio. Molti sistemi sicuri fanno entrambe le cose, ma risolvono problemi diversi.
RSA è un'idea solida, ma la maggior parte dei “break” nel mondo reale non sconfiggono la matematica di base. Sfruttano le parti disordinate attorno ad essa: come le chiavi sono generate, come i messaggi sono riempiti (padding), come si comportano i dispositivi e come le persone gestiscono i sistemi.
Quando i titoli dicono “RSA crackato”, spesso la storia riguarda un errore di implementazione o una scorciatoia di deployment. RSA raramente è usato come “RSA grezzo” oggi; è incapsulato in protocolli, avvolto in schemi di padding e combinato con hashing e casualità. Se uno di questi pezzi è sbagliato, il sistema può cadere anche se l'algoritmo centrale resta valido.
Ecco il tipo di gap che causa incidenti ripetuti:
Le librerie crittografiche moderne e gli standard esistono perché le squadre hanno imparato queste lezioni sul campo. Offrono default più sicuri, operazioni a tempo costante, padding testato e protezioni a livello di protocollo. Scrivere il proprio “RSA” o cambiare schemi consolidati è rischioso perché piccole deviazioni possono creare nuovi percorsi di attacco.
Questo conta ancora di più quando i team rilasciano velocemente. Se usi un flusso di sviluppo rapido—che sia una pipeline CI/CD tradizionale o una piattaforma di sviluppo veloce come Koder.ai—il vantaggio di velocità vale solo se i default di sicurezza sono standardizzati. La capacità di Koder.ai di generare e distribuire app full‑stack (React sul web, Go + PostgreSQL sul backend, Flutter per mobile) può abbreviare il percorso verso la produzione, ma hai comunque bisogno di gestione disciplinata delle chiavi: certificati TLS, gestione dei segreti e firma delle release devono essere trattati come asset operativi di prima classe, non come ripensamenti.
Se vuoi più guida pratica oltre la matematica, consulta il blog per guide correlate su implementazione e gestione delle chiavi.
Affidarsi a un unico “segreto master” è un modo scomodo di gestire la sicurezza. Se una sola persona detiene la chiave (o un singolo dispositivo la conserva), sei esposto a fallimenti reali comuni: perdita accidentale, furto, abuso interno e perfino coercizione. Il segreto può essere perfettamente cifrato, ma comunque fragile perché ha un solo proprietario e un solo punto di fallimento.
La Condivisione Segreta di Shamir risolve questo dividendo un segreto in n share separate e impostando una regola per cui qualsiasi k share possono ricostruire il segreto originale—mentre meno di k non rivelano nulla di utile.
Quindi invece di chiedersi “Chi ha la password master?”, la domanda diventa: “Riusciamo a radunare k persone/dispositivi autorizzati quando ne abbiamo davvero bisogno?”
La sicurezza a soglia distribuisce la fiducia tra più detentori:
Questo è particolarmente prezioso per segreti ad alto impatto come chiavi di recupero, materiale di autorità di certificazione o credenziali root per infrastrutture critiche.
L'intuizione di Shamir non era solo eleganza matematica—era un modo pratico per trasformare la fiducia da una singola scommessa in una regola misurabile e verificabile.
La Condivisione Segreta di Shamir risolve un problema molto pratico: non vuoi che una persona, un server o una chiavetta USB sia “la chiave”. Invece dividi un segreto in pezzi così che un gruppo debba cooperare per recuperarlo.
Immagina di poter disegnare una curva liscia su un foglio a quadretti. Se vedi solo uno o due punti su quella curva, puoi disegnarne infinite che la attraversano. Ma se vedi abbastanza punti, la curva diventa univoca.
Questa è l'idea principale dell'interpolazione polinomiale: Shamir codifica il segreto come parte di una curva, poi consegna punti su quella curva. Con abbastanza punti puoi ricostruire la curva e leggere il segreto. Con troppi pochi punti sei bloccato con molte curve possibili—quindi il segreto resta nascosto.
Una share è semplicemente un punto su quella curva: un piccolo pacchetto di dati che da solo sembra casuale.
Lo schema si descrive solitamente come k-of-n:
La condivisione segreta funziona solo se le share non finiscono nello stesso posto o sotto lo stesso controllo. Una buona pratica è distribuirle tra persone, dispositivi e luoghi (per esempio: una su un token hardware, una con il legale, una in una cassaforte sicura).
Scegliere k è un equilibrio:
L'eleganza sta nel fatto che la matematica trasforma la “fiducia condivisa” in una regola precisa e applicabile.
La condivisione segreta è meglio intesa come un modo per dividere il controllo, non come un modo per “conservare un segreto in modo sicuro” nel senso ordinario. È uno strumento di governance: richiedi deliberatamente a più persone (o sistemi) di cooperare prima che una chiave possa essere ricostruita.
È facile confondere questi strumenti perché tutti riducono il rischio, ma riducono rischi diversi.
Brilla quando il “segreto” ha valore estremo e vuoi forti controlli e bilanciamenti:
Se il tuo problema principale è “potrei cancellare dei file” o “ho bisogno di resettare password utente”, la condivisione segreta è spesso eccessiva. Non sostituisce una buona sicurezza operativa: se un attaccante riesce a ingannare abbastanza detentori di share (o compromette i loro dispositivi), la soglia può essere soddisfatta.
Il modo ovvio di fallire è la disponibilità: perdi troppe share, perdi il segreto. I rischi più sottili sono umani:
Documenta il processo, assegna ruoli chiari e esercita il recupero con regolarità—come un'evacuazione antincendio. Un piano di condivisione segreta non testato è più vicino a una speranza che a un controllo.
RSA e la Condivisione Segreta di Shamir sono famosi come “algoritmi”, ma il loro impatto reale emerge quando sono integrati in sistemi che le persone e le organizzazioni gestiscono: autorità di certificazione, flussi di approvazione, backup e ripristino incidenti.
Le firme RSA alimentano l'idea che una chiave pubblica possa rappresentare un'identità. In pratica questo diventa PKI: certificati, catene di certificati e policy su chi può firmare cosa. Un'azienda non sceglie solo “RSA vs altro”—decide chi può emettere certificati, quanto spesso ruotano le chiavi e cosa succede quando una chiave è sospettata di essere esposta.
La rotazione delle chiavi è la sorella operativa di RSA: pianifichi il cambiamento. Certificati a vita più breve, sostituzioni programmate e procedure di revoca chiare riducono l'impatto degli errori inevitabili.
La condivisione segreta trasforma “una chiave, un proprietario” in un modello di fiducia. Puoi richiedere che k su n persone (o sistemi) ricostruiscano un segreto di recupero, approvino una modifica sensibile di configurazione o sblocchino un backup offline. Questo supporta un recupero più sicuro: nessun singolo admin può prendere il controllo di nascosto e nessuna singola credenziale persa causa un blocco permanente.
Una buona sicurezza chiede: chi può firmare release, chi può recuperare account e chi può approvare cambiamenti di policy? La separazione dei compiti riduce sia la frode sia i danni accidentali facendo sì che azioni ad alto impatto richiedano accordo indipendente.
Qui entrano in gioco anche gli strumenti operativi. Per esempio, piattaforme come Koder.ai includono funzionalità come snapshot e rollback, che possono ridurre l'impatto di un deploy sbagliato—ma queste tutele funzionano meglio se abbinate a firma disciplinata, accesso minimo necessario e regole chiare su “chi può approvare cosa”.
Per team che offrono diversi livelli di sicurezza—come accesso base vs approvazioni a soglia—rendi le scelte esplicite (vedi la pagina dei prezzi).
Un algoritmo crittografico può essere “sicuro” sulla carta e comunque fallire non appena incontra persone reali, dispositivi e flussi di lavoro. La sicurezza è sempre relativa: rispetto a chi potrebbe attaccarti, cosa può fare, cosa stai proteggendo e quanto costerebbe una falla.
Inizia nominando i probabili attori di minaccia:
Ogni attore ti spinge verso difese differenti. Se temi soprattutto attaccanti esterni, potresti dare priorità a server induriti, default sicuri e patch veloci. Se gli interni sono il rischio maggiore, avrai bisogno di separazione dei compiti, trilaterali di audit e approvazioni.
RSA e la condivisione segreta sono esempi del perché una “buona matematica” è solo l'inizio.
Un'abitudine pratica: documenta il tuo modello di minaccia come una breve lista di assunzioni—cosa stai proteggendo, da chi e quali fallimenti puoi tollerare. Riesamina queste assunzioni quando cambiano le condizioni: nuovi membri del team, un passaggio al cloud, una fusione o un nuovo requisito normativo.
Se distribuisci a livello globale, aggiungi anche assunzioni su localizzazione e compliance: dove vivono le chiavi, dove si processano i dati e quali vincoli transfrontalieri si applicano. (Koder.ai, per esempio, gira su AWS a livello globale e può distribuire applicazioni in paesi diversi per aiutare a soddisfare requisiti regionali di privacy e trasferimento dei dati—ma la responsabilità di definire il modello e configurarlo correttamente resta del team.)
Il lavoro di Adi Shamir ci ricorda una regola semplice: ottime idee crittografiche rendono possibile la sicurezza, ma sono i processi quotidiani a renderla reale. RSA e la condivisione segreta sono mattoni eleganti. La protezione che ottieni davvero dipende da come le chiavi sono create, conservate, usate, ruotate, sottoposte a backup e recuperate.
Considera la crittografia come ingegneria, non magia. Un algoritmo può essere corretto mentre il sistema intorno è fragile—per colpa di deploy affrettati, proprietà poco chiare, backup mancanti o scorciatoie “temporanee” che diventano permanenti.
Se vuoi guide pratiche sulla gestione delle chiavi e sulla sicurezza operativa, consulta i post correlati nel blog.
Una svolta aggiunge una nuova capacità—non solo velocità. Nella pratica moderna questo di solito significa abilitare confidenzialità, integrità e autenticità tra parti che non condividono un segreto in anticipo, su scala internet.
La crittografia simmetrica è veloce, ma presuppone che entrambe le parti conoscano già la stessa chiave segreta. La crittografia a chiave pubblica introduce una chiave pubblica che puoi condividere ampiamente e una chiave privata che tieni segreta, risolvendo il problema della distribuzione delle chiavi tra estranei e in grandi sistemi.
RSA ti permette di pubblicare un “lucchetto” (chiave pubblica) che chiunque può usare, mentre solo tu possiedi la “chiave” (chiave privata) per decriptare o firmare. È ampiamente usato per firme digitali e storicamente per il trasporto/scambio di chiavi nei protocolli di sicurezza.
Si basa sull'aritmetica modulare (“math degli orologi”) e sull'assunzione che sia computazionalmente infeasible scomporre un numero molto grande (prodotto di due grandi primi). È una difficoltà “assunta”, non provata impossibile—quindi parametri e best practice contano.
La cifratura risponde a: “Chi può leggere questo?” Le firme rispondono a: “Chi ha creato/approvato questo, e è stato modificato?” Nei sistemi reali si firma quasi sempre un hash dei dati, e i verificatori usano la chiave pubblica per controllare la firma.
La maggior parte dei guasti reali riguarda il sistema intorno a RSA, come:
Usa librerie verificate e schemi standard (es. padding moderno) invece del “RSA grezzo”.
La Condivisione Segreta di Shamir divide un segreto in n share in modo che qualsiasi k share possano ricostruirlo, mentre meno di k non rivelano informazioni utili. È un modo per sostituire il "titolare unico" di un master key con una soglia controllata di collaboratori.
Usala per segreti ad alto impatto dove vuoi nessun singolo punto di fallimento e nessuna singola persona può agire da sola, come:
Evita per backup quotidiani o segreti di scarso valore: l'overhead operativo potrebbe superare i benefici.
Scegli k basandoti sui vincoli reali:
Assicurati inoltre che le share siano separate tra persone, dispositivi e luoghi; altrimenti ricrei il singolo punto di fallimento che volevi eliminare.
La sicurezza dipende da modelli di minaccia e operazioni, non solo da algoritmi. Azioni pratiche:
Per altre linee guida di implementazione, consulta i post correlati nel blog.
