RSA-4096 høres tryggere ut enn RSA-2048. Dobbelt så mange bits burde jo bety dobbelt så god beskyttelse. Virkeligheten er mer nyansert: ifølge Yubicos egen analyse gir dobling av nøkkellengden fra 2048 til 4096 bit kun 18 ekstra sikkerhetsbits, en økning på bare 16 prosent i reell styrke, mens signeringsoperasjonen samtidig kan bli mer enn 7 ganger tregere. Det er det klassiske dilemmaet norske utviklere, sikkerhetsarkitekter og DevOps-team står i når de skal velge nøkkelstørrelse for TLS-sertifikater, SSH-nøkler, kodesignering og KMS-tjenester i 2026.
Denne artikkelen går gjennom de faktiske tallene: ytelsesbenchmark fra tre uavhengige kilder, prising hos AWS, Google Cloud og Azure, hva NSA, NIST, BSI og CA/Browser Forum faktisk krever i 2026, og en praktisk migreringsguide. Målet er ikke å hylle den ene nøkkelstørrelsen, men å gi deg data til å ta en informert beslutning for akkurat ditt system.
Hva er RSA, og hvorfor betyr nøkkelstørrelse noe
RSA er en asymmetrisk krypteringsalgoritme fra 1977, oppkalt etter oppfinnerne Rivest, Shamir og Adleman. Sikkerheten hviler på at det er beregningsmessig svært tungt å faktorisere store tall som er produktet av to primtall. Nøkkelstørrelsen, målt i bits, angir hvor stort dette tallet (modulusen) er. Jo større modulus, desto mer regnekraft kreves for å faktorisere den og dermed knekke nøkkelen med klassiske datamaskiner.
RSA-2048 har vært industristandarden siden midten av 2000-tallet, etter at RSA-1024 ble ansett som for svakt i takt med at datakraften økte og faktoriseringsangrep ble billigere å utføre. RSA-4096 dukker stadig oftere opp i kravspesifikasjoner for langtidslagrede signaturer, rot-sertifikater og PGP-nøkler for utviklere som vil ha ekstra sikkerhetsmargin. Men flere bits koster alltid noe: mer CPU-tid, mer minne, tregere håndtrykk og i noen skytjenester også høyere pris. Spørsmålet er om den ekstra marginen er verdt kostnaden for akkurat ditt bruksområde, og det er nettopp det denne sammenligningen skal svare på.
Norske og nordiske virksomheter møter denne avveiningen oftere enn de fleste tror, fra bankenes API-gatewayer og offentlige etaters e-signeringsløsninger til utviklere som setter opp sin første egen PKI for interne tjenester. Fordi kravene fra NSA, BSI og CA/Browser Forum stadig strammes til, holder det ikke lenger å velge nøkkelstørrelse basert på magefølelse eller det som “alltid har vært standard”. Beslutningen bør bygge på faktiske tall for ytelse, kostnad og hvilken frist det aktuelle systemet må forholde seg til.
RSA-2048 vs RSA-4096: full spesifikasjonstabell
Under følger en samlet oversikt over de tekniske forskjellene mellom de to nøkkelstørrelsene, basert på NIST SP 800-57, OpenSSL-benchmarks og offentlig dokumentasjon fra CA/Browser Forum og BSI.
| Egenskap | RSA-2048 | RSA-4096 |
|---|---|---|
| Nøkkelstørrelse (modulus) | 2048 bit | 4096 bit |
| Sikkerhetsstyrke (NIST SP 800-57) | ~112 bit | ~140-150 bit (avhengig av kilde) |
| Signeringshastighet (OpenSSL, kilde A) | 264,7 signeringer/sek | 44,2 signeringer/sek |
| Verifiseringshastighet (OpenSSL, kilde A) | 10 899,5 verifiseringer/sek | 3 275,4 verifiseringer/sek |
| Signeringshastighet (OpenSSL, kilde B) | 1009,1 signeringer/sek | 90,3 signeringer/sek |
| Verifiseringshastighet (OpenSSL, kilde B) | 22 220,4 verifiseringer/sek | 6 054,5 verifiseringer/sek |
| Gjennomsnittlig TLS-håndtrykk (nettleser-test) | ~50 ms | ~76 ms |
| CPU-overhead relativt til RSA-2048 | Basislinje | Ca. 7-8x mer CPU per signering |
| NSA CNSA 2.0-status (mai 2025) | Ikke tilstrekkelig for nye systemer | Møter 3072-bit minimumskrav |
| NIST-anbefalt levetid | Til og med 31. desember 2030 | Anbefalt utover 2030 |
| BSI TR-02102-1 (2026)-krav | Under anbefalt minimum | Over anbefalt minimum (≥3000 bit) |
| CA/Browser Forum S/MIME rot-CA (fra 15.09.2026) | Ikke tillatt for nye rot-CA-nøkler | Påkrevd minimum |
| Standard i Let’s Encrypt (klient-standard) | Ja, standardvalg | Støttet, må velges aktivt |
| Standard i moderne GnuPG (≥2.2.22) | Eldre standard | Ikke standard (3072 er ny standard) |
| Antatte qubits for å knekke med Shors algoritme (Gidney, 2025) | ~1400 logiske / under 1 million fysiske | Ikke offentliggjort presist tall, men vesentlig høyere |
Legg merke til at sikkerhetsgevinsten ikke er lineær med nøkkelstørrelsen. Å doble modulusen fra 2048 til 4096 bit gir langt fra en dobling av sikkerhetsstyrken, mens ytelseskostnaden vokser mye raskere. Det er nøyaktig dette forholdet som gjør valget mellom de to nøkkelstørrelsene til en avveining, ikke et opplagt “større er bedre”-spørsmål.
Ytelsesbenchmark: signering og verifisering fra tre kilder
Tallene over stammer fra flere uavhengige OpenSSL-benchmarker, og forskjellene mellom kildene illustrerer hvor mye maskinvare, OpenSSL-versjon og testoppsett påvirker resultatet. I den første kilden gikk signeringshastigheten fra 264,7 operasjoner per sekund med RSA-2048 til 44,2 operasjoner per sekund med RSA-4096, en nedgang på rundt 6 ganger. Verifisering falt fra 10 899,5 til 3 275,4 operasjoner per sekund, altså en faktor på 3,3.
Den andre kilden viste et enda skarpere fall: 1009,1 signeringer per sekund med RSA-2048 mot bare 90,3 med RSA-4096, en nedgang på 11,2 ganger. Verifiseringen falt fra 22 220,4 til 6 054,5 operasjoner per sekund, tilsvarende 3,7 ganger tregere. Forfatteren Nicolás T. Soi dokumenterte i sin egen benchmark at det tar over syv ganger så mye CPU-tid å signere med 4096-bit RSA-nøkler sammenlignet med 2048-bit, i tråd med begge de andre kildene.
Mønsteret er konsistent på tvers av alle tre benchmarkene: signeringsoperasjonen, som bruker den private nøkkelen, rammes hardest av den økte nøkkelstørrelsen, mens verifisering med den offentlige nøkkelen holder seg relativt raskere selv med 4096-bit nøkler. Det betyr at RSA-4096 rammer serversiden (som signerer TLS-håndtrykk) langt hardere enn klientsiden (som verifiserer signaturen).
TLS-håndtrykk: hvor mye tregere blir nettsiden
For en vanlig nettside er det håndtrykkstiden brukeren faktisk merker. En nettleserbasert test målte et gjennomsnittlig håndtrykk på 50 millisekunder med RSA-2048, mot 76 millisekunder med RSA-4096. Det er en økning på 26 millisekunder, tilsvarende 52 prosent mer forsinkelse per tilkobling. På en enkelt sidevisning er 26 millisekunder knapt merkbart. På en høytrafikksside med tusenvis av nye TLS-tilkoblinger i sekundet, multiplisert med serverens CPU-budsjett, blir regnestykket et helt annet.
Nicolás T. Soi oppsummerte dette poenget presist i sin egen analyse, der han argumenterer for at RSA-nøkler sterkere enn 2048 bit og ECDSA-nøkler sterkere enn 256 bit for de fleste nettsteder er bortkastet CPU-kraft som kan svekke brukeropplevelsen. Det er verdt å understreke at dette gjelder rene TLS-serversertifikater med høyt trafikkvolum, ikke nødvendigvis rot-CA-nøkler eller PGP-nøkler som brukes sjeldnere og har helt andre trusselmodeller.
De fleste moderne TLS-oppsett bruker uansett ECDHE for selve nøkkelutvekslingen og lar RSA (eller ECDSA) kun signere håndtrykket, noe som demper den totale effekten av nøkkelstørrelsen på oppkoblingstiden sammenlignet med rene RSA-nøkkelutvekslinger fra TLS 1.2 og eldre.
Sikkerhetsstyrke: hva sier NIST faktisk
NIST SP 800-57 setter sikkerhetsstyrken til RSA-2048 til omtrent 112 bit, mens RSA-4096 havner et sted mellom 140 og 150 bit avhengig av hvilken tilnærming som brukes for å beregne ekvivalens. Yubico har regnet ut den praktiske konsekvensen av dette presist. Selskapet skriver i sin analyse at selv om en lengre nøkkel gir bedre sikkerhet, viser deres egne beregninger at å doble nøkkellengden fra 2048 til 4096 bit kun øker sikkerhetsstyrken med 18 bit, tilsvarende 16 prosent. Det er dette misforholdet mellom oppfattet og faktisk sikkerhetsgevinst som gjør RSA-4096 til et dårligere kompromiss enn mange antar.
NIST publiserte i 2025 et utkast til revisjon 6 av SP 800-57 del 1, som er åpent for offentlig høring. Utkastet bekrefter at RSA-2048 (112-bit sikkerhet) anses som tilstrekkelig frem til 31. desember 2030 for de fleste bruksområder, men at data som må forbli konfidensiell lenger enn det bør bruke sterkere nøkler allerede nå. For langtidslagrede signaturer, arkiv-integritet og PGP-nøkler som skal vare i tiår, gir dette et konkret argument for RSA-3072 eller RSA-4096.
CPU- og minnebruk i praksis: hva koster det egentlig serveren
En vanlig tommelfingerregel, bekreftet i flere Stack Exchange-diskusjoner om ytelse, er at “RSA 4096-bit nøkkelstørrelse krever omtrent 8 ganger mer CPU-sykluser enn 2048-bit RSA-nøkkelstørrelse”. Det stemmer godt med de tre OpenSSL-benchmarkene over, der signeringen ble mellom 6 og 11 ganger tregere. Minnebruken øker også, men i mindre grad enn CPU-belastningen, siden RSA-nøkler uansett er relativt små sammenlignet med for eksempel symmetriske krypteringsbuffere.
Praktisk betyr dette at en lastbalansert webtjeneste som terminerer TLS med RSA-4096 trenger vesentlig flere CPU-kjerner for å håndtere samme antall nye tilkoblinger per sekund som med RSA-2048, eller den må lene seg tyngre på TLS-sesjonsgjenopptak og sesjonsbilletter for å unngå å gjøre et fullt håndtrykk for hver ny klient. For interne tjenester med lavt tilkoblingsvolum, som en intern API-gateway eller en administrasjonskonsoll, er merkostnaden i praksis usynlig.
Jacob Appelbaum pekte på et beslektet poeng i sin analyse av nøkkelstørrelser: at ytelsen til RSA-operasjoner med den private nøkkelen begynner å svekkes ved 4096 bit, og at båndbreddekravene skaper problemer i enkelte protokoller. Dette gjelder spesielt protokoller med strenge pakkestørrelsesgrenser, som enkelte IoT- og innbygde systemer der større RSA-signaturer rett og slett ikke får plass i forventet pakkestørrelse.
Prisforskjell i skyen: AWS KMS, Google Cloud KMS og Azure Key Vault
Noe som overrasker mange team er at nøkkelstørrelse faktisk påvirker den månedlige skyfakturaen, ikke bare ytelsen. De tre store skyleverandørene prissetter RSA-4096 høyere enn RSA-2048 for enkelte tjenestenivåer, mens andre nivåer har lik pris uavhengig av nøkkelstørrelse.
| Tjeneste | RSA-2048 lagring | RSA-4096 lagring | RSA-2048 operasjoner | RSA-4096 operasjoner |
|---|---|---|---|---|
| AWS KMS (kundeadministrert nøkkel) | $1,00/nøkkel/mnd | $1,00/nøkkel/mnd | $0,03 per 10 000 | $0,15 per 10 000 |
| Google Cloud KMS (programvarebeskyttet) | ≈$0,06/nøkkelversjon/mnd | ≈$0,06/nøkkelversjon/mnd | $0,03 per 10 000 | $0,03 per 10 000 |
| Google Cloud HSM | $1,00/nøkkelversjon/mnd | $2,50/nøkkelversjon/mnd (0-2000 versjoner) | $0,03 per 10 000 | $0,03 per 10 000 |
| Azure Key Vault (programvarebeskyttet) | $1,00/nøkkel/mnd | $5,00/nøkkel/mnd (første 250 nøkler) | $0,03 per 10 000 | $0,15 per 10 000 |
Legg merke til at AWS og Azure begge flytter RSA-4096-operasjoner over i en dyrere kategori kalt “annen asymmetrisk”, priset til $0,15 per 10 000 forespørsler mot $0,03 for RSA-2048, en femdobling av transaksjonskostnaden. Google Cloud KMS skiller seg ut ved å holde operasjonsprisen lik for begge nøkkelstørrelser i programvaremodus, men innfører en betydelig prisøkning for RSA-4096 i sin HSM-beskyttede tjeneste (Cloud HSM).
For et team som signerer eller krypterer millioner av forespørsler i måneden, kan valget mellom RSA-2048 og RSA-4096 i AWS KMS alene utgjøre forskjellen mellom noen få dollar og flere hundre dollar ekstra per måned, kun i transaksjonsgebyrer, før man engang har lagt til den økte CPU-tiden på applikasjonssiden. Sertifikatprisen hos kommersielle CA-er som DigiCert og Sectigo påvirkes derimot ikke av nøkkelstørrelse: begge selskapene selger samme sertifikatprodukt uansett om kunden velger RSA-2048, RSA-3072 eller RSA-4096.
Et konkret regnestykke gjør forskjellen tydeligere. Si at en tjeneste gjør 50 millioner signeringsoperasjoner i måneden gjennom AWS KMS. Med RSA-2048, priset til $0,03 per 10 000 forespørsler, blir kostnaden om lag $150 i måneden. Med RSA-4096, som havner i kategorien “annen asymmetrisk” til $0,15 per 10 000 forespørsler, stiger den samme regningen til $750 i måneden, kun for API-kallene. Legg til $1 per nøkkel i måneden for lagring, som er lik for begge størrelsene i AWS KMS, og den reelle kostnadsforskjellen ved høyt volum blir tydelig før man i det hele tatt har regnet på ekstra EC2- eller Lambda-kapasitet for den tregere signeringen.
I Azure Key Vault er forskjellen enda skarpere for nøkkellagring: RSA-2048 koster $1 per nøkkel i måneden, mens RSA-4096 klassifiseres som en “avansert nøkkeltype” til $5 per nøkkel i måneden for de første 250 nøklene. For en organisasjon med hundrevis av nøkler spredt over flere miljøer og team, kan dette alene utgjøre flere tusen dollar i årlig merkostnad, uavhengig av hvor ofte nøklene faktisk brukes til signering eller kryptering.
Kvantetrusselen: hva sier den nyeste forskningen om Shors algoritme
Google-forsker Craig Gidney publiserte i mai 2025 en oppsiktsvekkende oppdatering av kvanteregnestykket for RSA. I artikkelen “How to factor 2048-bit RSA integers with less than a million noisy qubits” (arXiv:2505.15917) viser Gidney at en feiltolerant kvantedatamaskin med færre enn én million fysiske qubits, og rundt 1400 logiske qubits, i teorien kan faktorisere en 2048-bit RSA-nøkkel på under en uke. Det er en dramatisk nedjustering fra tidligere anslag, som opererte med langt høyere qubit-tall og lengre kjøretider.
For RSA-4096 finnes det foreløpig ingen tilsvarende presis, oppdatert kvanteberegning offentliggjort i samme detaljnivå. Det generelle mønsteret i Shors algoritme tilsier at ressursbehovet vokser mer enn lineært med nøkkellengden, slik at RSA-4096 krever vesentlig flere qubits og lengre kjøretid enn RSA-2048, men eksakte 2025-tall for 4096-bit er ikke publisert med samme presisjon som Gidneys RSA-2048-resultat. Konklusjonen mange kryptografer trekker av dette er at å doble nøkkelstørrelsen for å “vente ut” kvantetrusselen er en dårlig strategi sammenlignet med å migrere til postkvante-algoritmer som ML-KEM og ML-DSA, siden ingen klassisk RSA-størrelse er immun mot en tilstrekkelig stor kvantedatamaskin på lang sikt.
Det er verdt å presisere at ingen kryptografisk relevante kvantedatamaskiner eksisterer i dag som kan utføre dette angrepet. Gidneys resultat er et teoretisk ressursanslag, ikke en beskrivelse av en maskin som finnes. Likevel er anslaget lavt nok til at flere myndigheter, deriblant NSA og NIST, nå anbefaler at systemer som beskytter langtidssensitiv informasjon planlegger overgang til postkvante-kryptografi i god tid før 2030.
Hva krever NSA, NIST, BSI og CA/Browser Forum i 2026
Reguleringsbildet har strammet seg tydelig til gjennom 2025 og 2026. NSAs Commercial National Security Algorithm Suite 2.0 (CNSA 2.0), publisert 30. mai 2025, setter et minimumskrav på 3072-bit RSA-modulus for digitale signaturer på alle klareringsnivåer. Tidsplanen krever at ny programvare og fastvare bruker CNSA 2.0-kompatible signeringsalgoritmer allerede fra 2025, mens all eksisterende programvare og fastvare skal være fullstendig overført innen 2030.
Det tyske BSI (Bundesamt für Sicherheit in der Informationstechnik) krever i sin tekniske retningslinje TR-02102-1, versjon 2026-01, at “lengden på modulusen n bør være minst 3000 bit”, noe som i praksis utelukker RSA-2048 fra nye BSI-kompatible systemer. CA/Browser Forum vedtok gjennom Ballot SMC017 en økning av minimumskravet for RSA-nøkler i rot- og mellomliggende CA-sertifikater for S/MIME fra 2048 til 4096 bit for nøkler opprettet fra og med 15. september 2026. Samme ballot fastslår at fra 15. september 2027 skal CA-er ikke lenger utstede sluttbrukersertifikater fra noen underliggende CA med RSA-modulus under 3072 bit, noe som effektivt fjerner 2048-bit CA-infrastruktur fra økosystemet.
| Instans | Krav | Frist |
|---|---|---|
| NSA CNSA 2.0 | Minimum 3072-bit RSA-modulus for signaturer | Nye systemer fra 2025, alle systemer innen 2030 |
| NIST SP 800-57 (utkast rev. 6) | RSA-2048 (112-bit) akseptabelt for generell bruk | Til og med 31. desember 2030 |
| BSI TR-02102-1 (versjon 2026-01) | RSA-modulus minst 3000 bit | Gjeldende nå |
| CA/Browser Forum S/MIME (rot/mellom-CA) | Minimum 4096-bit RSA for nye CA-nøkler | Fra 15. september 2026 |
| CA/Browser Forum S/MIME (underliggende CA) | Stans i utstedelse fra CA-er med under 3072-bit nøkler | Fra 15. september 2027 |
Legg merke til at disse kravene i stor grad retter seg mot signaturnøkler, rot-CA-er og statlig/høysikkerhetsbruk, ikke nødvendigvis mot vanlige TLS-serversertifikater for webtrafikk, der RSA-2048 fortsatt er utbredt og akseptert av alle større nettlesere og CA-er i 2026.
RSA-3072: mellomveien de fleste standardene faktisk peker mot
Et poeng som ofte forsvinner i en ren RSA-2048 vs RSA-4096-diskusjon er at nesten ingen av de store standardene og myndighetene faktisk krever 4096 bit som minimum. Både NSA CNSA 2.0 og BSI TR-02102-1 setter grensen ved omtrent 3000-3072 bit, ikke 4096. CA/Browser Forums skjerpede krav for S/MIME gjelder spesifikt rot- og mellomliggende CA-nøkler, mens underliggende CA-er kun må opp til minst 3072 bit innen 2027. Moderne GnuPG-versjoner fra og med 2.2.22 genererer nettopp 3072-bit nøkler som standard, ikke 4096.
Det er en fornuftig logikk bak dette. RSA-3072 gir en sikkerhetsstyrke rundt 128 bit, godt over NIST-terskelen for langtidsbeskyttelse, samtidig som ytelseskostnaden er langt lavere enn ved 4096 bit. Siden signeringstiden vokser om lag kubisk med modulusstørrelsen i klassiske RSA-implementasjoner, havner RSA-3072 et sted midt mellom RSA-2048 og RSA-4096 i praktisk ytelse, men nærmere 2048 enn mange forventer. For team som synes RSA-4096 blir for tregt, men som vil møte CNSA 2.0- eller BSI-kravene, er RSA-3072 ofte den beste kompromissløsningen, ikke det ene eller det andre ytterpunktet.
Svakheten med RSA-3072 er praktisk snarere enn kryptografisk: færre systemer har eksplisitt testet og dokumentert ytelse ved denne nøkkelstørrelsen sammenlignet med de langt mer benchmarkede 2048- og 4096-bit variantene, og enkelte eldre biblioteker og innebygde systemer mangler støtte for ikke-standardiserte modulusstørrelser. Sjekk derfor kompatibiliteten med hele kjeden, fra klientbibliotek til lastbalanser og HSM, før du velger 3072 bit som produksjonsstandard.
Fem virkelige eksempler: hvem bruker hva i praksis
Teorien blir tydeligere når man ser på hva faktiske systemer og organisasjoner velger i 2025-2026. Her er fem konkrete eksempler som viser at valget mellom RSA-2048 og RSA-4096 varierer mye etter bruksområde.
- Let’s Encrypt: Aksepterer RSA-nøkler på 2048, 3072 eller 4096 bit samt P-256/P-384 ECDSA-nøkler, men standardklienten (Certbot) genererer 2048-bit RSA-nøkler med mindre brukeren eksplisitt ber om noe annet med flagget –rsa-key-size.
- OpenSSH ssh-keygen: Standard nøkkeltype er i dag Ed25519 (siden OpenSSH 9.5), men når RSA fortsatt velges eksplisitt, er standard nøkkellengde 3072 bit ifølge OpenBSDs offisielle ssh-keygen-manual, ikke lenger 2048 slik det historisk var.
- DNSSEC-rotsonen: ICANNs rotsone signeres i dag med RSA/SHA-256 og 2048-bit nøkler for både KSK (key signing key) og ZSK (zone signing key). Et forslag fra mai 2026 vurderer å bytte rot-KSK til ECDSA P-256, men dagens driftsstatus er fortsatt RSA-2048.
- GnuPG/OpenPGP: Fra og med versjon 2.2.22 (august 2020) genererer GnuPG som standard 3072-bit RSA-nøkkelpar, en oppgradering fra den tidligere 2048-bit standarden. Mange prosjekter, deriblant Apache, anbefaler eksplisitt minst RSA-4096 for kodesigneringsnøkler som skal vare lenge.
- CA/Browser Forum S/MIME rot-CA-er: Fra 15. september 2026 må alle nye rot- og mellomliggende CA-nøkler for S/MIME være minst 4096-bit RSA, en direkte konsekvens av Ballot SMC017 og et tydelig signal om at høysikkerhets-CA-infrastruktur beveger seg bort fra 2048-bit.
Mønsteret som trer frem er konsekvent: økosystemer med høyt volum og lav trusselgrad for enkeltnøkkelen (TLS-servere, DNS-soner) holder seg til RSA-2048 eller går til ECC, mens økosystemer med lavt volum og høy verdi per nøkkel (rot-CA-er, PGP-signering, langtidsarkivering) beveger seg mot RSA-4096 eller enda sterkere alternativer.
Ekspertenes syn på RSA-2048 vs RSA-4096
Flere fagfolk i sikkerhetsmiljøet har uttalt seg konkret om denne avveiningen. Nicolás T. Soi, som selv kjørte ytelsestester på Nginx med begge nøkkelstørrelsene, skrev i sin analyse: “For most web sites, using RSA keys stronger than 2048 bits and ECDSA keys stronger than 256 bits is a waste of CPU power and might impair user experience” (kilde), altså at ekstra store nøkler for de fleste nettsteder gir dårligere brukeropplevelse uten tilsvarende sikkerhetsgevinst. I samme test dokumenterte han: “As you can see from the results, it takes more than 7 times the CPU time to sign 4096-bit RSA keys compared to 2048-bit” (kilde).
Sikkerhetsselskapet Yubico har argumentert direkte mot antagelsen om at større alltid er bedre: “While it is true that a longer key provides better security, we have shown that by doubling the length of the key from 2048 to 4096, the increase in bits of security is only 18, a mere 16%” (kilde), altså kun 16 prosent mer reell sikkerhetsstyrke for en dobling av nøkkellengden. Forfatteren og sikkerhetsforskeren Jacob Appelbaum har på sin side pekt på de praktiske grensene ved store RSA-nøkler: “The performance of RSA private-key operations starts to suffer at 4096, and the bandwidth requirements is causing issues in some protocols” (kilde), et poeng som særlig gjelder protokoller med strenge pakkestørrelsesgrenser.
Disse tre stemmene peker i samme retning: den ekstra sikkerhetsmarginen fra RSA-4096 er reell, men liten, mens ytelseskostnaden er stor og til dels uforholdsmessig. Det gjør RSA-4096 til et fornuftig valg for spesifikke, lavvolums, høyverdi-scenarier, men til et dårlig standardvalg for generell webtrafikk.
Bruksområder: når bør du velge hva
Basert på ytelsesdataene, prisingen og regelverket over, kan man sette opp klare anbefalinger for ulike scenarier.
- Offentlige webservere med høyt trafikkvolum: RSA-2048, eventuelt ECDSA P-256, gir best balanse mellom sikkerhet og ytelse. Håndtrykkstiden holder seg lav og CPU-kostnaden per tilkobling er håndterbar selv ved høy last.
- Interne API-er og administrasjonssystemer med lavt volum: RSA-4096 er et trygt valg her, siden det lave tilkoblingsvolumet gjør at CPU-merkostnaden knapt merkes, samtidig som man får ekstra sikkerhetsmargin for følsomme interne systemer.
- Rot- og mellomliggende CA-nøkler: RSA-4096 bør brukes som standard for nye rot-CA-er i 2026, i tråd med CA/Browser Forums S/MIME-krav og BSIs anbefaling om minst 3000-bit modulus. Disse nøklene signerer sjelden, men beskytter enormt mye nedstrøms tillit.
- PGP/GPG-nøkler for kodesignering og personlig e-post: RSA-4096 eller helst en Curve25519-basert nøkkel er å foretrekke, siden signeringsfrekvensen er lav og nøkkelen typisk skal vare i mange år.
- KMS-baserte krypteringstjenester med høyt transaksjonsvolum: RSA-2048 er ofte det økonomisk fornuftige valget i AWS KMS og Azure Key Vault, siden RSA-4096-operasjoner koster fem ganger så mye per transaksjon i begge disse tjenestene.
- DNSSEC-signering: Følg praksis fra rotsonen og de fleste TLD-er med RSA-2048, eller vurder en overgang til ECDSA P-256 for lavere signaturstørrelse og raskere validering.
- Langtidsarkivering og juridisk bindende dokumentsignering: RSA-4096 gir en fornuftig sikkerhetsmargin for dokumenter som skal forbli verifiserbare i flere tiår, spesielt kombinert med tidsstempling fra en pålitelig tredjepart.
Migreringsguide: fra RSA-2048 til RSA-4096
Dersom du har vurdert avveiningene over og bestemt deg for å oppgradere kritiske nøkler til RSA-4096, følger her en praktisk fremgangsmåte for en trygg migrering.
Steg 1: Kartlegg hvor RSA-2048 brukes i dag. Lag en fullstendig oversikt over TLS-sertifikater, SSH-nøkler, PGP-nøkler, KMS-nøkler og signeringsnøkler i CI/CD-pipeline. Prioriter rot- og mellomliggende CA-nøkler samt langtidssignaturer først, siden disse har størst gevinst av oppgraderingen.
Steg 2: Test ytelseskonsekvensen i et separat miljø. Generer en RSA-4096-nøkkel og kjør samme lastprofil som produksjon mot et testmiljø, for å måle faktisk økning i responstid og CPU-bruk under realistiske forhold.
# Generer en ny RSA-4096-nøkkel med OpenSSL
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 -out ny_nokkel_4096.pem
# Generer tilhørende CSR (certificate signing request)
openssl req -new -key ny_nokkel_4096.pem -out ny_forespoersel.csr -sha256
# Sammenlign signeringshastighet mellom nøkkelstørrelsene lokalt
openssl speed rsa2048 rsa4096Steg 3: Oppdater sertifikatutstedelse. De fleste CA-er, inkludert Let’s Encrypt via Certbot-flagget –rsa-key-size 4096, DigiCert og Sectigo, støtter RSA-4096 uten prisforskjell for TLS-sertifikater. For interne PKI-er må rot- og mellomliggende CA-sertifikater fornyes med de nye nøklene før sluttbrukersertifikater kan signeres med dem.
Steg 4: Rull ut gradvis, ikke alt på én gang. Start med interne, lavvolums tjenester for å validere at applikasjonslogikk, lastbalansere og overvåkning håndterer de større nøklene og signaturene korrekt. Vent med høytrafikk-servere til du har bekreftet at CPU-budsjettet tåler den økte belastningen.
Steg 5: Oppdater KMS-konfigurasjon med kostnadsbevissthet. Hvis du bruker AWS KMS, Google Cloud KMS eller Azure Key Vault, sjekk prisarkene før du bytter nøkkelstørrelse i produksjon, siden RSA-4096-operasjoner koster vesentlig mer per transaksjon i både AWS og Azure.
Steg 6: Revoker og fas ut gamle nøkler kontrollert. Ikke slett RSA-2048-nøkler umiddelbart. Behold dem tilgjengelig for verifisering av eksisterende signaturer i en overgangsperiode, men fjern dem fra aktiv signering og fra CRL/OCSP-utstedelse så snart de nye nøklene er fullt operative.
Slik sjekker du hvilken nøkkelstørrelse et sertifikat allerede bruker
Før du planlegger en migrering, bør du kartlegge hva som faktisk er i produksjon i dag. OpenSSL gir et raskt svar på nøkkelstørrelsen til både lokale nøkkelfiler og eksterne TLS-sertifikater, uten at du trenger tilgang til den private nøkkelen for å sjekke et offentlig sertifikat.
# Sjekk nøkkelstørrelsen til en lokal privatnøkkel
openssl rsa -in nokkel.pem -noout -text | grep "Private-Key"
# Sjekk nøkkelstørrelsen til et lokalt sertifikat
openssl x509 -in sertifikat.pem -noout -text | grep "Public-Key"
# Sjekk nøkkelstørrelsen til et sertifikat på en live server
echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -text | grep "Public-Key"Kjør denne kartleggingen mot alle produksjonsdomener og interne tjenester før du bestemmer deg for en migreringsplan. Det er ikke uvanlig å oppdage at enkelte eldre systemer fortsatt kjører RSA-1024 eller enda eldre nøkler som burde vært pensjonert for lenge siden, og disse bør prioriteres foran en eventuell oppgradering fra 2048 til 4096 bit.
Vanlige feil ved migrering mellom RSA-nøkkelstørrelser
Flere team som har migrert mellom RSA-2048 og RSA-4096 rapporterer de samme fallgruvene. Den første er å bytte nøkkelstørrelse på en høytrafikkstjeneste uten først å måle den faktiske CPU-belastningen i et representativt testmiljø. Siden signeringskostnaden kan øke mellom 6 og 11 ganger, kan en umålt migrering i verste fall utløse autoskalering langt utover budsjettert kapasitet eller i verste fall timeout-feil under lastopptak.
Den andre fallgruven er å glemme at TLS-biblioteker på klientsiden kan ha øvre grenser for nøkkelstørrelse. Enkelte eldre mobilapplikasjoner, IoT-enheter og innebygde systemer med begrenset TLS-stack-støtte kan feile eller time ut mot et sertifikat med for stor nøkkel, spesielt hvis den kombineres med en lang sertifikatkjede. Test derfor migreringen mot den eldste klienten du fortsatt må støtte, ikke bare mot moderne nettlesere.
Den tredje fallgruven er kostnadsblindhet i skymiljøer. Som prisoversikten tidligere i artikkelen viser, kan en tilsynelatende uskyldig endring fra RSA-2048 til RSA-4096 i AWS KMS eller Azure Key Vault femdoble transaksjonskostnaden uten at noen oppdager det før neste fakturasyklus. Sett opp kostnadsvarsling for KMS-tjenesten før migreringen, ikke etter.
Den fjerde og siste vanlige feilen er å migrere rot-CA-nøkkelen og sluttbrukersertifikatene samtidig. Bygg i stedet inn en overlappende periode der den gamle og den nye rot-CA-en er gyldig parallelt, slik at eksisterende klienter som har den gamle rot-CA-en i sin tillitslager fortsatt kan validere sertifikatkjeden mens du gradvis ruller ut den nye.
Fordeler og ulemper med RSA-2048
RSA-2048 har klare fordeler: rask signering og verifisering, lavere CPU- og minnebruk, universell støtte i alle nettlesere, operativsystemer og biblioteker, samt lavere transaksjonskostnad i skybaserte KMS-tjenester. Det er fortsatt vurdert som sikkert nok for de fleste bruksområder frem til 2030 ifølge NIST. Ulempene er at det ikke lenger møter minimumskravene i NSA CNSA 2.0, BSI TR-02102-1 eller de kommende CA/Browser Forum-kravene for S/MIME rot-CA-er, og at sikkerhetsmarginen mot fremtidige klassiske og kvantebaserte angrep er mindre enn ved RSA-4096.
Fordeler og ulemper med RSA-4096
RSA-4096 gir en reell, om enn begrenset, økning i sikkerhetsstyrke og møter kravene som stadig flere myndigheter og standardorganer stiller til nye systemer. Det er også et fremtidsrettet valg for nøkler som skal leve lenge, som rot-CA-er og PGP-signeringsnøkler. Ulempene er betydelige: mellom 6 og 11 ganger tregere signering ifølge de tre benchmarkene i denne artikkelen, opptil 52 prosent lengre TLS-håndtrykk, og i AWS KMS og Azure Key Vault en femdobling av transaksjonskostnaden sammenlignet med RSA-2048. For høytrafikkstjenester kan denne kombinasjonen kreve vesentlig mer serverkapasitet uten en tilsvarende stor sikkerhetsgevinst.
Er RSA i det hele tatt fremtidssikkert?
Uansett om man velger RSA-2048 eller RSA-4096, gjenstår et større spørsmål: er RSA som algoritmefamilie i det hele tatt et godt langsiktig valg? Gidneys 2025-forskning viser at RSA-2048 teoretisk kan faktoriseres av en fremtidig, tilstrekkelig stor kvantedatamaskin med under én million fysiske qubits. Å doble nøkkelstørrelsen til 4096 bit utsetter dette problemet noe, men løser det ikke, siden Shors algoritme i prinsippet knekker RSA uavhengig av nøkkelstørrelse, gitt en tilstrekkelig kraftig kvantedatamaskin.
Det er derfor NIST, NSA og europeiske myndigheter som BSI nå dytter i to retninger samtidig: øk minimum RSA-nøkkelstørrelse for kortsiktig sikkerhetsmargin, og migrer parallelt til postkvante-algoritmer som ML-KEM for nøkkelutveksling og ML-DSA for signaturer for langsiktig sikkerhet. For team som allerede planlegger en større kryptografisk oppgradering, kan det være mer fornuftig å investere ressursene i en hybrid ML-KEM/RSA- eller ML-DSA/ECDSA-løsning enn i en ren RSA-2048-til-4096-oppgradering som uansett har begrenset holdbarhet på lang sikt.
Konklusjon: verdikt basert på tallene
Tallene i denne sammenligningen peker mot en klar, men nyansert konklusjon. For generell webtrafikk, offentlige TLS-servere og KMS-tjenester med høyt transaksjonsvolum er RSA-2048 fortsatt det mest fornuftige valget i 2026: det er 6 til 11 ganger raskere å signere med, opptil 52 prosent raskere i TLS-håndtrykk, og betydelig billigere i AWS KMS og Azure Key Vault, samtidig som NIST anser det som sikkert frem til 2030.
For rot-CA-er, PGP-signeringsnøkler, kodesignering og andre lavvolums, høyverdi-nøkler bør RSA-4096 være standardvalget i 2026, både fordi regelverket fra CA/Browser Forum og BSI beveger seg i den retningen, og fordi CPU-kostnaden ved sjelden signering er neglisjerbar. Den virkelige langsiktige løsningen er uansett verken RSA-2048 eller RSA-4096 alene, men en gradvis overgang til postkvante-kryptografi for systemer som må beskytte data utover 2030-tallet.
Hvis du er usikker på hvor du skal starte, bruk denne enkle tommelfingerregelen: tell hvor mange ganger nøkkelen faktisk signerer eller dekrypterer per dag. Ligger tallet i tusenvis eller millioner, er RSA-2048 (eller enda heller en elliptisk kurve) riktig verktøy. Ligger tallet i titalls eller hundretalls signeringer, som for en rot-CA eller en personlig PGP-nøkkel, er RSA-4096 en billig forsikring mot fremtidige krav. Og uansett hvilken størrelse du velger i dag, sett av tid i sikkerhetsplanen for å evaluere ML-KEM og ML-DSA før 2030, siden ingen RSA-størrelse løser kvanteproblemet alene.
Vanlige spørsmål om RSA-2048 vs RSA-4096
Er RSA-2048 fortsatt trygt å bruke i 2026?
Ja, ifølge NIST SP 800-57 er RSA-2048 (112-bit sikkerhetsstyrke) ansett som tilstrekkelig for generell bruk til og med 31. desember 2030. For nye høysikkerhetssystemer anbefaler imidlertid NSA CNSA 2.0 og BSI allerede nå minst 3072-bit nøkler.
Hvor mye tregere er RSA-4096 enn RSA-2048?
Basert på tre uavhengige OpenSSL-benchmarker er signering mellom 6 og 11 ganger tregere med RSA-4096, mens verifisering er mellom 3,3 og 3,7 ganger tregere. TLS-håndtrykk kan bli opptil 52 prosent lengre.
Koster RSA-4096 mer i skytjenester enn RSA-2048?
Ja, i AWS KMS og Azure Key Vault koster RSA-4096-operasjoner fem ganger så mye per 10 000 forespørsler som RSA-2048. Google Cloud KMS har lik operasjonspris i programvaremodus, men høyere pris for RSA-4096 i Cloud HSM.
Hvilken nøkkelstørrelse bruker Let’s Encrypt som standard?
Standardklienten Certbot genererer 2048-bit RSA-nøkler med mindre brukeren eksplisitt ber om 3072 eller 4096 bit med flagget –rsa-key-size.
Krever CA/Browser Forum RSA-4096 for alle sertifikater i 2026?
Nei, kravet gjelder foreløpig kun rot- og mellomliggende CA-nøkler for S/MIME fra 15. september 2026. Sluttbrukersertifikater kan fortsatt bruke RSA-2048 som minimum, men underliggende CA-er med nøkler under 3072 bit mister utstedelsesrett fra 15. september 2027.
Kan en kvantedatamaskin knekke RSA-4096 lettere enn RSA-2048?
Nei, det motsatte. RSA-4096 krever flere qubits og lengre kjøretid å faktorisere enn RSA-2048 med Shors algoritme. Craig Gidneys 2025-forskning viser at RSA-2048 kan faktoriseres med under én million fysiske qubits, mens RSA-4096 krever vesentlig mer ressurser, om enn ikke presist tallfestet i samme studie.
Bør jeg bytte fra RSA til ECDSA eller Ed25519 i stedet for å oppgradere til RSA-4096?
For mange nye systemer er elliptiske kurver som Ed25519 eller ECDSA P-256 et bedre alternativ, siden de gir tilsvarende eller bedre sikkerhet med langt mindre nøkler og raskere operasjoner enn både RSA-2048 og RSA-4096. Valget avhenger av kompatibilitetskrav med eldre systemer som kun støtter RSA.
Hva bruker DNSSEC-rotsonen av nøkkelstørrelse?
ICANNs rotsone signeres i dag med RSA/SHA-256 og 2048-bit nøkler for både KSK og ZSK. Et forslag fra mai 2026 vurderer overgang til ECDSA P-256, men dette er foreløpig ikke gjennomført i drift.
Er RSA-3072 et bedre valg enn både RSA-2048 og RSA-4096?
For mange systemer, ja. RSA-3072 møter minimumskravene i NSA CNSA 2.0 og BSI TR-02102-1, gir rundt 128-bit sikkerhetsstyrke, og har lavere ytelseskostnad enn RSA-4096. Ulempen er noe mindre utbredt testing og biblioteksstøtte sammenlignet med de to mer vanlige nøkkelstørrelsene.
