P-256 vs. P-384: wann sich 192-Bit-ECDSA lohnt

Bei P-256 vs. P-384 wählst du zwischen zwei NIST-Kurven derselben Familie: dieselben Algorithmen (ECDSA und ECDH), dieselben Kodierungen, dieselben Tools. P-384 hebt die klassische Sicherheit von etwa 128 auf etwa 192 Bit; P-256 ist um ein Mehrfaches schneller und wird von mehr Hardware unterstützt. Für die meisten Systeme entscheidet eher eine Richtlinie als das Risiko.

Auf einen Blick

Die Geschwindigkeiten wurden auf einem Kern eines Apple M4 Max mit openssl speed gemessen; das Skript für die Größen weiter unten lief mit OpenSSL 3.6.5.

Wie viel Sicherheit brauchst du?

NIST SP 800-57 Part 1 ordnet Kurven mit 256–383 Bit der 128-Bit-Sicherheit zu und Kurven mit 384–511 Bit der 192-Bit-Sicherheit. 128 Bit liegen weit jenseits jedes absehbaren klassischen Angriffs: Der beste bekannte Angriff auf P-256 braucht größenordnungsmäßig 2¹²⁸ Gruppenoperationen. Der zusätzliche Spielraum von P-384 schützt vor unerwarteten Fortschritten in der Kryptoanalyse elliptischer Kurven, nicht vor Brute-Force-Angriffen, und gegen den Shor-Algorithmus hilft er gar nicht, denn der bricht beide Kurven mit ähnlichem Aufwand. NIST IR 8547 (ein erster öffentlicher Entwurf) behandelt sie deshalb gleich: Keine der beiden gilt 2030 als veraltet (das betrifft nur Algorithmen mit 112 Bit wie RSA-2048 und P-224), und beide sind nach 2035 nicht mehr zugelassen.

Der eigentliche Treiber sind Richtlinien. Die ursprüngliche Commercial National Security Algorithm Suite der NSA (CNSA 1.0) schrieb P-384 für ECDH und ECDSA vor, deshalb setzen Produkte für nationale Sicherheitssysteme der USA und ihre Lieferketten standardmäßig auf diese Kurve; CNSA 2.0 ersetzt sie durch ML-KEM-1024 und ML-DSA-87. Zertifizierungsstellen wählen P-384 oft für Schlüssel von Root-CAs und Zwischen-CAs, die zehn Jahre oder länger vertrauenswürdig bleiben müssen; ISRG Root X2 von Let's Encrypt und die zugehörigen ECDSA-Zwischenzertifikate nutzen P-384, während die Zertifikate der Kunden jede der beiden Kurven verwenden können.

Kosten bei Leistung und Größe

OpenSSL liefert für P-256 handoptimierten Assembler-Code mit, deshalb ist der Abstand groß: etwa 87.000 Signaturen pro Sekunde mit P-256 gegenüber etwa 9.700 mit P-384 auf einem Kern eines Apple M4 Max, und etwa 29.000 gegenüber 4.500 Prüfungen. Bei einem TLS-Server signiert der Zertifikatsschlüssel einmal pro vollständigem Handshake, sodass P-384 diesen Teil der Handshake-Kosten ungefähr um den Faktor neun erhöht; für eine Zertifizierungsstelle, die einige Zertifikate pro Sekunde signiert, spielt das keine Rolle.

Die Größen wachsen moderat: Signaturen roh um 32 Byte, öffentliche Schlüssel um 32 Byte, Zertifikate um etwa 60 Byte.

#!/bin/sh
dir=$(mktemp -d)
cd "$dir" || exit 1
printf 'hello' > msg
for curve in P-256 P-384; do
  openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:$curve -out key.pem 2>/dev/null
  openssl req -new -x509 -key key.pem -subj "/CN=example.com" -days 90 -outform DER -out cert.der 2>/dev/null
  openssl dgst -sha256 -sign key.pem -out sig.der msg
  printf '%s: SPKI %s bytes, DER signature %s bytes, self-signed certificate %s bytes\n' "$curve" \
    "$(openssl pkey -in key.pem -pubout -outform DER | wc -c | tr -d ' ')" \
    "$(wc -c < sig.der | tr -d ' ')" \
    "$(wc -c < cert.der | tr -d ' ')"
done
cd / && rm -rf "$dir"

P-256: SPKI 91 bytes, DER signature 71 bytes, self-signed certificate 388 bytes
P-384: SPKI 120 bytes, DER signature 102 bytes, self-signed certificate 451 bytes

Unterstützung

Beide Kurven finden sich in FIPS 186-5 und SP 800-186, in jeder TLS-Bibliothek, in WebCrypto, in JOSE und COSE, in PIV-Smartcards und in der Liste zulässiger Zertifikatsschlüssel des CA/Browser Forum (P-256, P-384 und P-521). Lücken gibt es bei sicherer Hardware und bei Authenticators: Die Secure Enclave von Apple bietet für klassische Schlüssel nur P-256, Passkeys nutzen fast ausnahmslos ES256, und manche Secure Elements für IoT-Geräte implementieren nur P-256. Serverseitig unterstützen HSMs und KMS-Dienste in der Cloud beide Kurven.

Wann welche Kurve passt

• Öffentliche TLS-Zertifikate: P-256. Die Kurve ist im Handshake schneller und wird überall akzeptiert; Leaf-Zertifikate mit P-384 bringen nichts, was ein Client prüfen könnte.
• Schlüssel von Root-CAs und Zwischen-CAs: P-384 ist für langlebige Schlüssel eine verbreitete, vernünftige Wahl; ein solcher Schlüssel darf auch Leaf-Zertifikate mit P-256 signieren.
• JWTs und API-Tokens: ES256, sofern nicht ein Profil, etwa manche Spezifikationen von Behörden oder aus der Finanzbranche, ES384 verlangt.
• Passkeys und Geräteschlüssel: P-256, weil die Hardware genau das bietet.
• Systeme nach CNSA 1.0 und ihre Hersteller: P-384 mit SHA-384 sowie AES-256; plane den Umstieg auf ML-KEM-1024 und ML-DSA-87 nach CNSA 2.0.
• Hybrides Post-Quanten-TLS: X25519MLKEM768 für den allgemeinen Einsatz; SecP384r1MLKEM1024, wo eine Richtlinie nach Art von CNSA NIST-Kurven und Parameter der Kategorie 5 verlangt.

Hinweise zur Migration

Ein Kurvenwechsel bedeutet neue Schlüssel, die Tools bleiben aber dieselben.

1. Erzeuge den neuen Schlüssel mit openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-384 (oder P-256) direkt in dem HSM oder KMS, in dem er künftig liegen soll.
2. Kombiniere die Kurve mit dem passenden Hash. P-384 wird normalerweise mit SHA-384 verwendet (ES384, ecdsa-with-SHA384); ECDSA kürzt längere Hashes auf die Länge der Ordnung, doch unpassende Paare verwirren Richtlinienprüfungen und manche Verifizierer.
3. Aktualisiere die Kennungen: alg und crv in JOSE, den Algorithmus in COSE, das Signaturverfahren in TLS und die Zertifikatsprofile. Veröffentliche während der Rotation beide Schlüssel in einem JWKS mit unterschiedlichen Werten für kid.
4. Passe feste Puffergrößen an: Rohe Signaturen wachsen von 64 auf 96 Byte, Koordinaten von 32 auf 48 Byte.
5. Miss die Handshake-Leistung, bevor du einen stark ausgelasteten TLS-Endpunkt auf ein P-384-Zertifikat umstellst; die meisten Betreiber, die aus Richtliniengründen auf P-384 wechseln, behalten P-256 dort, wo die Richtlinie nicht greift.

Quellen

• NIST SP 800-186 (§3.2.1.3 P-256, §3.2.1.4 P-384)
• FIPS 186-5, Standard für digitale Signaturen
• NIST SP 800-57 Part 1 Rev. 5, Tabelle 2
• NIST IR 8547, erster öffentlicher Entwurf
• RFC 7518 §3.4, ES256 und ES384
• Advisory der NSA zu den Algorithmen von CNSA 2.0
• Baseline Requirements des CA/Browser Forum, §6.1.5
• Vertrauensketten von Let's Encrypt