Leonard Adleman hielp mee RSA te ontwikkelen, een publiek-sleutelsysteem dat HTTPS, internetbankieren en ondertekende updates mogelijk maakte. Lees hoe het werkt en waarom het belangrijk is.
Als mensen zeggen dat ze een website of online dienst “vertrouwen”, bedoelen ze meestal drie praktische dingen:
RSA werd beroemd omdat het hielp deze beloften op internet-schaal mogelijk te maken.
Je hebt de invloed van RSA gevoeld, ook al ken je de naam misschien niet. Het hangt nauw samen met hoe:
De gemeenschappelijke draad is vertrouwen zonder dat je iedereen persoonlijk hoeft te kennen (of vooraf geheimen met elke server of leverancier hoeft af te spreken).
Dit artikel houdt de uitleg eenvoudig: geen zware wiskunde, en geen behoefte aan een computerwetenschappelijke achtergrond. We richten ons op het dagelijkse “waarom het werkt” plaatje.
RSA populariseerde een krachtig idee: in plaats van één gedeeld geheim gebruik je een publieke sleutel die je open kunt delen en een privésleutel die je geheim houdt. Die splitsing maakt het mogelijk zowel privacy te beschermen als identiteit te bewijzen in situaties waar mensen en systemen elkaar nog nooit ontmoet hebben.
Leonard Adleman is de “A” in RSA, naast Ron Rivest en Adi Shamir. Terwijl Rivest en Shamir vaak gecrediteerd worden voor de kernconstructie, was Adlemans bijdrage essentieel: hij hielp het systeem vormgeven tot iets dat niet alleen slim was, maar ook overtuigend—een algoritme dat mensen konden analyseren, testen en vertrouwen.
Een groot deel van Adlemans rol was het onder druk testen van het idee. In cryptografie is een schema niet waardevol omdat het plausibel klinkt; het is waardevol omdat het bestand is tegen zorgvuldige aanvallen en toetsing. Adleman werkte aan validatie, verfijnde aannames en droeg bij aan de vroege framing waarom RSA moeilijk te breken zou moeten zijn.
Net zo belangrijk was dat hij hielp van “dit zou kunnen werken” naar “dit is een cryptosysteem dat anderen kunnen evalueren” te komen. Die helderheid—het ontwerp begrijpelijk maken voor de bredere onderzoeksgemeenschap om te inspecteren—was cruciaal voor adoptie.
Voor RSA hing veilige communicatie meestal af van dat beide partijen al een geheim deelden. Die aanpak werkt binnen gesloten groepen, maar schaalt niet als vreemden veilig met elkaar moeten communiceren (bijv. een koper en een website die elkaar voor het eerst ontmoeten).
RSA veranderde dat verhaal door een praktisch publieke-sleutelcryptosysteem populair te maken: je kunt één sleutel publiceren voor anderen om te gebruiken, terwijl je een aparte privésleutel geheim houdt.
De invloed van RSA is groter dan één algoritme. Het maakte twee internetessentials haalbaar op schaal:
Die ideeën liggen ten grondslag aan hoe HTTPS, internetbankieren en ondertekende software-updates normale verwachtingen werden in plaats van zeldzame uitzonderingen.
Voor RSA betekende veilige communicatie meestal gedeelde-geheim encryptie: beide kanten moesten van tevoren dezelfde geheime sleutel hebben. Dat werkt voor een kleine groep, maar faalt snel als je een publieke dienst voor miljoenen wilt draaien.
Als elke klant een unieke geheime sleutel nodig had om met een bank te praten, moest de bank een enorme hoeveelheid geheimen genereren, afleveren, opslaan, rouleren en beschermen. Het moeilijkste deel is niet de wiskunde—het is de coördinatie.
Hoe lever je die geheime sleutel veilig aan elk persoon? Per post is traag en risicovol. Telefonisch doorgeven kan worden onderschept of sociaal gemanipuleerd. Over het internet sturen ondermijnt het doel, omdat het kanaal precies is wat je probeert te beveiligen.
Stel twee vreemden voor—jij en een online winkel—die elkaar nooit eerder ontmoetten. Je wilt veilig een betaling sturen. Met gedeelde-geheim encryptie zou je een privé-sleutel nodig hebben die jullie allebei al kennen. Maar dat hebben jullie niet.
De doorbraak van RSA maakte veilige communicatie mogelijk zonder vooraf een geheim te delen. In plaats daarvan kun je één sleutel publiceren (een publieke sleutel) die iedereen kan gebruiken om een bericht voor jou te beveiligen, terwijl je een andere privésleutel geheim houdt.
Zelfs als je berichten kunt versleutelen, moet je nog steeds weten naar wie je versleutelt. Anders kan een aanvaller zich voordoen als de bank of winkel, je misleiden om hun sleutel te gebruiken en stilletjes alles te lezen of te wijzigen.
Daarom heeft veilige internetcommunicatie twee eigenschappen nodig:
RSA maakte het mogelijk beide eigenschappen te bereiken en legde het fundament voor hoe onlinevertrouwen op schaal werkt.
Publieke-sleutelcryptografie is een eenvoudig idee met grote consequenties: je kunt iets voor iemand vergrendelen zonder eerst een gedeeld geheim te hebben afgesproken. Dat is de kernverschuiving die RSA praktisch maakte.
Zie een publieke sleutel als een slot dat je gerust aan iedereen kunt geven. Mensen kunnen het gebruiken om een bericht voor jou te beschermen—of (in signatuursystemen) om te controleren dat iets echt van jou komt.
Een privésleutel is wat je geheim moet houden. Het is de sleutel die opent wat met je publieke sleutel is vergrendeld, en het is ook wat je gebruikt om handtekeningen te maken die alleen jij kon produceren.
Samen vormen de publieke en privésleutel een sleutelpaar. Ze zijn wiskundig verbonden, maar niet uitwisselbaar. Het delen van de publieke sleutel is veilig omdat het kennen ervan iemand geen praktische manier geeft om de privésleutel af te leiden.
Encryptie gaat over privacy. Als iemand een bericht versleutelt met jouw publieke sleutel, kan alleen jouw privésleutel het ontsleutelen.
Digitale handtekeningen gaan over vertrouwen en integriteit. Als jij iets ondertekent met je privésleutel, kan iedereen met je publieke sleutel twee dingen verifiëren:
De beveiliging is geen magie—ze berust op moeilijke wiskundige problemen die de ene kant makkelijk maken en extreem moeilijk om om te keren met huidige computers. Die éénrichtings-eigenschap maakt het delen van de publieke sleutel veilig, terwijl de privésleutel krachtig blijft.
RSA bouwt op een simpele asymmetrie: de “voorwaartse” wiskunde om iets te vergrendelen is makkelijk, maar het terugdraaien om het te ontgrendelen is extreem moeilijk—tenzij je een speciaal geheim hebt.
Zie RSA als een soort wiskundig hangslot. Iedereen kan met de publieke sleutel een bericht vergrendelen. Maar alleen degene met de privésleutel kan het openen.
Wat dit mogelijk maakt, is een zorgvuldig gekozen relatie tussen de twee sleutels. Ze worden samen gegenereerd en, hoewel ze gerelateerd zijn, kun je in de praktijk de privésleutel niet afleiden door alleen naar de publieke sleutel te kijken.
Op hoofdlijnen steunt RSA op het feit dat het vermenigvuldigen van grote priemgetallen makkelijk is, maar terugwerken—uitvinden welke priemgetallen vermenigvuldigd zijn—zeer moeilijk is wanneer de getallen enorm zijn.
Voor kleine getallen is factoriseren snel. Voor de groottes die in echte RSA-sleutels worden gebruikt (duizenden bits) vereisen de beste bekende methoden nog steeds een onpraktische hoeveelheid tijd en rekenkracht. Die “moeilijk om om te keren” eigenschap houdt aanvallers weg van het reconstrueren van de privésleutel.
RSA wordt meestal niet gebruikt om grote bestanden of lange berichten direct te versleutelen. In plaats daarvan beschermt het vaak kleine geheimen—vooral een willekeurig gegenereerde sessiesleutel. Die sessiesleutel versleutelt vervolgens de echte data met sneller symmetrisch versleutelingswerk, dat beter geschikt is voor bulkverkeer.
RSA is bekend omdat het twee verwante maar duidelijk verschillende taken kan uitvoeren: encryptie en digitale handtekeningen. Ze door elkaar halen is een veelvoorkomende bron van verwarring.
Encryptie richt zich vooral op vertrouwelijkheid. Digitale handtekeningen richten zich vooral op integriteit + authenticiteit.
Bij RSA-encryptie gebruikt iemand jouw publieke sleutel om iets te vergrendelen zodat alleen jouw privésleutel het kan ontsleutelen.
In de praktijk wordt RSA vaak gebruikt om een klein geheim te beschermen, zoals een willekeurige sessiesleutel. Die sessiesleutel versleutelt vervolgens de bulkdata efficiënt.
Bij RSA-handtekeningen draait de richting om: de zender gebruikt zijn privésleutel om een handtekening te maken, en iedereen met de publieke sleutel kan verifiëren:
Digitale handtekeningen verschijnen in alledaagse ‘goedkeurings’-momenten:
Encryptie houdt geheimen; handtekeningen behouden vertrouwen.
Het slotje in je browser is een ezelsbrug: je verbinding met deze website is versleuteld en (meestal) geauthenticeerd. Het betekent dat anderen op het netwerk—bijv. iemand op openbaar Wi‑Fi—niet kunnen lezen of stilletjes veranderen wat je browser en de site uitwisselen.
Het betekent niet dat de website in elke zin “veilig” is. Het slotje kan je niet vertellen of een winkel eerlijk is, of een download malware bevat, of je het juiste domein hebt ingetikt. Het garandeert ook niet dat de site je gegevens beschermt zodra ze op hun servers aankomen.
Wanneer je een HTTPS-site bezoekt, voeren je browser en de server een opzetgesprek: de TLS-handshake:
Historisch werd RSA vaak gebruikt om de sessiesleutel uit te wisselen (de browser versleutelt een geheim met de RSA-publieke sleutel van de server). In veel moderne TLS-configuraties wordt RSA vooral gebruikt voor authenticatie via handtekeningen (aantonen dat de server de privésleutel beheert), terwijl sleutelovereenkomst met andere methoden gebeurt.
RSA is uitstekend voor het opzetten van vertrouwen en het beschermen van kleine stukjes data tijdens de start, maar het is traag vergeleken met symmetrische encryptie. Na de handshake schakelt HTTPS over op snelle symmetrische algoritmen voor de feitelijke pagina's, inloggegevens en banktransacties.
Internetbankieren heeft een eenvoudige belofte: je moet kunnen inloggen, saldo controleren en geld overmaken zonder dat iemand anders je inloggegevens leert—of stilletjes verandert wat je verstuurt.
Een banksessie moet drie dingen tegelijk beschermen:
Zonder HTTPS kan iedereen op hetzelfde Wi‑Fi, een gecompromitteerde router of een kwaadwillende netwerkoperator mogelijk afluisteren of vervalsen.
HTTPS (via TLS) beveiligt de verbinding zodat data tussen je browser en de bank versleuteld en gecontroleerd op integriteit is. In praktische termen betekent dit:
De historische rol van RSA was hier cruciaal omdat het het “eerste contact”-probleem hielp oplossen: het opzetten van een veilige sessie over een onveilig netwerk.
Encryptie alleen is niet voldoende als je naar de verkeerde partij versleutelt. Internetbankieren werkt alleen als je browser kan vaststellen dat hij met de echte bank praat, niet met een nep-site of een man-in-the-middle.
Banken voegen nog steeds MFA, apparaatchecks en fraudemonitoring toe. Die verminderen schade bij gestolen inloggegevens—maar vervangen HTTPS niet. Ze werken het beste als vangnet bovenop een verbinding die al privé en manipulatiebestendig is.
Software-updates zijn net zozeer een vertrouwensprobleem als een technisch probleem. Zelfs als een app zorgvuldig is geschreven, kan een aanvaller de bezorgstap aanvallen—een legitieme installer vervangen door een aangepaste versie, of een gemanipuleerde update tussen uitgever en gebruiker schuiven. Zonder een betrouwbare manier om te verifiëren wat je hebt gedownload, kan “update beschikbaar” een gemakkelijk instappunt voor aanvallers worden.
Als updates alleen worden beschermd door een downloadlink, kan een aanvaller die een mirror compromitteert, een netwerk kapen of een gebruiker naar een look‑alike pagina lokken een ander bestand met dezelfde naam serveren. De gebruiker installeert het mogelijk normaal en de schade kan “stil” zijn: malware gebundeld met de update, backdoors toegevoegd of veiligheidsinstellingen verzwakt.
Codeondertekening gebruikt publieke-sleutelcryptografie (waaronder vaak RSA) om een digitale handtekening aan een installer of updatepakket te hangen.
De uitgever ondertekent de software met een privésleutel. Je apparaat (of besturingssysteem) verifieert die handtekening met de publieke sleutel van de uitgever—vaak geleverd via een certificaatketen. Als zelfs één byte is aangepast, faalt de verificatie. Dit verschuift vertrouwen van “waar heb ik het gedownload?” naar “kan ik verifiëren wie het heeft gemaakt en dat het intact is?”
In moderne levertreinen breiden deze ideeën zich uit tot API-aanroepen, build-artifacten en deployment-rollouts. Platforms zoals Koder.ai (een vibe-coding platform om web-, backend- en mobiele apps vanuit een chatinterface te leveren) vertrouwen nog steeds op dezelfde fundamenten: HTTPS/TLS voor data onderweg, zorgvuldig certificaatbeheer voor custom domains en praktische rollback-workflows (snapshots en herstelpunten) om risico bij het uitrollen van wijzigingen te verkleinen.
Ondertekende updates verminderen het aantal stille manipulatiemogelijkheden. Gebruikers krijgen duidelijkere waarschuwingen als iets niet klopt en geautomatiseerde update-systemen kunnen aangepaste bestanden weigeren voordat ze worden uitgevoerd. Het is geen garantie dat de software zelf foutloos is, maar het is een krachtige verdediging tegen imitatie en supply-chain manipulatie.
Om dieper te gaan in hoe handtekeningen, certificaten en verificatie samenwerken, zie /blog/code-signing-basics.
Als RSA je een publieke sleutel geeft, volgt de vraag: van wie is die publieke sleutel?
Een certificaat is het internetantwoord. Het is een klein, ondertekend gegevensbestand dat een publieke sleutel koppelt aan een identiteit—zoals een website-naam (example.com), een organisatie of een software-uitgever. Zie het als een ID-kaart voor een sleutel: het zegt “deze sleutel hoort bij deze naam” en bevat details zoals de eigenaar, de publieke sleutel zelf en geldigheidsdata.
Certificaten zijn belangrijk omdat ze door iemand anders worden ondertekend. Die “iemand” is meestal een Certificate Authority (CA).
Een CA is een derde partij die bepaalde bewijzen controleert (van basale domeincontrole tot diepgaandere bedrijfsverificatie) en vervolgens het certificaat ondertekent. Je browser of besturingssysteem bevat een ingebouwde lijst met vertrouwde CAs. Wanneer je een site bezoekt via HTTPS gebruikt je apparaat die lijst om te beslissen of het certificaat geaccepteerd wordt.
Dit systeem is niet perfect: CAs kunnen fouten maken en aanvallers kunnen proberen ze te misleiden of te compromitteren. Maar het creëert een praktische keten van vertrouwen die op mondiale schaal werkt.
Certificaten verlopen opzettelijk. Korte levensduur beperkt schade als een sleutel gestolen is en stimuleert regelmatig onderhoud.
Certificaten kunnen ook voortijdig worden ingetrokken. Intrekking is een manier om te zeggen “stop met het vertrouwen van dit certificaat”, bijvoorbeeld als een privésleutel mogelijk is gelekt of het certificaat onjuist is uitgegeven. Apparaten kunnen de intrekkingsstatus controleren (met wisselende betrouwbaarheid en strengheid), wat een reden is waarom sleutelhygiëne nog steeds belangrijk is.
Houd je privésleutel privé: bewaar hem in veilige sleutelopslag, beperk toegang en vermijd het kopiëren tussen systemen tenzij noodzakelijk.
Roteer sleutels wanneer nodig—na een incident, tijdens geplande upgrades of wanneer beleid dat vereist. Houd vervaldata bij zodat vernieuwingen geen last-minute-paniek worden.
RSA is een fundamenteel idee, maar geen magisch schild. De meeste echte kwetsuren ontstaan niet doordat iemand “RSA heeft gekraakt”—ze ontstaan omdat systemen rondom RSA falen.
Een paar patronen komen steeds terug:
De veiligheid van RSA hangt af van het genereren van genoeg groot en echt onvoorspelbaar materiaal. Goede randomisatie is essentieel: als keygeneratie een zwakke bron van willekeur gebruikt, kunnen aanvallers soms de mogelijke sleutels reproduceren of beperken. Evenzo is sleutellengte belangrijk omdat verbeteringen in rekenkracht en wiskundige technieken geleidelijk de veiligheidsmarge voor kleine sleutels verminderen.
RSA-operaties zijn zwaarder dan moderne alternatieven, daarom gebruiken veel protocollen RSA spaarzaam—meestal voor authenticatie of het uitwisselen van een tijdelijk geheim, en schakelen vervolgens over op sneller symmetrisch encryptie voor bulkdata.
Beveiliging werkt het beste als meerdere lagen: bescherm privésleutels (bij voorkeur in hardware), monitor certificaatuitgifte, patch systemen, gebruik phishing-resistente authenticatie en ontwerp voor veilige sleutelrotatie. RSA is één gereedschap in de keten—niet de hele keten.
RSA is een van de meest ondersteunde cryptografische middelen op het internet. Ook als een dienst RSA niet “voorkeur” geeft, behoudt het vaak RSA-compatibiliteit omdat het overal aanwezig is: oudere apparaten, langlopende enterprise-systemen en certificaatinfrastructuren die over veel jaren zijn opgebouwd.
Cryptografie evolueert om dezelfde redenen als andere beveiligingstechnologieën:
Je ziet vaak alternatieven in TLS en moderne toepassingen:
Kort gezegd: RSA kan zowel encryptie als handtekeningen doen, maar nieuwere systemen splitsen vaak het werk—een methode geoptimaliseerd voor handtekeningen en een andere voor het tot stand brengen van sessiesleutels.
Nee. RSA blijft veelvuldig ondersteund en is een geldige keuze in veel contexten, vooral waar compatibiliteit cruciaal is of waar bestaande certificaat- en sleutelbeheerpraktijken erop zijn gebouwd. De “beste” keuze hangt af van factoren zoals apparaatondersteuning, prestatiebehoeften, compliance-eisen en hoe sleutels worden opgeslagen en geroteerd.
Als je wilt zien hoe deze keuzes in echte HTTPS-verbindingen naar voren komen, is de volgende stap: /blog/ssl-tls-explained.
RSA maakte internet-breed vertrouwen praktisch mogelijk door publieke-sleutelcryptografie, die ondersteunt:
Die bouwstenen zijn centraal voor HTTPS, internetbankieren en ondertekende software-updates.
Leonard Adleman hielp RSA van een slim idee te veranderen in een cryptosysteem dat anderen konden analyseren en vertrouwen. Praktisch betekent dat: het onder druk testen van aannames, het verfijnen van de presentatie en het versterken van het betoog waarom RSA onder realistische aanvalsscenario's moeilijk te breken zou zijn.
Een publieke sleutel is bedoeld om te delen; mensen gebruiken hem om iets naar jou te versleutelen of om jouw handtekeningen te verifiëren.
Een privésleutel moet geheim blijven; die gebruik je om te ontsleutelen wat naar jou versleuteld is (bij RSA-encryptie) en om handtekeningen te maken die alleen jij kunt produceren.
Als de privésleutel uitlekt, kunnen aanvallers zich voordoen als jij en/of versleutelde geheimen ontsleutelen, afhankelijk van het gebruik van de sleutel.
De veiligheid van RSA berust op een éénrichtings wiskundig probleem: het vermenigvuldigen van grote priemgetallen is makkelijk, maar het factoriseren van het resulterende enorme getal terug naar priemfactoren is extreem moeilijk bij reële sleutellengtes.
De publieke en privésleutels zijn wiskundig gerelateerd, maar zo ontworpen dat de publieke sleutel in de praktijk niet de privésleutel onthult.
Ze dienen verschillende doelen:
Een eenvoudige vuistregel: encryptie houdt geheimen veilig; handtekeningen bewijzen wie iets heeft verzonden en dat het niet is gewijzigd.
In een vereenvoudigde HTTPS/TLS-flow:
RSA kan gebruikt worden voor en werd historisch ook gebruikt om het initiële sessiegeheim te beschermen in sommige configuraties.
Nee. Het hangslot geeft voornamelijk aan dat de verbinding versleuteld en meestal geauthenticeerd is.
Het betekent niet dat:
Beschouw HTTPS als een noodzakelijke transportlaag, niet als een volledige garantie voor vertrouwen.
Een certificaat koppelt een publieke sleutel aan een identiteit (bijv. een domeinnaam). Browsers vertrouwen dat omdat een Certificate Authority (CA) het certificaat ondertekent, en browsers/OS-en leveren een lijst met vertrouwde CAs.
Als je services uitrolt, plan voor:
Ondertekende updates laten je apparaat twee dingen controleren:
Dit verdedigt tegen “vervang het pakket”-aanvallen (gecompromitteerde mirrors, gekaapte netwerken, look‑alike downloadpagina's). Voor meer uitleg, zie /blog/code-signing-basics.
Veel echte veiligheidsproblemen zijn operationeel, niet omdat de RSA-wiskunde is gebroken:
Praktische stappen: bescherm privésleutels (bij voorkeur hardware-ondersteund), houd vervaldata bij, roteer sleutels op tijd en monitor certificaatuitgifte waar mogelijk.
