Kort svar
ECDSA-nøgler er meget mindre og hurtigere end RSA ved samme sikkerhedsniveau: en 256-bit ECDSA-nøgle svarer groft til en 3072-bit RSA-nøgle. ECDSA giver hurtigere handshakes og lavere CPU-belastning, især under stor last. RSA vinder kun på ét punkt: kompatibilitet med meget gamle klienter. For de fleste offentlige servere er det bedste svar at servere begge og lade hver klient vælge.
Direkte sammenligning
| RSA 2048 | ECDSA P-256 | |
|---|---|---|
| Sikkerhedsniveau | ~112-bit | ~128-bit |
| Privat nøgle, størrelse | Stor | Lille |
| Handshake-CPU (server) | Højere | Lavere |
| Signaturverifikation (klient) | Hurtig | Lidt langsommere |
| Kompatibilitet, gamle klienter | Bredest | Meget bred, men ikke total |
| Bedst til | Maksimal bagudkompatibilitet | Ydeevne, ny infrastruktur |
Bemærk at tabellen sammenligner P-256 med RSA-2048 (den mest udbredte RSA-størrelse) — ikke med sin egen ækvivalent. P-256 svarer sikkerhedsmæssigt til RSA-3072, så ECDSA-kolonnens ~128-bit ligger over RSA-2048's ~112-bit.
Bemærk asymmetrien: RSA er hurtigere at verificere men langsommere at signere, mens ECDSA er hurtigere at signere men en smule langsommere at verificere. Da serveren signerer per handshake, vinder ECDSA på serverens CPU-belastning — som regel det der betyder noget under last.
Generér en af hver
# RSA 2048-bit openssl req -new -newkey rsa:2048 -nodes \ -keyout rsa.key -out rsa.csr -subj "/CN=example.com" # ECDSA på P-256-kurven (prime256v1) openssl ecparam -name prime256v1 -genkey -noout -out ec.key openssl req -new -key ec.key -out ec.csr -subj "/CN=example.com"
Bemærk at prime256v1, secp256r1 og P-256 er tre navne for præcis samme kurve. P-256 og P-384 er de eneste kurver der reelt understøttes bredt i TLS.
Hvad har certifikatet?
openssl x509 -in cert.pem -noout -text | grep -A2 "Public Key Algorithm"
For RSA ser du rsaEncryption og en nøglestørrelse i bit. For ECDSA ser du id-ecPublicKey og en kurve som prime256v1. Nøgletypen bestemmer Au=-delen i de cipher suites serveren kan bruge — se hvad en cipher suite er.
Det rigtige svar: server begge (dual-cert)
Moderne servere kan have både et ECDSA- og et RSA-certifikat installeret samtidigt. Serveren præsenterer ECDSA for klienter der understøtter det (langt de fleste i dag) og falder tilbage til RSA for de gamle. Du får ECDSA's ydeevne uden at miste kompatibilitet:
# nginx — to certifikater på samme server ssl_certificate /etc/ssl/example.com/ecdsa-fullchain.pem; ssl_certificate_key /etc/ssl/example.com/ecdsa.key; ssl_certificate /etc/ssl/example.com/rsa-fullchain.pem; ssl_certificate_key /etc/ssl/example.com/rsa.key;
Hvorfor ECDSA-nøgler er så meget mindre
Forskellen kommer fra de underliggende matematiske problemer. RSA's sikkerhed hviler på at det er svært at faktorisere store tal, og det problem bliver kun langsomt sværere efterhånden som tallene vokser — derfor skal RSA-nøgler være store (2048, 3072, 4096 bit) for at modstå moderne angreb. ECDSA hviler på det diskrete logaritmeproblem på elliptiske kurver, som er meget sværere per bit. Resultatet: en 256-bit ECDSA-nøgle giver samme sikkerhed som en 3072-bit RSA-nøgle. Det er ikke kun en filstørrelse-detalje — mindre nøgler betyder mindre data i hvert handshake, hurtigere signering og lavere hukommelsesforbrug, hvilket især tæller på mobile klienter og under høj forbindelsesrate.
Praktiske overvejelser ved migration
Skal du migrere fra RSA til ECDSA, så gør det additivt, ikke som en hård udskiftning. Tilføj et ECDSA-certifikat ved siden af det eksisterende RSA-certifikat (dual-cert ovenfor), verificér at klienterne forhandler ECDSA, og behold RSA som fallback indtil du er sikker på at ingen kritiske klienter falder ud. Husk at hele kæden skal matche nøgletypen: et ECDSA-leaf skal kædes med en ECDSA-intermediate fra CA'en. Bland aldrig leaf og intermediate på tværs af nøgletyper — det giver en kæde der ikke kan bygges færdig.
Hvad med sikkerheden?
Begge er sikre når de bruges rigtigt. Det reelle kryptografiske niveau ved RSA-2048 (~112-bit) er lavere end ved ECDSA P-256 (~128-bit), men begge ligger langt over det der praktisk kan brydes i dag. RSA's største praktiske risiko er at folk bruger 1024-bit nøgler (forældede) eller dårlig tilfældighed ved nøglegenerering; ECDSA's er en svag tilfældighedskilde ved signering. Med ordentlige biblioteker er ingen af delene et problem.
Sådan ser CertControl det på tværs af jeres flåde
I praksis ender organisationer med en blanding: nye servere på ECDSA, ældre på RSA-2048, og enkelte glemte på RSA-1024. CertControl registrerer nøgletype og nøglestørrelse på hvert certifikat den finder, og rejser en finding på de svage eller forældede — så I kan migrere systematisk i stedet for at opdage en RSA-1024-nøgle i en revision. Læs mere om hvad et certifikat indeholder i hvad er et TLS-certifikat.
Ofte stillede spørgsmål
Er ECDSA mere sikkert end RSA?
Ved sammenlignelige nøglestørrelser giver ECDSA et højere sikkerhedsniveau per bit — P-256 svarer til RSA-3072. Men begge er sikre i praksis ved anbefalede størrelser. Forskellen handler mest om ydeevne og nøglestørrelse, ikke om reel brudrisiko.
Hvilken er hurtigst?
ECDSA giver lavere CPU-belastning på serveren per handshake, fordi signering er billigere. Det betyder mest ved høj last. RSA verificerer en smule hurtigere på klienten, men det er sjældent flaskehalsen.
Kan jeg bruge både RSA og ECDSA på samme domæne?
Ja, og det er ofte det bedste. Med en dual-cert opsætning serverer du begge, og hver klient forhandler den nøgletype den understøtter — ECDSA for de fleste, RSA som fallback.
Hvilken ECDSA-kurve skal jeg vælge?
P-256 (prime256v1) til langt de fleste; P-384 hvis et compliance-krav forlanger et højere niveau. Andre kurver understøttes ikke bredt nok i TLS til offentlig brug.
Bør jeg stadig bruge RSA-2048 eller gå til 3072/4096?
RSA-2048 er fortsat acceptabel for de fleste formål. 3072 giver en større margin på bekostning af ydeevne; 4096 er sjældent nødvendigt og mærkbart langsommere. Vil du have et højere niveau, er ECDSA P-256 ofte et bedre valg end stor RSA.