Leonard Adleman hjälpte till att skapa RSA, ett publiknyckelsystem som möjliggjorde HTTPS, internetbanker och signerade uppdateringar. Lär dig hur det fungerar och varför det är viktigt.
När folk säger att de litar på en webbplats eller en onlinetjänst menar de vanligtvis tre praktiska saker:
RSA blev känt eftersom det hjälpte göra dessa löften möjliga i internet-skala.
Du har känt av RSA:s påverkan även om du aldrig hört namnet. Det är tätt knutet till hur:
Den gemensamma nämnaren är förtroende utan att behöva känna (eller fördela hemligheter med) varje server och programvaruleverantör du interagerar med.
Denna text håller förklaringarna enkla: ingen tung matematik och inget krav på datavetenskaplig bakgrund. Vi fokuserar på den vardagliga "varför det fungerar"-bilden.
RSA populariserade ett kraftfullt tillvägagångssätt: istället för en delad hemlighet använder du en publik nyckel som du kan dela öppet och en privat nyckel som du håller hemlig. Den uppdelningen gör det möjligt att både skydda sekretess och bevisa identitet i situationer där människor och system aldrig träffats tidigare.
Leonard Adleman är A i RSA, tillsammans med Ron Rivest och Adi Shamir. Medan Rivest och Shamir ofta krediteras för den kärnbyggnad som RSA bygger på, var Adlemans bidrag avgörande: han hjälpte forma systemet till något som inte bara var smart, utan övertygande—en algoritm som folk kunde analysera, testa och lita på.
En stor del av Adlemans roll var att pressa idén i sömmarna. Inom kryptografi är ett system inte värdefullt för att det låter rimligt; det är värdefullt för att det överlever noggranna attacker och granskning. Adleman arbetade med validering, förfinade antaganden och bidrog till hur man tidigt presenterade varför RSA borde vara svårt att bryta.
Lika viktigt var att han hjälpte översätta "det här kanske fungerar" till "det här är ett kryptosystem som andra kan utvärdera." Den klarheten—att göra designen begriplig nog för den bredare forskarkretsen att inspektera—var avgörande för att tekniken skulle bli använd.
Före RSA byggde säker kommunikation oftast på att båda parter redan delade en hemlig nyckel. Det fungerar inom slutna grupper, men skalar inte när främlingar behöver kommunicera säkert (till exempel en kund och en webbplats som träffas för första gången).
RSA ändrade den historien genom att göra en praktisk publiknyckelkryptosystem vanlig: du kan publicera en nyckel för andra att använda, samtidigt som du håller en separat privat nyckel hemlig.
RSA:s påverkan är större än en enda algoritm. Det gjorde två internetväsentligheter trovärdiga i större skala:
Dessa idéer ligger bakom hur HTTPS, internetbanker och signerade programuppdateringar blev normala förväntningar snarare än sällsynta undantag.
Före RSA innebar säker kommunikation mestadels delad-hemlighet-kryptering: båda sidor var tvungna att ha samma hemliga nyckel i förväg. Det funkar i en liten grupp, men fallerar snabbt om du försöker driva en offentlig tjänst för miljontals användare.
Om varje kund behöver en unik hemlig nyckel för att prata med en bank, måste banken generera, leverera, lagra, rotera och skydda ett enormt antal hemligheter. Det svåraste är inte matematiken—det är koordinationen.
Hur levererar du säkert den hemliga nyckeln till varje person från början? Att posta den är långsamt och riskfyllt. Att säga den över telefon kan avlyssnas eller utnyttjas via social manipulation. Att skicka den över internet underminerar syftet, eftersom det är just kanalen du försöker skydda.
Föreställ dig två främlingar—du och en webbutik—som aldrig träffats. Du vill skicka en betalning säkert. Med delad-hemlighet-kryptering skulle du behöva en privat nyckel som ni båda redan känner till. Men det gör ni inte.
RSA:s genombrott var att möjliggöra säker kommunikation utan förhandsdelad hemlighet. I stället kan du publicera en nyckel (en publik nyckel) som vem som helst kan använda för att skydda ett meddelande till dig, medan du håller en annan nyckel (privat nyckel) som bara du har.
Även om du kan kryptera meddelanden måste du fortfarande veta till vem du krypterar. Annars kan en angripare utge sig för banken eller butiken, lura dig att använda deras nyckel och tyst läsa eller ändra allt.
Därför behöver säker internetkommunikation två egenskaper:
RSA hjälpte göra båda möjliga och lade grunden för hur internetförtroende fungerar i skala.
Publiknyckelkryptografi är en enkel idé med stora konsekvenser: du kan låsa något för någon utan att först komma överens om en gemensam hemlighet. Det är den centrala förändringen RSA gjorde möjlig i praktiken.
Tänk på en publik nyckel som ett lås du gärna ger till vem som helst. Folk kan använda det för att skydda ett meddelande till dig—eller (i signatursystem) för att kontrollera att något verkligen kom från dig.
En privat nyckel är det enda du måste hålla för dig själv. Det är den nyckel som öppnar det som låstes med din publika nyckel, och den låter dig också skapa signaturer som bara du kan göra.
Tillsammans bildar den publika och privata nyckeln ett nyckelpar. De hänger ihop matematiskt, men är inte utbytbara. Att dela den publika nyckeln är säkert eftersom att känna till den inte ger någon praktisk möjlighet att härleda den privata nyckeln.
Kryptering handlar om sekretess. Om någon krypterar ett meddelande med din publika nyckel kan bara din privata nyckel dekryptera det.
Digitala signaturer handlar om förtroende och integritet. Om du signerar något med din privata nyckel kan vem som helst med din publika nyckel verifiera två saker:
Säkerheten är inget magiskt—den bygger på svåra matematiska problem som är lätta att utföra åt ena hållet men extremt svåra att vända med dagens datorer. Denna egenskap gör det säkert att dela den publika nyckeln medan den privata nyckeln behåller sin makt.
RSA bygger på en enkel asymmetri: det är lätt att göra den "framåtgående" matematiken för att låsa något, men extremt svårt att vända den för att låsa upp—om du inte har en speciell hemlighet.
Tänk på RSA som en slags matematisk hänglås. Vem som helst kan använda den publika nyckeln för att låsa ett meddelande. Men bara personen som håller den privata nyckeln kan låsa upp det.
Det som gör detta möjligt är en noggrant utvald relation mellan de två nycklarna. De genereras tillsammans, och även om de är relaterade kan du inte realistiskt härleda den privata nyckeln bara genom att titta på den publika.
På en hög nivå bygger RSA på att multiplicera stora primtal är enkelt, medan att räkna ut vilka primtal som multiplicerats (faktorisera) är extremt svårt när talen är jättestora.
För små tal går faktorisering snabbt. För de storlekar som används i riktiga RSA-nycklar (tusentals bitar) kräver de bästa kända metoderna fortfarande orimligt mycket tid och datorkraft. Denna svårighet hindrar angripare från att rekonstruera den privata nyckeln.
RSA används vanligtvis inte för att kryptera stora filer eller långa meddelanden direkt. Istället skyddar det oftast små hemligheter—framför allt en slumpmässigt genererad sessionsnyckel. Den sessionsnyckeln krypterar sedan den verkliga datan med snabbare symmetrisk kryptering, som är bättre för stora datamängder.
RSA är känt eftersom det kan göra två relaterade—men mycket olika—jobb: kryptering och digitala signaturer. Att blanda ihop dem är en vanlig källa till förvirring.
Kryptering riktar sig främst mot konfidentialitet. Digitala signaturer riktar sig främst mot integritet + äkthet.
Med RSA-kryptering använder någon din publika nyckel för att låsa något så att bara din privata nyckel kan låsa upp det.
I praktiken används RSA ofta för att skydda en liten hemlighet, som en slumpmässig sessionsnyckel. Den sessionsnyckeln krypterar sedan bulkdatan effektivt.
Vid RSA-signering vänder man på riktningen: avsändaren använder sin privata nyckel för att skapa en signatur, och vem som helst med den publika nyckeln kan verifiera:
Digitala signaturer dyker upp i vardagliga "godkännandemoment":
Kryptering bevarar hemligheter; signaturer bevarar förtroendet.
Hänglåset i din webbläsare är en genväg för en idé: din förbindelse till webbplatsen är krypterad och (vanligtvis) autentiserad. Det betyder att andra på nätverket—till exempel någon på offentligt Wi‑Fi—inte kan läsa eller tyst ändra vad din webbläsare och webbplatsen skickar till varandra.
Det betyder inte att webbplatsen är "säker" i alla avseenden. Hänglåset kan inte säga om en butik är ärlig, om en nedladdning innehåller skadlig kod eller om du skrev rätt domännamn. Det garanterar inte heller att webbplatsen kommer att skydda din data när den väl når deras servrar.
När du besöker en HTTPS-sida kör din webbläsare och servern en uppsättningssamtal kallat TLS-handshake:
Historiskt användes RSA ofta för att byta sessionsnyckeln (webbläsaren krypterar en hemlighet med serverns RSA-publika nyckel). I många moderna TLS-konfigurationer används RSA huvudsakligen för autentisering via signaturer (att bevisa servern kontrollerar den privata nyckeln), medan nyckelavtal görs med andra metoder.
RSA är utmärkt för att etablera förtroende och skydda små delar av data under uppsättning, men det är långsammare jämfört med symmetrisk kryptering. Efter handskakningen växlar HTTPS till snabba symmetriska algoritmer för att kryptera faktiska sidladdningar, inloggningar och banktransaktioner.
Internetbanker har ett enkelt löfte: du ska kunna logga in, se saldo och föra över pengar utan att någon annan lär sig dina inloggningsuppgifter—eller tyst ändrar det du skickar.
En bank-session måste skydda tre saker samtidigt:
Utan HTTPS kan vem som helst på samma Wi‑Fi, en komprometterad router eller en illvillig nätoperatör potentiellt avlyssna eller manipulera trafiken.
HTTPS (via TLS) säkrar förbindelsen så att data mellan din webbläsare och banken är krypterad och integritetskontrollerad. I praktiska termer innebär det:
RSA:s historiska roll var viktig här eftersom den hjälpte lösa "första kontakten"-problemet: att etablera en säker session över ett osäkert nätverk.
Kryptering räcker inte om du krypterar till fel part. Internetbanker fungerar bara om din webbläsare kan avgöra att den pratar med riktiga banken, inte en bedragarsajt eller en man-in-the-middle.
Banker lägger fortfarande på MFA, enhetskontroller och bedrägerimonitorering. Dessa minskar skadan när inloggningsuppgifter stulits—men ersätter inte HTTPS. De fungerar bäst som säkerhetsnät ovanpå en anslutning som redan är privat och manipulationssäker.
Programuppdateringar är lika mycket ett förtroendeproblem som ett tekniskt problem. Även om en app är väl skriven kan en angripare rikta in sig på leveranssteget—byta en legitim installationsfil mot en modifierad, eller smyga in en manipulerad uppdatering på vägen mellan utgivaren och användaren. Utan ett tillförlitligt sätt att autentisera det du laddat ner kan "uppdatering tillgänglig" bli en enkel ingång för attacker.
Om uppdateringar bara skyddas av en nedladdningslänk kan en angripare som komprometterar en mirror, kapar en nätverksförbindelse eller lurar en användare till en look‑alike-sida leverera en annan fil med samma namn. Användaren installerar den normalt, och skadan kan vara tyst: malware bundlat med uppdateringen, bakdörrar tillagda i programmet eller försvagade säkerhetsinställningar.
Kodsignering använder publiknyckelkryptografi (inklusive RSA i många system) för att fästa en digital signatur på en installationsfil eller ett uppdateringspaket.
Utgivaren signerar programvaran med en privat nyckel. Din enhet (eller operativsystem) verifierar signaturen med utgivarens publika nyckel—ofta levererad via en certifikatkedja. Om en enda byte ändrats misslyckas verifieringen. Detta skiftar förtroendet från "var laddade jag ner den?" till "kan jag verifiera vem som skapade den och att den är intakt?"
I moderna leveranspipeline sträcker sig dessa idéer bortom installationsfiler till saker som API-anrop, byggartefakter och distributionsrullar. Till exempel förlitar sig plattformar som Koder.ai (en vibe-coding-plattform för att skicka web, backend och mobilappar från ett chattgränssnitt) fortfarande på samma grund: HTTPS/TLS för data i transit, noggrann certifikathantering för egna domäner och praktiska rollback-arbetssätt (snapshots och återställningspunkter) för att minska risken vid utrullning.
Signerade uppdateringar minskar antalet obemärkta manipuleringsmöjligheter. Användare får tydligare varningar när något är fel, och automatiska uppdateringssystem kan avvisa ändrade filer innan de körs. Det är ingen garanti för att själva programvaran är buggfri, men det är ett kraftfullt försvar mot utgivarförfalskning och leverantörskedjeangrepp.
För att fördjupa dig om hur signaturer, certifikat och verifiering hänger ihop, se /blog/code-signing-basics.
Om RSA ger dig en publik nyckel uppstår en naturlig fråga: vems publik nyckel är det?
Ett certifikat är internets svar. Det är en liten signerad datafil som kopplar en publik nyckel till en identitet—som ett webbplatsnamn (example.com), en organisation eller en programvaruutgivare. Tänk på det som ett ID-kort för en nyckel: det säger "den här nyckeln tillhör det här namnet" och innehåller detaljer som ägaren, den publika nyckeln och giltighetsdatum.
Certifikat spelar roll eftersom de signeras av någon annan. Den "någon" är vanligtvis en Certificate Authority (CA).
En CA är en tredje part som kontrollerar vissa bevis (som kan sträcka sig från grundläggande domänkontroll till djupare företagsverifiering) och sedan signerar certifikatet. Din webbläsare eller ett operativsystem levereras med en inbyggd lista över betrodda CA. När du besöker en sajt via HTTPS använder din enhet den listan för att avgöra om certifikatets påstående är acceptabelt.
Systemet är inte perfekt: CA kan göra misstag och angripare kan försöka lura eller kompromettera dem. Men det skapar en praktisk förtroendekedja som fungerar i global skala.
Certifikat löper ut med flit. Kortare livslängd begränsar skadan om en nyckel stulits och uppmuntrar regelbundet underhåll.
Certifikat kan också revokeras före utgång. Revokation är ett sätt att säga "sluta lita på detta certifikat", till exempel om en privat nyckel kan ha läckt eller certifikatet utfärdats felaktigt. Enheter kan kontrollera revokationsstatus (med varierande pålitlighet och strikthet), vilket är en anledning till att nyckelvård fortfarande är viktigt.
Håll din privata nyckel privat: förvara den i säker nyckelhantering, begränsa åtkomst och undvik att kopiera den mellan system i onödan.
Rotera nycklar vid behov—efter incidenter, under planerade uppgraderingar eller när policy kräver det. Följ också utgångsdatum så att förnyelser inte blir sista-minuten-kriser.
RSA är en grundläggande idé, men det är inget magiskt sköld. De flesta verkliga intrång händer inte för att någon "löste RSA"—de händer för att systemen runt RSA brister.
Flera mönster återkommer:
RSA:s säkerhet beror på att generera nycklar som är tillräckligt stora och verkligt oförutsägbara. Bra slumpmässighet är avgörande: om nyckelgenerering använder en svag slumpkälla kan angripare ibland återskapa eller begränsa möjliga nycklar. Likaså spelar nyckellängd roll eftersom förbättringar i beräkningskraft och matematiska tekniker gradvis minskar marginalen för små nycklar.
RSA-operationer är tyngre än moderna alternativ, vilket är anledningen till att många protokoll använder RSA sparsamt—ofta för autentisering eller att byta en tillfällig hemlighet—och sedan växlar till snabbare symmetrisk kryptering för bulkdata.
Säkerhet fungerar bäst som försvar-i-djupet: skydda privata nycklar (helst i hårdvara), övervaka certifikatutgivning, patcha system, använd phishing-resistent autentisering och designa för säker nyckelrotation. RSA är ett verktyg i kedjan—not hela kedjan.
RSA är ett av de mest stödda kryptoverktygen på internet. Även om en tjänst inte "föredrar" RSA längre behåller den ofta kompatibilitet eftersom det är överallt: äldre enheter, långlivade företagsystem och certifikatinfrastrukturer byggda över många år.
Kryptografi utvecklas av samma skäl som annan säkerhetsteknik:
Du ser ofta alternativ i TLS och moderna applikationer:
Tydligt: RSA kan göra både kryptering och signaturer, men nyare system delar ofta upp arbetet—använder en metod optimerad för signaturer och en annan för att etablera sessionsnycklar.
Nej. RSA stöds fortfarande i stor utsträckning och är ett giltigt val i många sammanhang, särskilt där bakåtkompatibilitet är kritisk eller där befintliga certifikats- och nyckelhanteringsrutiner är byggda kring det. Det "bästa" valet beror på faktorer som enhetsstöd, prestandakrav, efterlevnadskrav och hur nycklar lagras och roteras.
Om du vill se hur dessa val dyker upp i verkliga HTTPS-anslutningar är nästa steg: /blog/ssl-tls-explained.
RSA gjorde internet-skala förtroende praktiskt möjligt genom att möjliggöra publiknyckelkryptografi, vilket stöder:
Dessa byggstenar är centrala för HTTPS, internetbanker och signerade programuppdateringar.
Leonard Adleman hjälpte till att göra RSA från en smart idé till ett kryptosystem som andra kunde analysera och lita på. I praktiken innebar det att han stressade systemet med kritisk granskning, förtydligade antaganden och stärkte argumentet för varför RSA bör vara svårt att knäcka i realistiska attacker.
En publik nyckel är avsedd att delas; folk använder den för att kryptera något till dig eller för att verifiera dina signaturer.
En privat nyckel måste hållas hemlig; den används för att dekryptera det som krypterats till dig (i RSA-krypteringsupplägg) och för att skapa signaturer som bara du kan göra.
Om den privata nyckeln läcker kan angripare utge sig för dig och/eller dekryptera skyddade hemligheter beroende på hur nyckeln används.
RSA:s säkerhet bygger i stort på ett enkelriktat matematiskt problem: att multiplicera stora primtal är enkelt, men att faktorisera det resulterande mycket stora talet tillbaka till primtal är extremt svårt vid verkliga nyckelstorlekar.
De publika och privata nycklarna är matematiskt relaterade, men relationen är utformad så att den publika nyckeln inte i praktiken avslöjar den privata.
De löser olika mål för förtroende:
En enkel tumregel: kryptering bevarar hemligheter; signaturer bevisar vem som skickade något och att det inte ändrats.
I en förenklad TLS-flöde:
RSA kan användas för autentisering (signaturer), och historiskt användes det även för att skydda den initiala sessionshemligheten i vissa konfigurationer.
Nej. Hänglåset visar i huvudsak att förbindelsen är krypterad och vanligtvis autentiserad.
Det garanterar inte att:
Se HTTPS som ett nödvändigt transportskydd, inte som en fullständig bedömning av förtroende.
Ett certifikat binder en publik nyckel till en identitet (som ett domännamn). Webbläsare litar på den bindningen eftersom ett Certificate Authority (CA) signerar certifikatet, och webbläsare/OS levereras med en lista över betrodda CA.
Om du driftsätter tjänster, planera för:
Signerade uppdateringar låter din enhet verifiera två saker:
Det försvarar mot "byt paketet"-attacker (komprometterade mirrors, kapade nätverk, look-alike nedladdningssidor).
Vanliga verkliga fel är oftast operationella, inte att "RSA-matematiken spruckit":
Praktiska åtgärder: skydda privata nycklar (helst hårdvarubackad lagring), följ utgångsdatum, rotera nycklar planerat och övervaka certifikatutgivning där det är möjligt.
