Welcher Schlüsseltyp ist sinnvoll: RSA oder ECC?

Für neue Zertifikate ist ECC (Elliptic Curve Cryptography) heute die bessere Wahl: kürzere Schlüssel, schnellere TLS-Handshakes, geringere CPU-Last bei vergleichbarer oder höherer Sicherheit. RSA bleibt sinnvoll, wenn ältere Clients oder Geräte unterstützt werden müssen, die kein ECC verstehen.

Beide Verfahren sind in den Trust-Stores aller großen Browser und Betriebssysteme verankert und lassen sich von jeder öffentlichen CA ausstellen. Der Unterschied liegt in der Mathematik dahinter und damit in Performance, Schlüssellängen und Kompatibilität.

Sicherheit und Schlüssellängen im Vergleich (NIST SP 800-57):

Sicherheitsniveau	RSA-Schlüssellänge	ECC-Kurve	Vergleichbar mit symmetrisch
112 Bit	2048 Bit	P-224	3DES
128 Bit	3072 Bit	P-256	AES-128
192 Bit	7680 Bit	P-384	AES-192
256 Bit	15360 Bit	P-521	AES-256

Ein ECC-Schlüssel mit 256 Bit bietet also dieselbe kryptografische Stärke wie ein RSA-Schlüssel mit 3072 Bit — bei einem Bruchteil der Größe und Rechenleistung.

Was das in der Praxis bedeutet:

Eigenschaft	RSA 2048	ECC P-256
Schlüssellänge	2048 Bit	256 Bit
Zertifikatsgröße	größer	kleiner — schneller über die Leitung
Handshake-Geschwindigkeit	Standard	typisch 3- bis 10-mal schneller
CPU-Last beim Server	höher, vor allem bei vielen parallelen Verbindungen	deutlich niedriger
Mobilgeräte und IoT	akkulastiger	energiesparender
Kompatibilität	nahezu universell, auch alte Geräte	alle modernen Browser und OS, ältere Embedded-Systeme teils nicht
Quantencomputer-Risiko	durch Shor-Algorithmus angreifbar	durch Shor-Algorithmus angreifbar — keine Lösung, beide brauchen Post-Quantum-Migration

Empfohlene Schlüsselparameter für neue Zertifikate:

• RSA: mindestens 2048 Bit, besser 3072 Bit. RSA 4096 nur, wenn die Last keine Rolle spielt — der Sicherheitsgewinn gegenüber 3072 Bit ist gering, der Performance-Verlust spürbar.
• ECC: P-256 (auch secp256r1 oder prime256v1) ist der heutige Standard. P-384 für höhere Sicherheitsanforderungen, etwa im Finanz- oder Behördenumfeld.

Wann welche Wahl ergibt Sinn:

• Standard-Webserver, Onlineshops, APIs: ECC P-256. Schnellere Handshakes verbessern Time-to-First-Byte messbar.
• Hochlast-Setups, Load Balancer, CDN-Origins: ECC P-256 — die geringere CPU-Last spart Hardware.
• Setups mit alten Clients: RSA 2048 oder Hybrid-Ansatz mit zwei Zertifikaten (ECC + RSA), die der Server je nach Client ausliefert.
• Embedded-Geräte, ältere Industriesteuerungen, alte Java-Versionen: RSA 2048 — ECC-Unterstützung erst ab Java 7, einigen Embedded-Stacks fehlt sie ganz.
• Compliance-Vorgaben: BSI TR-02102 und FIPS 140-3 erlauben beide Verfahren — die Wahl richtet sich nach internen Vorgaben.

Beispiel für die Erzeugung eines ECC-Schlüssels und CSR mit OpenSSL:

openssl ecparam -name prime256v1 -genkey -noout -out meine-domain.key
openssl req -new -key meine-domain.key -out meine-domain.csr

Ein Ausblick zur Quantenkryptografie: Sowohl RSA als auch ECC sind langfristig durch hinreichend leistungsfähige Quantencomputer angreifbar. Die Migration läuft über die Post-Quantum-Standards der NIST (ML-KEM, ML-DSA, SLH-DSA, finalisiert 2024). Erste hybride Zertifikate werden ab 2026/2027 erwartet — bis dahin bleibt ECC die solide Standardwahl.