27 jun 2025·8 min
Doorbraken van Adi Shamir: RSA, Secret Sharing en beveiliging
Ontdek Adi Shamir’s kernideeën achter RSA en secret sharing en leer hoe elegante wiskunde echte beveiliging, risico's en sleutelbeheer beïnvloedt.
Ontdek Adi Shamir’s kernideeën achter RSA en secret sharing en leer hoe elegante wiskunde echte beveiliging, risico's en sleutelbeheer beïnvloedt.
Adi Shamir is een van die zeldzame onderzoekers wiens ideeën niet in papers en conferenties bleven hangen—ze werden bouwstenen van alledaagse beveiliging. Als je ooit HTTPS hebt gebruikt, een software-update hebt geverifieerd of op een digitale handtekening hebt vertrouwd, heb je waarschijnlijk baat gehad bij werk waaraan hij heeft bijgedragen.
Shamir was medebedenker van RSA, een publieke-sleutelcryptosysteem dat het praktisch maakte voor vreemden om veilige berichten uit te wisselen en identiteit op schaal te bewijzen. Hij ontwikkelde ook Shamir’s Secret Sharing, een methode om een geheim (zoals een cryptografische sleutel) in stukken te splitsen zodat geen enkele persoon of server volledige controle heeft.
Beide ideeën delen een thema: een zuivere wiskundige ingeving kan een praktische beveiligingscapaciteit ontsluiten die organisaties daadwerkelijk kunnen inzetten.
Dit artikel richt zich op die brug—van elegante concepten naar tools die echte systemen ondersteunen. Je ziet hoe RSA handtekeningen en veilige communicatie mogelijk maakte, en hoe secret sharing teams helpt vertrouwen te spreiden met “k‑van‑n” regels (bijv. elke 3 van 5 sleutelhouders kunnen een kritische actie goedkeuren).
We leggen de kernideeën uit zonder zware vergelijkingen of gevorderde getaltheorie. Het doel is helderheid: begrijpen wat deze systemen proberen te bereiken, waarom de ontwerpen slim zijn en waar de scherpe randjes zitten.
Er zijn beperkingen. Sterke wiskunde betekent niet automatisch sterke veiligheid. Echte falen komen vaak door implementatiefouten, slecht sleutelbeheer, zwakke operationele procedures of onrealistische aannames over dreigingen. Shamir’s werk helpt ons beide kanten te zien: de kracht van goed cryptografisch ontwerp—en de noodzaak van zorgvuldige, praktische uitvoering.
Een echte cryptografische doorbraak is niet alleen “we hebben versleuteling sneller gemaakt.” Het is een nieuwe mogelijkheid die verandert wat mensen veilig kunnen doen. Zie het als het uitbreiden van de set problemen die beveiligingstools kunnen oplossen—vooral op schaal, tussen vreemden en binnen realistische beperkingen zoals onbetrouwbare netwerken en menselijke fouten.
Klassieke “geheime codes” richten zich op het verbergen van een bericht. Moderne cryptografie is breder en praktischer:
Die verschuiving is belangrijk omdat veel fouten niet over afluisteren gaan—ze gaan over manipulatie, imitatie en geschillen over “wie wat deed.”
Bij symmetrische cryptografie delen beide kanten dezelfde geheime sleutel. Het is efficiënt en wordt nog veel gebruikt (bijv. voor het versleutelen van grote bestanden of netwerkverkeer). De uitdaging is praktisch: hoe delen twee partijen die sleutel veilig—vooral als ze elkaar nooit eerder hebben ontmoet?
Publieke-sleutelcryptografie splitst de sleutel in twee delen: een publieke sleutel die je open kunt delen en een privésleutel die je geheim houdt. Mensen kunnen je publieke sleutel gebruiken om berichten naar je te versleutelen; alleen jouw privésleutel kan deze ontsleutelen. Of je ondertekent iets met je privésleutel zodat iedereen het met je publieke sleutel kan verifiëren.
Toen publieke sleutels praktisch werden, had veilige communicatie geen vooraf gedeeld geheim of vertrouwde koerier meer nodig. Dat maakte internet‑schaal systemen mogelijk: beveiligde logins, versleuteld webverkeer, verifieerbare software‑updates en digitale handtekeningen die identiteit en verantwoordelijkheid ondersteunen.
Dit is het soort “nieuwe capaciteit” dat een doorbraak verdient.
RSA heeft een van de beste ontstaansverhalen in cryptografie: drie onderzoekers—Ron Rivest, Adi Shamir en Leonard Adleman—probeerden een nieuw idee (publieke-sleutelcryptografie) om te zetten in iets dat je daadwerkelijk kon gebruiken.
In 1977 publiceerden zij een schema dat snel het meest bekende praktische antwoord werd op een simpele vraag: “Hoe kunnen twee mensen veilig communiceren zonder eerst een geheim te delen?” Hun namen werden het acroniem.
De grote verschuiving van RSA is gemakkelijk in alledaagse termen te beschrijven. Je kunt een slot publiceren voor iedereen om te gebruiken (je publieke sleutel), terwijl je de enige sleutel die het opent zelf houdt (je privésleutel).
Als iemand je een geheim bericht wil sturen, hoeft die persoon je niet eerst te ontmoeten. Hij neemt je publieke slot, doet het op het bericht en stuurt de afgesloten doos. Alleen jij hebt de privésleutel om het te openen.
Die “publiceer het slot, verberg de sleutel” belofte voelde magisch en werd de basis voor veel moderne vertrouwenssystemen op internet.
RSA berust op een speciaal soort puzzel:
In RSA kan de publieke sleutel iedereen laten “verven” om een bericht te beschermen, terwijl de privésleutel het geheime recept is om het ongedaan te maken.
RSA komt in enkele belangrijke rollen voor:
Ook al zijn er nieuwere tools populair geworden, RSA’s simpele idee—publiek slot, privé sleutel—legt nog steeds veel uit over hoe vertrouwen op internet is opgebouwd.
RSA lijkt mysterieus totdat je inzoomt op twee alledaagse ideeën: getallen laten rondlopen binnen een vaste range en vertrouwen op een probleem dat pijnlijk langzaam lijkt om om te keren.
Modulaire rekenkunde is wat gebeurt als getallen “rondlopen”, zoals uren op een klok. Op een 12‑uurs klok geeft 10 + 5 geen 15; het komt uit op 3.
RSA gebruikt hetzelfde wraparound‑idee, maar dan met een veel grotere “klok”. Je kiest een groot getal (de modulus) en doet berekeningen waarbij resultaten altijd teruggebracht worden tot het bereik van 0 tot modulus‑1.
Waarom dit ertoe doet: modulaire rekenkunde laat operaties toe die in één richting makkelijk zijn, terwijl de omgekeerde richting moeilijk blijft—precies de asymmetrie die cryptografie wil.
Cryptografie hangt vaak af van een taak die:
Bij RSA is de “speciale informatie” de privésleutel. Zonder die sleutel staat de aanvaller voor een probleem dat als extreem kostbaar wordt beschouwd.
RSA‑veiligheid is gebaseerd op de moeilijkheid van factorisatie: het nemen van een groot getal en het vinden van de twee grote priemgetallen die vermenigvuldigd zijn om het te creëren.
Het vermenigvuldigen van twee grote priemgetallen is eenvoudig. Maar als iemand je alleen het product geeft en vraagt om de originele priemgetallen, lijkt dat omgekeerde stap bij grotere getallen enorme inspanning te vereisen.
Die factorisatiedifficulty is de kernreden waarom RSA kan werken: publieke informatie is veilig om te delen, terwijl de privésleutel praktisch blijft in gebruik maar moeilijk te reconstrueren is.
RSA wordt niet beschermd door een wiskundig bewijs dat factorisatie onmogelijk is. Het is beschermd door decennia aan bewijs: slimme onderzoekers hebben veel benaderingen geprobeerd, en de beste bekende methoden kosten nog steeds te veel tijd bij goed gekozen groottes.
Dat is wat “verondersteld moeilijk” betekent: niet gegarandeerd voor altijd, maar vertrouwd omdat het efficiënt kraken grote nieuwe ontdekkingen zou vereisen.
Sleutellengte bepaalt hoe groot die modulaire “klok” is. Grotere sleutels maken factorisatie over het algemeen dramatisch duurder en duwen aanvallen buiten realistische tijd en budgetten. Daarom zijn oudere, kortere RSA‑sleutels uitgefaseerd—en waarom keuzen voor sleutellengte feitelijk keuzes zijn over de inspanning voor een aanvaller.
Digitale handtekeningen beantwoorden een andere vraag dan encryptie. Encryptie beschermt geheimhouding: “Kan alleen de bedoelde ontvanger dit lezen?” Een handtekening beschermt vertrouwen: “Wie maakte dit en is het ongewijzigd?”
Een digitale handtekening bewijst typisch twee dingen:
Met RSA gebruikt de ondertekenaar zijn privésleutel om een korte stuk data te produceren—the handtekening—gekoppeld aan het bericht. Iedereen met de bijbehorende publieke sleutel kan het controleren.
Belangrijk: je ondertekent niet het hele bestand direct. In de praktijk ondertekenen systemen een hash (een compacte vingerafdruk) van het bestand. Daarom werkt ondertekenen even goed voor een klein bericht als voor een multi‑gigabyte download.
RSA‑handtekeningen komen voor waar systemen identiteit op schaal moeten verifiëren:
Amateuristisch “RSA‑wiskunde doen” is niet genoeg. Real‑world RSA‑handtekeningen vertrouwen op gestandaardiseerde padding‑ en encoderegels (zoals PKCS#1 of RSA‑PSS). Zie deze als vangrails die subtiele aanvallen voorkomen en handtekeningen eenduidig maken.
Je kunt versleutelen zonder te bewijzen wie het bericht zond, en je kunt ondertekenen zonder het bericht te verbergen. Veel veilige systemen doen beide—maar ze lossen verschillende problemen op.
RSA is een sterk idee, maar de meeste echte “breuken” verslaan niet de onderliggende wiskunde. Ze benutten de rommelige delen eromheen: hoe sleutels worden gegenereerd, hoe berichten worden gepad, hoe apparaten zich gedragen en hoe mensen systemen bedienen.
Wanneer koppen zeggen “RSA gekraakt”, gaat het vaak om een implementatiefout of een deployment‑shortcut. RSA wordt zelden als “raw RSA” gebruikt; het zit ingebed in protocollen, verpakt in padding‑schema’s en gecombineerd met hashing en randomness. Als één van die onderdelen verkeerd is, kan het systeem falen ook al blijft het kernalgoritme intact.
Dit zijn de gaten die herhaaldelijk incidenten veroorzaken:
Moderne cryptobibliotheken en standaarden bestaan omdat teams deze lessen op de harde manier hebben geleerd. Ze bevatten veilige defaults, constant‑time operaties, geteste padding en protocol‑niveau vangrails. “Je eigen RSA schrijven” of gevestigde schema’s aanpassen is riskant omdat kleine afwijkingen nieuwe aanvalspaden kunnen openen.
Dit is nog belangrijker als teams snel uitrollen. Als je een snel ontwikkel‑workflow gebruikt—of het nu een traditionele CI/CD‑pipeline is of een vibe‑coding platform zoals Koder.ai—het snelheidsvoordeel blijft alleen bestaan als beveiligingsdefaults ook gestandaardiseerd zijn. Koder.ai’s vermogen om full‑stack apps te genereren en deployen (React op het web, Go + PostgreSQL op de backend, Flutter voor mobiel) kan de weg naar productie verkorten, maar je moet nog steeds gedisciplineerd met sleutels omgaan: TLS‑certificaten, secrets‑management en release‑signing zijn operationele assets, geen bijzaken.
Als je meer praktische beveiligingsgidsen wilt naast de wiskunde, bekijk gerelateerde posts op /blog.
Vertrouwen op één “master secret” is een ongemakkelijke manier om beveiliging te regelen. Als één persoon de sleutel bezit (of één apparaat slaat hem op), loop je risico op gewone real‑world fouten: per ongeluk verlies, diefstal, misbruik door insiders en zelfs dwang. Het geheim kan perfect versleuteld zijn, maar nog steeds kwetsbaar omdat het één eigenaar en één faalpunt heeft.
Shamir’s Secret Sharing lost dit op door één geheim in n afzonderlijke shares te splitsen en een regel in te stellen dat elke k shares het originele geheim kunnen reconstrueren—terwijl minder dan k niets bruikbaars onthullen.
Dus in plaats van “Wie heeft het master‑wachtwoord?”, wordt de vraag: “Kunnen we k bevoegde mensen/apparaten verzamelen wanneer het echt nodig is?”
Drempelbeveiliging spreidt vertrouwen over meerdere houders:
Dit is vooral waardevol voor geheimen met hoge impact zoals recovery‑sleutels, certificaatautoriteitmateriaal of root‑referenties voor kritieke infrastructuur.
Shamir’s inzicht was niet alleen wiskundige elegantie—het was een praktische manier om vertrouwen van een enkele gok naar een meetbare, controleerbare regel te transformeren.
Shamir’s Secret Sharing lost een heel praktisch probleem op: je wilt niet dat één persoon, één server of één USB‑stick “de sleutel” is. In plaats daarvan splits je een geheim in stukken zodat een groep moet samenwerken om het terug te krijgen.
Stel je voor dat je een gladde kromme op ruitjespapier tekent. Als je maar één of twee punten op die kromme ziet, kun je talloze verschillende krommen bedenken die erdoorheen lopen. Maar als je genoeg punten ziet, wordt de kromme uniek bepaald.
Dat is het idee achter polynoominterpolatie: Shamir codeert het geheim als deel van een kromme en deelt vervolgens punten op die kromme uit. Met genoeg punten kun je de kromme reconstrueren en het geheim teruglezen. Met te weinig punten blijf je met te veel mogelijke krommen—dus het geheim blijft verborgen.
Een share is simpelweg één punt op die verborgen kromme: een klein datapakketje dat op zichzelf willekeurig lijkt.
Het schema wordt meestal beschreven als k‑van‑n:
Secret sharing werkt alleen als shares niet op dezelfde plek of onder dezelfde controle terechtkomen. Goede praktijk is ze te verspreiden over personen, apparaten en locaties (bijv. één in een hardwaretoken, één bij juridische raad, één in een veilige kluis).
Het kiezen van k is een afweging:
De elegantie is dat de wiskunde “gedeeld vertrouwen” verandert in een precieze, afdwingbare regel.
Secret sharing is het beste te zien als een manier om controle te splitsen, niet als een gewone manier om een geheim veilig op te slaan. Het is een governance‑instrument: je vereist dat meerdere mensen (of systemen) samenwerken voordat een sleutel kan worden gereconstrueerd.
Het is makkelijk deze tools te verwarren omdat ze allemaal risico’s verkleinen, maar ze verkleinen verschillende risico’s.
Secret sharing blinkt uit wanneer het “geheim” extreem waardevol is en je sterke checks‑and‑balances wilt:
Als je probleem vooral is “ik kan bestanden per ongeluk verwijderen” of “ik moet wachtwoorden van gebruikers resetten”, is secret sharing meestal overdreven. Het vervangt ook geen goede operationele beveiliging: als een aanvaller genoeg share‑houders weet te misleiden (of hun apparaten compromitteert), kan de drempel worden gehaald.
De voor de hand liggende faalmode is beschikbaarheid: verlies te veel shares, verlies het geheim. De subtielere risico’s zijn menselijk:
Documenteer het proces, wijs duidelijke rollen toe en oefen herstel volgens een schema—als een brandalarm. Een secret‑sharing plan dat niet getest is, is meer hoop dan controle.
RSA en Shamir’s Secret Sharing zijn beroemd als “algoritmes”, maar hun echte impact verschijnt wanneer ze ingebed worden in systemen die mensen en organisaties daadwerkelijk draaien: certificaatautoriteiten, goedkeuringsworkflows, backups en incidentherstel.
RSA‑handtekeningen voeden het idee dat een publieke sleutel een identiteit kan vertegenwoordigen. In de praktijk wordt dat PKI: certificaten, certificaatketens en beleid over wie mag ondertekenen wat. Een bedrijf kiest niet alleen “RSA vs iets anders”—het kiest wie certificaten mag uitgeven, hoe vaak sleutels roteren en wat er gebeurt bij vermoedelijke blootstelling.
Sleutelrotatie is de operationele tegenhanger van RSA: plan voor verandering. Korter levende certificaten, geplande vervangingen en duidelijke intrekkingsprocedures verkleinen de impact van onvermijdelijke fouten.
Secret sharing verandert “één sleutel, één eigenaar” in een vertrouwensmodel. Je kunt vereisen dat k‑van‑n mensen (of systemen) een herstelgeheim reconstrueren, een gevoelige configuratiewijziging goedkeuren of een offline backup ontgrendelen. Dat ondersteunt veiliger herstel: geen enkele beheerder kan stilletjes overnemen en geen enkele verloren referentie veroorzaakt permanente lockout.
Goede beveiliging vraagt: wie mag releases ondertekenen, wie kan accounts herstellen en wie kan beleidswijzigingen goedkeuren? Scheiding van taken vermindert fraude en onbedoelde schade door hoge‑impact acties onafhankelijke goedkeuringen te laten vereisen.
Dit is ook waar operationele tooling ertoe doet. Bijvoorbeeld, platforms zoals Koder.ai bevatten functies als snapshots en rollback, die de impact van een slechte deployment kunnen verminderen—maar die beschermingen werken het best samen met gedisciplineerd signen, least‑privilege toegang en duidelijke regels wie wat mag goedkeuren.
Voor teams die verschillende beveiligingsniveaus aanbieden—zoals basis toegang vs drempel‑goedkeuringen—maak de keuzes expliciet (zie /pricing).
Een cryptografisch algoritme kan “veilig” zijn op papier en toch falen zodra het echte mensen, apparaten en workflows ontmoet. Beveiliging is altijd relatief: relatief aan wie je denkt dat je aanvalt, wat zij kunnen doen, wat je beschermt en wat falen zou kosten.
Begin met het benoemen van waarschijnlijke dreigingsactoren:
Elke actor stuurt je naar andere verdedigingsmaatregelen. Ben je vooral bezorgd over externe aanvallers, dan prioriteer je verharde servers, veilige defaults en snelle patches. Zijn insiders het grotere risico, dan heb je scheiding van taken, auditsporen en goedkeuringen nodig.
RSA en secret sharing zijn voorbeelden waarom “goede wiskunde” slechts het begin is.
Een praktische gewoonte: documenteer je threat model als een korte lijst aannames—wat je beschermt, tegen wie en welke fouten je kunt tolereren. Herzie het als omstandigheden veranderen: nieuwe teamleden, migratie naar de cloud, een fusie of nieuwe regelgeving.
Als je globaal uitrolt, voeg locatie‑ en compliance‑aannames toe: waar sleutels leven, waar data verwerkt wordt en welke grensoverschrijdende beperkingen gelden. (Koder.ai, bijvoorbeeld, draait op AWS wereldwijd en kan apps in verschillende landen deployen om regionale privacy‑ en data‑transfer eisen te helpen ondersteunen—maar de verantwoordelijkheid om het model te definiëren en correct te configureren blijft bij het team.)
Het werk van Adi Shamir herinnert aan een eenvoudige regel: geweldige cryptografische ideeën maken beveiliging mogelijk, maar je dagelijkse proces maakt het werkelijk effectief. RSA en secret sharing zijn elegante bouwstenen. De bescherming die je daadwerkelijk krijgt, hangt af van hoe sleutels worden aangemaakt, opgeslagen, gebruikt, geroteerd, geback‑upt en hersteld.
Beschouw cryptografie als engineering, niet als magie. Een algoritme kan solide zijn terwijl het systeem eromheen fragiel is—door gehaaste deployments, onduidelijke eigenaarschap, ontbrekende backups of “tijdelijke” shortcuts die permanent worden.
Als je meer praktische gidsen over sleutelbeheer en operationele beveiliging wilt, bekijk gerelateerde posts op /blog.
Een doorbraak voegt een nieuwe capaciteit toe—niet alleen snelheid. In de praktijk betekent dat meestal dat je vertrouwelijkheid, integriteit en authenticiteit tussen partijen mogelijk maakt die van tevoren geen geheim delen, en dat op internetschaal.
Symmetrische crypto is snel, maar veronderstelt dat beide partijen hetzelfde geheime sleutel al delen. Publieke-sleutelcryptografie introduceert een publieke sleutel die je breed kunt delen en een privésleutel die je geheim houdt, waarmee het probleem van sleuteluitwisseling tussen vreemden en grote systemen wordt opgelost.
RSA laat je een “slot” publiceren (publieke sleutel) dat iedereen kan gebruiken, terwijl alleen jij de “sleutel” (privésleutel) hebt om te ontsluiten of te ondertekenen. Het wordt veel gebruikt voor digitale handtekeningen en historisch voor sleuteltransport/uitwisseling in beveiligde protocollen.
Het vertrouwt op modulaire rekenkunde (“klok‑wiskunde”) en de aanname dat factorisatie van een zeer groot getal (product van twee grote priemgetallen) onpraktisch moeilijk is bij geschikte sleutellengtes. Het is “verondersteld moeilijk”, niet bewezen onmogelijk—dus parameters en best practices zijn belangrijk.
Encryptie beantwoordt: “Wie kan dit lezen?” Handtekeningen beantwoorden: “Wie heeft dit gemaakt/goedgekeurd en is het ongewijzigd?” In systemen onderteken je meestal een hash van de data, en verificateurs gebruiken de publieke sleutel om de handtekening te controleren.
De meeste echte fouten komen uit het systeem rondom RSA, zoals:
Gebruik goedgekeurde bibliotheken en moderne padding in plaats van “raw RSA.”
Shamir’s Secret Sharing splitst één geheim in n shares zodat elke k shares het origineel kunnen reconstrueren, terwijl minder dan k niets bruikbaars onthullen. Het vervangt een enkele sleutelhouder door een gecontroleerde drempel van samenwerkende houders.
Gebruik het voor hoog-impact geheimen waarbij je geen single point of failure wilt en waar geen enkele persoon alleen kan handelen, zoals:
Vermijd het voor dagelijkse backups of laagwaardige geheimen waar de operationele overhead niet opweegt tegen het voordeel.
Kies k op basis van praktische beperkingen:
Zorg dat shares gespreid worden over personen, apparaten en locaties; anders creëer je opnieuw het enkelvoudige faalpunt dat je probeerde te vermijden.
Omdat beveiliging afhangt van threat models en operatie, niet alleen algoritmen. Praktische stappen:
Voor implementatieadvies zie gerelateerde posts op /blog.