Elliptische Kurvenkryptografie (ECC) verstehen

Elliptische-Kurven-Kryptographie (ECC) ist eine Form der Public-Key-Kryptographie, die auf der algebraischen Struktur elliptischer Kurven über endlichen Körpern basiert. Sie erreicht dieselben Sicherheitsziele wie RSA , einschließlich Schlüsselaustausch, digitaler Signaturen und Authentifizierung, jedoch mit deutlich kleineren Schlüssellängen, schnelleren Operationen und geringerem Ressourcenverbrauch. Ein 256-Bit-ECC-Schlüssel bietet annähernd dieselbe Sicherheit wie ein 3072-Bit-RSA-Schlüssel. Empfohlene Vorgehensweise: Verwenden Sie ECDSA P-256 oder Ed25519 für neue digitale Signaturen und TLS-Zertifikate, ECDHE für den Schlüsselaustausch in TLS 1.3 und beginnen Sie mit der Planung der Migration zu Post-Quantum-Verfahren (ML-KEM, ML-DSA) für langlebige Infrastrukturen, für die die Abschaffungsfrist 2030 gilt.

Kurzantwort: Was ist ECC und wann sollte man es einsetzen?

ECC ist der bevorzugte asymmetrische kryptografische Algorithmus für die meisten neuen Implementierungen: TLS-Zertifikate, Codesignierung, SSH-Schlüssel und mobile/IoT-Authentifizierung. Seine Sicherheit basiert auf dem Elliptic Curve Discrete Logarithm Problem (ECDLP), für das es auf einer geeignet gewählten Kurve keine bekannte subexponentielle Lösung gibt. Vorteil der Schlüssellänge: ECDSA P-256 bietet 128-Bit-Sicherheit mit einem 32-Byte-Schlüssel; RSA benötigt für vergleichbare Sicherheit einen 3072-Bit-Schlüssel (384 Byte). Verwenden Sie ECC für neue Zertifikate, SSH-Schlüssel und Codesignierung. Nutzen Sie RSA nur dort, wo ECC von älteren Systemen nicht unterstützt wird. Hinweis: ECC ist nicht quantensicher; Shors Algorithmus bricht das ECDLP. Planen Sie die Migration zu NIST-standardisierten Post-Quanten-Algorithmen für Infrastrukturen mit mehrjährigen Schlüssellebensdauern.

Was ist elliptische Kurvenkryptographie (ECC)?

ECC ist eine Form der Public-Key-Kryptographie, bei der zwei mathematisch zusammenhängende Schlüssel verwendet werden: ein öffentlicher Schlüssel (der öffentliche Schlüssel) und ein privater Schlüssel (der private Schlüssel). Das Besondere an ECC ist die Verwendung elliptischer Kurven: mathematische Strukturen, die über endlichen Körpern durch eine Gleichung der Form y² = x³ + ax + b definiert sind . Mathematiker erforschten diese Kurven jahrhundertelang, doch 1985 entdeckten Neal Koblitz und Victor S. Miller unabhängig voneinander ihre Anwendung in der Kryptographie. Dies ermöglichte hohe Sicherheit mit deutlich kleineren Schlüsseln als frühere Verfahren wie RSA.

Die Sicherheit von ECC beruht auf dem Problem des diskreten Logarithmus auf elliptischen Kurven (ECDLP) : Gegeben ein Basispunkt G auf der Kurve und ein resultierender Punkt P, berechnet als P = kG (durch Skalarmultiplikation, bei der G gemäß den Kurvenregeln k-mal zu sich selbst addiert wird), ist es rechnerisch unmöglich, k allein aus G und P zu bestimmen. Es ist kein Algorithmus bekannt, der das ECDLP auf einer geeignet gewählten Kurve wesentlich schneller löst als eine Brute-Force-Methode. Daher bieten kleine ECC-Schlüssel eine hohe Sicherheit.

Wie der ECDH-Schlüsselaustausch funktioniert

ECDH (Elliptic Curve Diffie-Hellman) ist das auf ECC basierende Schlüsselaustauschprotokoll. Es ermöglicht zwei Parteien, ein gemeinsames Geheimnis über einen unsicheren Kanal zu vereinbaren, ohne das Geheimnis selbst zu übertragen. Hier ist die Funktionsweise am Beispiel von Alice und Bob:

Alice und Bob einigen sich öffentlich auf eine bestimmte elliptische Kurve und einen Startpunkt G auf dieser Kurve. Alice wählt eine geheime Zahl a (ihren privaten Schlüssel) und berechnet ihren öffentlichen Schlüssel A = aG (Skalarmultiplikation von G mit a). Bob wählt eine geheime Zahl b (seinen privaten Schlüssel) und berechnet seinen öffentlichen Schlüssel B = bG. Beide tauschen ihre öffentlichen Schlüssel A und B öffentlich aus.

Alice berechnet das gemeinsame Geheimnis: aB = a(bG) = abG. Bob berechnet dasselbe gemeinsame Geheimnis: bA = b(aG) = abG. Beide gelangen zum identischen Punkt abG auf der Kurve, der das gemeinsame Geheimnis darstellt. Ein Angreifer, der G, A und B beobachtet, kann das gemeinsame Geheimnis abG nicht berechnen, ohne das ECDLP zu lösen, d. h. entweder a aus G und A oder b aus G und B zu bestimmen, was rechnerisch unmöglich ist.

In der Praxis erzeugt ECDHE (Ephemeral ECDH) für jede Sitzung ein neues Schlüsselpaar und verwirft anschließend die temporären privaten Schlüssel. Dies gewährleistet Vorwärtsgeheimhaltung : Selbst wenn langfristige Schlüssel später kompromittiert werden, können vergangene Sitzungen nicht entschlüsselt werden, da die temporären Sitzungsschlüssel nicht mehr vorhanden sind. TLS 1.3 schreibt ECDHE für alle Schlüsselaustausche vor, wodurch Vorwärtsgeheimhaltung obligatorisch wird. In unserem Leitfaden zu TLS 1.2 und TLS 1.3 erfahren Sie , wie dies in der Praxis umgesetzt wird.

ECC vs. RSA

RSA und ECC erreichen beide Ziele der Public-Key-Kryptographie, jedoch auf unterschiedlichen mathematischen Grundlagen. RSA basiert auf der Schwierigkeit der Faktorisierung großer ganzer Zahlen; ECC auf dem ECDLP-Prinzip. Die praktischen Unterschiede sind erheblich.

Funktion	RSA	ECC
Sicherheit basiert auf	Ganzzahlfaktorisierung	Diskreter Logarithmusproblem mit elliptischen Kurven (ECDLP)
Schlüssellänge für 128-Bit-Sicherheit	3072 Bits	256 Bit (ECDSA P-256)
Schlüssellänge für 192-Bit-Sicherheit	7680 Bits	384 Bit (ECDSA P-384)
Leistung bei der Unterzeichnung	Langsam (große modulare Exponentiation)	Schnell
Überprüfungsleistung	Schnell	Schnell
Auswirkungen der Zertifikatsgröße	Groß (RSA-3072-Zertifikat, ca. 384 Bytes für den öffentlichen Schlüssel)	Klein (ECDSA P-256-Zertifikat, ca. 32 Bytes für den öffentlichen Schlüssel)
Am besten geeignet für	Legacy-Systeme, die RSA-Kompatibilität erfordern	Neue Einsatzmöglichkeiten: TLS, SSH, Codesignierung, IoT, Mobilgeräte
Quantensicherheit	Nicht quantensicher (Shors Algorithmus bricht RSA)	Nicht quantensicher (Shors Algorithmus verletzt das ECDLP)

Vergleich der Sicherheitsstärken verschiedener Algorithmenfamilien

NIST SP 800-57 Teil 1 Rev. 5 definiert gleichwertige Sicherheitsniveaus für symmetrische, ECC- und RSA-Algorithmen. Dies ermöglicht es Sicherheitsarchitekten, Algorithmen auszuwählen, die gleichwertigen Schutz bieten, ohne übermäßigen Rechenaufwand zu verursachen.

Sicherheitsstärke (Bits)	Symmetrische Schlüsselgröße	ECC-Schlüsselgröße	RSA-Schlüsselgröße
128	AES-128	256-283 Bit (P-256)	3072 Bits
192	AES-192	384-511 Bit (P-384)	7680 Bits
256	AES-256	512+ Bit (P-521)	15360 Bits

ECC erreicht dieselbe Sicherheit wie RSA mit deutlich kleineren Schlüsseln. Für das gängigste Anwendungsziel mit 128-Bit-Verschlüsselung gilt: ECDSA P-256 (32 Byte öffentlicher Schlüssel) im Vergleich zu RSA-3072 (384 Byte öffentlicher Schlüssel). Dieser Größenunterschied ist für die Größe von TLS-Zertifikaten, die Größe von DNSSEC-Antworten und ressourcenbeschränkte Geräte von erheblicher Bedeutung. Der Vorteil von ECC zeigt sich besonders in Umgebungen mit begrenzter Bandbreite, Speicherkapazität oder Rechenleistung: mobile Anwendungen, IoT-Geräte , Smartcards und eingebettete Systeme.

Leitfaden zur Auswahl des ECC-Algorithmus und der Kurve

Anwendungsfall	Empfohlener ECC-Algorithmus/Kurve	Warum	Vermeiden
TLS-Zertifikate (Neuinstallationen)	ECDSA P-256	128-Bit-Sicherheit; weit verbreitete Unterstützung; kleinere Zertifikate reduzieren die Größe des TLS-Handshakes; empfohlen gemäß NIST SP 800-52 Rev. 2.	RSA-2048 (vorgeschlagen, nach 2030 gemäß NIST IR 8547 als veraltet zu gelten)
TLS-Schlüsselaustausch (Sitzungsschlüssel)	ECDHE X25519 oder P-256	Der Austausch ephemerer Schlüssel gewährleistet Vorwärtsgeheimhaltung; TLS 1.3 erfordert ECDHE für alle Verbindungen	RSA-Schlüsselaustausch (keine Vorwärtsgeheimhaltung; aus TLS 1.3 entfernt)
SSH-Schlüssel	Ed25519	Edwards-Kurven-DSA; 128-Bit-Sicherheit; 32-Byte-öffentlicher Schlüssel; schnell; resistent gegen Timing-Seitenkanalangriffe; unterstützt von OpenSSH 6.5+	DSA (veraltet); RSA-1024 (unsicher); ECDSA P-256 (akzeptable Alternative, falls Ed25519 nicht verfügbar)
Codesignatur	ECDSA P-256 oder P-384	Kleinere Signaturen als RSA bei gleichwertiger Sicherheit; schnellere Signierung; wichtig für Signierungspipelines mit hohem Durchsatz	RSA-1024 (unsicher); SHA-1 als Hash (fehlerhaft)
DNSSEC-Zonensignatur	ECDSA P-256	Kleinere Signaturen passen leichter zu DNS-UDP-Antworten; reduzierte Zonengröße	RSA-1024 (unsicher); RSA-2048 (deutlich größere Signaturen)
Mobile und IoT-Authentifizierung	ECDSA P-256 oder Ed25519	Geringere Anforderungen an Rechenleistung, Energie und Bandbreite im Vergleich zu RSA bei gleichwertiger Sicherheit	RSA-3072+ (höherer Rechenaufwand auf leistungsschwacher Hardware)
Postquantenmigration (Schlüsselaustausch)	ML-KEM (FIPS 203)	NIST-standardisierter PQC-Ersatz für ECDH; resistent gegen Shors Algorithmus	ECDH allein für neue, langlebige Infrastruktur

Vor- und Nachteile von ECC

Vorteile von ECC

• Kleinere Schlüssellänge bei gleichwertiger Sicherheit: ECC erreicht 128-Bit-Sicherheit mit einem 256-Bit-Schlüssel im Vergleich zu 3072 Bit bei RSA. Kleinere Schlüssel reduzieren den Speicherbedarf, die Bandbreite für die Zertifikatsübertragung und die Rechenzeit.
• Solide mathematische Grundlagen: Es ist kein subexponentieller Angriff gegen ECDLP auf gut gewählten Kurven bekannt. Dies gewährleistet robuste Sicherheit, ohne auf algorithmischer Unklarheit zu beruhen.
• Vorwärtsgeheimhaltung über ECDHE: ECDHE ermöglicht den Austausch von temporären Schlüsseln und bietet Vorwärtsgeheimhaltung, sodass die Kompromittierung langfristiger Schlüssel vergangene Sitzungen nicht offenlegt.
• Leistung auf leistungsschwacher Hardware: Kleinere Schlüssellängen reduzieren direkt den Rechenaufwand für kryptografische Operationen, wodurch ECC die praktische Wahl für mobile Geräte, IoT-Sensoren und Smartcards darstellt.

Nachteile von ECC

• Die Wahl der Kurve ist entscheidend: Die Sicherheit von ECC hängt maßgeblich von der Wahl mathematisch fundierter Kurvenparameter ab. Ungeeignete oder schlecht gewählte Kurven können Schwachstellen verursachen, die die Sicherheitsgarantien untergraben. Verwenden Sie ausschließlich NIST-standardisierte Kurven (P-256, P-384, P-521) oder allgemein anerkannte Alternativen (X25519, Ed25519).
• Nicht quantensicher: Shors Algorithmus auf einem Quantencomputer bricht das ECDLP. ECC muss für eine langlebige Infrastruktur auf Post-Quanten-Algorithmen (ML-KEM, ML-DSA) migriert werden.
• Kompatibilitätslücken mit älteren Systemen: Ältere Systeme, eingebettete Geräte und einige Middleware-Lösungen für Unternehmen unterstützen ECC möglicherweise nicht. Die RSA-Kompatibilität ist für bestehende Brownfield-Umgebungen umfassender.
• Komplexität der Implementierung: ECC-Implementierungen müssen Grenzfälle der Kurvenarithmetik (Punkt-im-Unendlichen, ungültige öffentliche Schlüsselvalidierung) sorgfältig behandeln, um Seitenkanalangriffe zu vermeiden. Verwenden Sie bewährte kryptografische Bibliotheken anstelle von Eigenentwicklungen.

Anwendungen der Elliptischen Kurvenkryptographie

1. Digitale Signaturen und Codesignierung: ECDSA signiert Dokumente, Software-Releases und Firmware-Updates, um deren Authentizität zu überprüfen und Manipulationen zu erkennen. Kleinere Signaturen und schnellere Signierung machen es für Codesignierungs-Pipelines mit hohem Durchsatz gegenüber RSA vorzuziehen.
2. Sicherung von Webverbindungen (HTTPS/TLS): ECDSA P-256 TLS-Zertifikate authentifizieren Server. ECDHE ermöglicht den Austausch des Vorwärtsgeheimnisses während des TLS-Handshakes. Kleinere ECC-Zertifikate verkürzen die Verbindungsaufbauzeit, was insbesondere bei mobilen Verbindungen und Verbindungen mit geringer Bandbreite von Vorteil ist.
3. SSH-Schlüsselauthentifizierung: Ed25519 ist der aktuell bevorzugte Algorithmus für SSH-Schlüssel. Er bietet kompakte 32-Byte-Schlüssel, schnelle Operationen und Schutz vor Timing-Seitenkanalangriffen. Siehe unseren Beitrag zu diesem Thema. SSH-Schlüsselverwaltung zur Bereitstellungsanleitung.
4. Kryptowährungen und Blockchain: ECDSA (hauptsächlich secp256k1 für Bitcoin und Ethereum) sichert Wallet-Schlüsselpaare und Transaktionssignaturen. Die kompakte Schlüssellänge ist besonders wichtig für die Speichereffizienz der Blockchain.
5. Sicherheit von IoT-Geräten: Die kleinen Schlüsselgrößen und der geringe Rechenaufwand von ECC machen es zur praktischen Wahl für IoT-Sensoren, intelligente Zähler und eingebettete Systeme mit begrenzter Rechenleistung und Batterielebensdauer.
6. Schlüsselaustausch für verschlüsselte Kommunikation: ECDH und ECDHE werden in Messaging-Anwendungen (das Signal-Protokoll verwendet X25519), E-Mail-Verschlüsselung und VPN-Protokollen verwendet, um gemeinsame Sitzungsschlüssel zu etablieren, ohne Geheimnisse zu übertragen.

Einsatzbeispiel: ECC in einer Produktionsumgebung für TLS und Codesignatur

Ein Softwareunternehmen setzt ECC in seiner gesamten TLS-Zertifikatsinfrastruktur und Codesignierungspipeline ein:

1. Migration von TLS-Zertifikaten: Die bestehenden RSA-2048-TLS-Zertifikate auf öffentlich zugänglichen Webservern werden durch ECDSA-P-256-Zertifikate ersetzt. Die Zertifikatsgröße verringert sich von ca. 1,200 Byte auf 400 Byte, wodurch die Anzahl der ausgetauschten TLS-Handshake-Bytes reduziert und die Verbindungsaufbauzeit in Mobilfunknetzen verbessert wird.
2. TLS-Serverkonfiguration: Die Server sind für die Unterstützung von TLS 1.3 mit ECDHE X25519 als bevorzugtem Schlüsselaustausch konfiguriert. Forward Secrecy ist nun für alle Verbindungen obligatorisch; vergangene Sitzungen können nicht entschlüsselt werden, selbst wenn der private ECDSA-Schlüssel später kompromittiert wird.
3. Codesignierungspipeline: CodeSign Secure Alle Software-Releases werden mit ECDSA P-256 signiert. Die Signaturschlüssel werden in einem FIPS 140-3-validierten Speicher abgelegt. HSMsDadurch wird sichergestellt, dass der private Schlüssel niemals in den Anwendungsspeicher gelangt. Die ECDSA-Signaturgröße beträgt etwa 64 Byte, im Vergleich zu 384 Byte bei RSA-3072, wodurch der Aufwand für signierte Artefakte reduziert wird.
4. Interne Dienstauthentifizierung: Die Kommunikation zwischen Diensten erfolgt über Mutual TLS (mTLS) mit ECDSA P-256-Zertifikaten, die von einer internen Zertifizierungsstelle ausgestellt werden. Die Zertifikatsgültigkeitsdauer beträgt nur 90 Tage und wird von einer internen Zertifizierungsstelle verwaltet. CertSecure Manager) das Zeitfenster für die Offenlegung zu begrenzen, falls ein Zertifikat kompromittiert wird.
5. PQC-Migrationsplanung: das Unternehmen nutzt CBOM Secure Alle eingesetzten ECC-Instanzen sollen inventarisiert werden. Langlebige CA-Privatschlüssel und Codesignaturinfrastrukturen wurden als erste Migrationskandidaten für ML-DSA (FIPS 204) vor dem NIST-Abkürzungsdatum 2030 identifiziert.

Schlüsselmanagement für ECC

• Speicherung des privaten Schlüssels: ECC-Privatschlüssel müssen für CA-Schlüssel, Codesignaturschlüssel und andere langlebige, wichtige Schlüssel in HSM-Hardware gemäß FIPS 140-2 Level 2 oder höher gespeichert werden. HSMs gewährleisten, dass kryptografische Operationen in manipulationssicherer Hardware stattfinden; der Privatschlüssel gelangt niemals in den Anwendungsspeicher eines Servers, der kompromittiert werden könnte.
• Nonce-Generierung (k-Wert-Generierung) in ECDSA: ECDSA-Signaturen erfordern für jede Signatur eine eindeutige, zufällige Nonce k. Wird k für zwei Signaturen mit demselben privaten Schlüssel wiederverwendet, lässt sich der private Schlüssel algebraisch aus den beiden Signaturen berechnen. Diese Schwachstelle wurde bei aufsehenerregenden Angriffen auf Hardwaregeräte ausgenutzt. Um dieses Risiko zu eliminieren, verwenden Sie deterministisches ECDSA (RFC 6979) oder hardwaregenerierte Nonces.
• Automatisierung des Zertifikatslebenszyklus: Da das CA/Browser Forum bis 2029 eine Gültigkeitsdauer von TLS-Zertifikaten von nur noch 47 Tagen vorschreibt, ist die manuelle Zertifikatsverwaltung in großem Umfang nicht praktikabel. Für alle ECC-TLS-Zertifikate ist eine automatisierte Verwaltung des Zertifikatslebenszyklus erforderlich. Siehe CertSecure Manager für die automatisierte Ermittlung, Verlängerung und Durchsetzung von Richtlinien.

CodeSign Secure von Encryption Consulting

CodeSign Secure unterstützt Softwareunternehmen dabei, Vertrauen bei Endnutzern aufzubauen, indem es die Authentizität und Integrität von Software-Releases mithilfe von ECC sicherstellt. Konkret verwendet CodeSign Secure ECDSA mit Schlüsseltypen wie P-256 und P-384, um digitale Signaturen zu erstellen, die bestätigen, dass die Software seit ihrer Signierung nicht verändert wurde. Wichtige Funktionen für die ECC-Implementierung:

• HSM-gestützter Schlüsselspeicher: Die signierten privaten Schlüssel werden in FIPS 140-3 validierten HSMs (die die Standards PKCS#11 und FIPS 140-3 unterstützen) gespeichert, wodurch sichergestellt wird, dass die ECC-Privatschlüssel niemals die manipulationssichere Hardware verlassen.
• CI/CD-Pipeline-Integration: automatisiert Signaturprozesse in Jenkins, Azure DevOps, GitHub Actions und anderen Plattformen und eliminiert so manuelle Signaturschritte, die menschliche Fehler und Verzögerungen verursachen.
• Prüfprotokoll und Compliance-Berichterstattung: Die detaillierte Protokollierung jedes Signierungsvorgangs unterstützt die Einhaltung der Compliance-Anforderungen und liefert Nachweise für Audits der Codesignierungsrichtlinien.
• Algorithmensteuerung: wird sichergestellt, dass nur zugelassene ECC-Kurven und Hash-Algorithmen zum Signieren verwendet werden, wodurch verhindert wird, dass Entwickler standardmäßig auf schwache Parameter zurückgreifen.

Einschränkungen der ECC

• Nicht quantensicher: Shors Algorithmus bricht das ECDLP-Problem auf einem Quantencomputer. Dies ist die größte Einschränkung für langlebige Infrastrukturen. Das NIST schlägt gemäß NIST IR 8547 vor, ECC nach 2030 abzuschaffen. Beginnen Sie jetzt mit der Planung der PQC-Migration für Zertifikatshierarchien und Codesignaturschlüssel.
• Die Wahl der Kurve ist von entscheidender Bedeutung: Die Sicherheit hängt von den mathematischen Eigenschaften der gewählten Kurve ab. Verwenden Sie ausschließlich standardisierte Kurven: NIST P-256, P-384, P-521, X25519 oder Ed25519. Implementieren Sie keine benutzerdefinierten Kurven oder Parameter.
• ECDSA-Nonce-Sicherheitsanforderung: Um das Risiko der Nonce-Wiederverwendung und damit die Offenlegung des privaten Schlüssels zu eliminieren, muss deterministisches ECDSA (RFC 6979) verwendet werden. Dies ist eine bekannte Implementierungsfalle, die bereits zu Sicherheitslücken in realen Anwendungen geführt hat.
• Einschränkungen der Kompatibilität mit älteren Systemen: Einige ältere Systeme, eingebettete Geräte und Middleware für Unternehmen unterstützen ECC nicht. Umgebungen, die maximale Abwärtskompatibilität erfordern, benötigen möglicherweise für eine Übergangszeit weiterhin RSA.

Fazit

Elliptische-Kurven-Kryptographie (ECC) gilt aufgrund ihrer Kombination aus hoher Sicherheit, kurzen Schlüssellängen, schnellen Operationen und geringem Ressourcenbedarf als bevorzugter asymmetrischer kryptographischer Algorithmus für die meisten neuen Anwendungen. ECDSA P-256 und Ed25519 sind die vom NIST empfohlenen Verfahren für digitale Signaturen und TLS; ECDHE stellt den obligatorischen Vorwärtsgeheimnis-Schlüsselaustausch in TLS 1.3 bereit. ECC ist in TLS 1.3, FIDO2, SSH, S/MIME, Codesignierung und den meisten modernen Sicherheitsprotokollen integriert.

Der entscheidende Hinweis: ECC ist nicht quantensicher. Shors Algorithmus verletzt das ECDLP. Für Infrastrukturen mit mehrjähriger Schlüssellebensdauer, wie z. B. CA-Privatschlüssel, Codesignaturinfrastruktur und langlebige TLS-Hierarchien, müssen Unternehmen jetzt mit der Planung der PQC-Migration beginnen. Das NIST hat ML-KEM (FIPS 203) und ML-DSA (FIPS 204) als postquantensichere Alternativen standardisiert. Weiterführende Informationen finden Sie in unseren Beiträgen zu symmetrischer vs. asymmetrischer Verschlüsselung und zum Vergleich von Verschlüsselungsalgorithmen.

Häufig gestellte Fragen

Was ist Elliptic Curve Cryptography (ECC)?

ECC ist ein Public-Key-Kryptosystem, das auf elliptischen Kurven über endlichen Körpern basiert und durch y² = x³ + ax + b definiert ist. Seine Sicherheit beruht auf dem ECDLP (Elliptic Curve Discrete Logarithm Problem), für das auf geeignet gewählten Kurven keine subexponentielle Lösung bekannt ist. Ein 256-Bit-ECC-Schlüssel bietet eine Sicherheit von etwa 128 Bit, was RSA-3072 entspricht. ECC wurde 1985 von Neal Koblitz und Victor S. Miller vorgeschlagen.

Worin besteht der Unterschied zwischen ECDH und ECDSA?

ECDH (Elliptic Curve Diffie-Hellman) ist ein Schlüsselaustauschprotokoll, das ein gemeinsames Geheimnis zwischen zwei Parteien etabliert, ohne dieses zu übertragen. ECDHE (ephemeral) bietet Vorwärtsgeheimhaltung; TLS 1.3 schreibt dies für alle Verbindungen vor. ECDSA (Elliptic Curve Digital Signature Algorithm) ist ein Signaturalgorithmus, der private Schlüssel zum Signieren von Daten und öffentliche Schlüssel zur Überprüfung von Signaturen verwendet. Er wird in TLS-Zertifikaten, Codesignierung und SSH-Authentifizierung eingesetzt.

Wie vergleicht sich ECC mit RSA?

ECC P-256 bietet 128-Bit-Sicherheit mit einem 32-Byte-Schlüssel; RSA benötigt 3072 Bit für vergleichbare Sicherheit. Die ECDSA-Signierung ist bei gleichem Sicherheitsniveau schneller als die RSA-Signierung. ECC-Zertifikate sind etwa ein Drittel so groß wie RSA-Zertifikate. Beide sind nicht quantensicher; für beide ist eine Migration zu Post-Quanten-Algorithmen (ML-KEM, ML-DSA) erforderlich.

Welche ECC-Kurven werden vom NIST empfohlen?

NIST FIPS 186-5 spezifiziert: P-256 (128-Bit-Sicherheit, am weitesten verbreitet), P-384 (192-Bit, Geheimhaltungsstufe „Geheim“), P-521 (256-Bit, Geheimhaltungsstufe „Streng geheim“). X25519 und Ed25519 sind weit verbreitete und anerkannte Alternativen: X25519 für den TLS-1.3-Schlüsselaustausch; Ed25519 als bevorzugter SSH-Schlüsselalgorithmus.

Ist ECC quantensicher?

Nein. Shors Algorithmus löst auf einem Quantencomputer das ECDLP effizient und bricht damit alle ECC-basierten Kryptographieverfahren. Das NIST hat postquantenbasierte Alternativen standardisiert: ML-KEM (FIPS 203) für den Schlüsselaustausch und ML-DSA (FIPS 204) für Signaturen. NIST IR 8547 schlägt vor, ECC nach 2030 als veraltet zu betrachten und es ab 2035 in neuen Anwendungen nicht mehr zuzulassen.

Wann sollte ECC anstelle von RSA verwendet werden?

Für alle neuen Implementierungen ohne Legacy-Beschränkungen: TLS-Zertifikate (ECDSA P-256), SSH-Schlüssel (Ed25519), Codesignatur (ECDSA P-256 oder P-384), DNSSEC, Mobilgeräte und IoT. Verwenden Sie RSA nur dann, wenn ECC von Legacy-Systemen nicht unterstützt wird oder spezifische Compliance-Anforderungen dies vorschreiben.