Welcher Schlüsseltyp ist sinnvoll: RSA oder ECC?

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.

CSR & Einrichtung

Weitere Fragen und Antworten »