{"id":86,"date":"2026-06-12T16:15:43","date_gmt":"2026-06-12T16:15:43","guid":{"rendered":"https:\/\/shattered.io\/de\/2026\/06\/12\/ecdsa-nodejs-signaturen\/"},"modified":"2026-06-12T20:08:46","modified_gmt":"2026-06-12T20:08:46","slug":"ecdsa-nodejs-signaturen","status":"publish","type":"post","link":"https:\/\/shattered.io\/de\/2026\/06\/12\/ecdsa-nodejs-signaturen\/","title":{"rendered":"ECDSA in Node.js: Signaturen in 11 Schritten [2026]"},"content":{"rendered":"\n

Digitale Signaturen halten das halbe Internet zusammen. Jedes TLS-Zertifikat, jedes signierte JSON Web Token, jede Bitcoin-Transaktion und jeder SSH-Login st\u00fctzt sich auf dieselbe Idee: Ein privater Schl\u00fcssel erzeugt eine Signatur, die jeder mit dem passenden \u00f6ffentlichen Schl\u00fcssel pr\u00fcfen kann, ohne den geheimen Teil je zu sehen. Der mit Abstand am h\u00e4ufigsten eingesetzte Algorithmus daf\u00fcr hei\u00dft ECDSA<\/strong> (Elliptic Curve Digital Signature Algorithm).<\/p>\n\n\n\n

In diesem Tutorial bauen Sie ECDSA von Grund auf in Node.js, ausschlie\u00dflich mit dem eingebauten crypto<\/code>-Modul, ohne externe Bibliotheken. Sie erzeugen Schl\u00fcsselpaare, signieren und verifizieren Nachrichten, exportieren Schl\u00fcssel als PEM, arbeiten mit der Bitcoin-Kurve secp256k1, vermeiden die ber\u00fcchtigte Nonce-Falle und bauen am Ende eine signierte REST-API mit ES256-Tokens. Geplante Zeit: rund 45 Minuten. Stand: 12. Juni 2026.<\/p>\n\n\n\n

Was ist ECDSA und warum es 2026 noch z\u00e4hlt<\/h2>\n\n\n\n

ECDSA ist die Variante des klassischen Digital Signature Algorithm, die auf elliptischen Kurven rechnet statt auf gro\u00dfen Primzahl-Modulen wie RSA. Der Vorteil ist drastisch kleinere Schl\u00fcssel bei gleicher Sicherheit. Ein P-256-Schl\u00fcssel liefert etwa 128 Bit Sicherheit und entspricht damit grob einem 3072-Bit-RSA-Schl\u00fcssel. Ein P-384-Schl\u00fcssel liegt ungef\u00e4hr auf dem Niveau von 7680-Bit-RSA. Kleinere Schl\u00fcssel bedeuten schnellere Handshakes, kleinere Zertifikate und weniger Bandbreite, weshalb moderne TLS-Verbindungen ECDSA-Zertifikaten den Vorzug geben.<\/p>\n\n\n\n

Eine digitale Signatur<\/a> garantiert drei Dinge gleichzeitig: Authentizit\u00e4t (die Nachricht stammt vom Inhaber des privaten Schl\u00fcssels), Integrit\u00e4t (sie wurde nicht ver\u00e4ndert) und Nichtabstreitbarkeit (der Unterzeichner kann die Signatur nicht glaubhaft leugnen). ECDSA erreicht das, indem es zuerst einen Hash der Nachricht bildet, meist mit SHA-256, und dann diesen Hash mit dem privaten Schl\u00fcssel und einer Zufallszahl signiert. Ohne den Hash w\u00fcrde der Algorithmus nicht funktionieren, weshalb ein solides Verst\u00e4ndnis von SHA-256<\/a> die Basis f\u00fcr jede ECDSA-Implementierung bildet.<\/p>\n\n\n\n

Wo begegnet Ihnen ECDSA konkret? In TLS-Zertifikatsketten und im Handshake. In JWT mit dem Algorithmus ES256. In SSH als Host- und Nutzerschl\u00fcssel neben Ed25519 und RSA. Und in jeder einzelnen Bitcoin- und Ethereum-Transaktion, dort \u00fcber die spezielle Kurve secp256k1. Wer Backend-Software baut, kommt an ECDSA praktisch nicht vorbei. Genau deshalb lohnt es sich, den Algorithmus einmal mit eigenen H\u00e4nden in Node.js umzusetzen statt ihn als Blackbox zu behandeln.<\/p>\n\n\n\n

Voraussetzungen: Versionen und Werkzeuge<\/h2>\n\n\n\n

Dieses Tutorial setzt eine moderne Node.js-Umgebung voraus. Alle Code-Beispiele nutzen ausschlie\u00dflich Bordmittel, sodass Sie keine npm-Pakete installieren m\u00fcssen (bis auf das optionale JWT-Beispiel am Ende). Pr\u00fcfen Sie zuerst Ihre Versionen.<\/p>\n\n\n\n

Komponente<\/th>Empfohlene Version (2026)<\/th>Mindestversion<\/th>Pr\u00fcfbefehl<\/th><\/tr><\/thead>
Node.js<\/td>24.x LTS (Krypton)<\/td>20.x<\/td>node -v<\/code><\/td><\/tr>
OpenSSL (in Node geb\u00fcndelt)<\/td>3.5<\/td>3.0<\/td>node -p \"process.versions.openssl\"<\/code><\/td><\/tr>
npm<\/td>11.x<\/td>10.x<\/td>npm -v<\/code><\/td><\/tr>
Editor<\/td>VS Code \/ beliebig<\/td>–<\/td>–<\/td><\/tr>
Terminal<\/td>bash \/ zsh \/ PowerShell<\/td>–<\/td>–<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Node.js 24 ist 2026 die aktuelle LTS-Linie f\u00fcr neue Projekte und wird bis April 2028 unterst\u00fctzt. Sein crypto<\/code>-Modul basiert auf OpenSSL 3.5 und l\u00e4uft mit dem Standard-Sicherheitslevel 2. Das ist wichtig: Auf Sicherheitslevel 2 verbietet OpenSSL elliptische Kurven mit weniger als 224 Bit sowie RSA-Schl\u00fcssel unter 2048 Bit. Alle Kurven in diesem Tutorial (P-256, P-384, secp256k1) liegen klar \u00fcber dieser Grenze, sodass es keine Probleme gibt. Node.js 22 funktioniert ebenfalls, befindet sich aber im Wartungsmodus.<\/p>\n\n\n\n

Falls node -v<\/code> eine Version unter 20 zeigt, aktualisieren Sie zuerst. Auf Linux und macOS ist nvm der bequemste Weg, unter Windows der offizielle Installer von nodejs.org. Legen Sie danach einen Arbeitsordner an und stellen Sie sicher, dass Sie Schreibrechte besitzen. Den vollst\u00e4ndigen Funktionsumfang des Moduls finden Sie in der offiziellen Node.js crypto-Dokumentation<\/a>, die wir in diesem Tutorial mehrfach als Referenz heranziehen.<\/p>\n\n\n\n

ECDSA vs. RSA vs. Ed25519: der direkte Vergleich<\/h2>\n\n\n\n

Bevor Sie Code schreiben, sollten Sie wissen, wann ECDSA die richtige Wahl ist und wann nicht. Drei Signaturverfahren dominieren 2026 die Praxis. Die folgende Tabelle stellt sie gegen\u00fcber.<\/p>\n\n\n\n

Eigenschaft<\/th>ECDSA (P-256)<\/th>RSA-3072<\/th>Ed25519 (EdDSA)<\/th><\/tr><\/thead>
Sicherheitsniveau<\/td>~128 Bit<\/td>~128 Bit<\/td>~128 Bit<\/td><\/tr>
\u00d6ffentlicher Schl\u00fcssel<\/td>~65 Byte<\/td>~398 Byte<\/td>32 Byte<\/td><\/tr>
Signaturgr\u00f6\u00dfe<\/td>~64 bis 72 Byte<\/td>~384 Byte<\/td>64 Byte<\/td><\/tr>
Signieren (relativ)<\/td>schnell<\/td>langsam<\/td>sehr schnell<\/td><\/tr>
Verifizieren (relativ)<\/td>mittel<\/td>sehr schnell<\/td>schnell<\/td><\/tr>
Nonce-empfindlich<\/td>ja (kritisch)<\/td>nein<\/td>nein (deterministisch)<\/td><\/tr>
JWT-Kennung<\/td>ES256 \/ ES384<\/td>RS256 \/ PS256<\/td>EdDSA<\/td><\/tr>
Bitcoin \/ Ethereum<\/td>ja (secp256k1)<\/td>nein<\/td>nein<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Die wichtigste Erkenntnis: Ed25519 geh\u00f6rt nicht zu ECDSA, sondern zur Familie EdDSA. Es nutzt einen deterministischen Ansatz und umgeht damit die gef\u00e4hrlichste Schw\u00e4che von ECDSA, die Zufallszahl pro Signatur. Wenn Sie heute ein neues System ohne Altlasten bauen und Ihre Gegenstellen Ed25519 unterst\u00fctzen, ist es oft die robustere Wahl. ECDSA gewinnt dort, wo Sie Kompatibilit\u00e4t brauchen: TLS-Zertifikate von \u00f6ffentlichen CAs, ES256-Tokens in OAuth-\u00d6kosystemen, SSH gegen \u00e4ltere Server und vor allem Blockchain. Ein SSH-Schl\u00fcssel auf Basis von Ed25519 l\u00e4sst sich \u00fcbrigens in wenigen Minuten erzeugen, wie unser Leitfaden zum SSH-Key mit Ed25519<\/a> zeigt.<\/p>\n\n\n\n

RSA bleibt relevant, wenn Verifikation extrem h\u00e4ufig und Signierung selten passiert, etwa bei Software-Signaturen, die Millionen Clients pr\u00fcfen. F\u00fcr die meisten Web-Backends ist ECDSA mit P-256 jedoch der pragmatische Mittelweg aus Geschwindigkeit, Kompatibilit\u00e4t und kleinen Schl\u00fcsseln.<\/p>\n\n\n\n

Schritt 1: Das Projekt einrichten<\/h2>\n\n\n\n

Erstellen Sie einen Projektordner und initialisieren Sie ihn. Wir aktivieren ES-Module, damit wir modernes import<\/code>-Syntax nutzen k\u00f6nnen.<\/p>\n\n\n\n

mkdir ecdsa-tutorial && cd ecdsa-tutorial\nnpm init -y\nnpm pkg set type=module\nnode -v          # erwartet v24.x oder mindestens v20.x\nnode -p \"process.versions.openssl\"   # erwartet 3.5 oder h\u00f6her<\/code><\/pre>\n\n\n\n
Der Befehl npm pkg set type=module<\/code> tr\u00e4gt \"type\": \"module\"<\/code> in die package.json<\/code> ein. Damit behandelt Node jede .js<\/code>-Datei als ES-Modul. Legen Sie nun eine erste Datei an und pr\u00fcfen Sie, dass das crypto-Modul verf\u00fcgbar ist.<\/p>\n\n\n\n
\/\/ check.js\nimport { getCurves } from 'node:crypto';\n\nconsole.log('Verf\u00fcgbare Kurven (Auszug):');\nconsole.log(getCurves().filter(c => ['prime256v1', 'secp384r1', 'secp256k1'].includes(c)));<\/code><\/pre>\n\n\n\n
F\u00fchren Sie die Datei mit node check.js<\/code> aus. Die erwartete Ausgabe best\u00e4tigt, dass die drei Kurven, die wir nutzen werden, vorhanden sind:<\/p>\n\n\n\n
Verf\u00fcgbare Kurven (Auszug):\n[ 'prime256v1', 'secp384r1', 'secp256k1' ]<\/code><\/pre>\n\n\n\n
Wichtig zur Namensgebung: In OpenSSL und damit in Node hei\u00dft die NIST-Kurve P-256 intern prime256v1<\/code>. P-384 hei\u00dft secp384r1<\/code>. Diese internen Namen verwenden Sie \u00fcberall dort, wo Node eine Kurve als Zeichenkette erwartet. Merken Sie sich die Zuordnung, sie ist eine h\u00e4ufige Stolperfalle.<\/p>\n\n\n\n
Schritt 2: Ein ECDSA-Schl\u00fcsselpaar erzeugen<\/h2>\n\n\n\n
Jetzt erzeugen Sie das Herzst\u00fcck: ein Schl\u00fcsselpaar auf der Kurve P-256. Node bietet daf\u00fcr generateKeyPairSync<\/code>, die synchrone Variante, ideal zum Lernen. In Produktion bevorzugen Sie die asynchrone Variante, dazu sp\u00e4ter mehr.<\/p>\n\n\n\n
\/\/ keys.js\nimport { generateKeyPairSync } from 'node:crypto';\n\nconst { publicKey, privateKey } = generateKeyPairSync('ec', {\n  namedCurve: 'prime256v1',   \/\/ entspricht NIST P-256\n});\n\nconsole.log('Privater Schl\u00fcssel-Typ:', privateKey.asymmetricKeyType);\nconsole.log('Kurve:', privateKey.asymmetricKeyDetails.namedCurve);\n\nexport { publicKey, privateKey };<\/code><\/pre>\n\n\n\n
Die Ausgabe sieht so aus:<\/p>\n\n\n\n
Privater Schl\u00fcssel-Typ: ec\nKurve: prime256v1<\/code><\/pre>\n\n\n\n
Beachten Sie, dass publicKey<\/code> und privateKey<\/code> hier KeyObject<\/code>-Instanzen sind, keine reinen Zeichenketten. Ein KeyObject ist Nodes interne, sichere Repr\u00e4sentation eines Schl\u00fcssels. Es verhindert versehentliches Loggen des geheimen Materials und l\u00e4sst sich direkt an Signierfunktionen \u00fcbergeben. Erst wenn Sie Schl\u00fcssel speichern oder \u00fcber das Netz schicken, wandeln Sie sie in PEM- oder DER-Format um, das zeigt Schritt 5.<\/p>\n\n\n\n
Wollen Sie stattdessen die st\u00e4rkere Kurve P-384, \u00e4ndern Sie lediglich namedCurve: 'secp384r1'<\/code>. F\u00fcr Bitcoin-kompatible Schl\u00fcssel verwenden Sie 'secp256k1'<\/code>. Der restliche Code bleibt identisch, das ist die Eleganz der KeyObject-Abstraktion.<\/p>\n\n\n\n
Schritt 3: Eine Nachricht signieren<\/h2>\n\n\n\n
Mit dem Schl\u00fcsselpaar in der Hand signieren Sie nun Daten. Node stellt die sign<\/code>-Funktion bereit, die den Hash intern berechnet. Sie geben nur den Hash-Algorithmus an, hier SHA-256, was zusammen mit P-256 dem JWT-Standard ES256 entspricht.<\/p>\n\n\n\n
\/\/ sign.js\nimport { sign } from 'node:crypto';\nimport { privateKey } from '.\/keys.js';\n\nconst nachricht = Buffer.from('\u00dcberweisung: 250 EUR an Konto DE89...');\n\n\/\/ SHA-256 wird intern gebildet, dann mit dem privaten Schl\u00fcssel signiert\nconst signatur = sign('sha256', nachricht, {\n  key: privateKey,\n  dsaEncoding: 'ieee-p1363',   \/\/ festes 64-Byte-Format, ideal f\u00fcr JWT\/Web\n});\n\nconsole.log('Signaturl\u00e4nge:', signatur.length, 'Byte');\nconsole.log('Signatur (base64url):', signatur.toString('base64url'));\n\nexport { nachricht, signatur };<\/code><\/pre>\n\n\n\n
Eine typische Ausgabe:<\/p>\n\n\n\n
Signaturl\u00e4nge: 64 Byte\nSignatur (base64url): k3Jx9... (gek\u00fcrzt)<\/code><\/pre>\n\n\n\n
Der Parameter dsaEncoding<\/code> ist entscheidend und wird oft \u00fcbersehen. ECDSA-Signaturen bestehen aus zwei Zahlen, r und s. Es gibt zwei Wege, sie zu kodieren. Der Standard 'der'<\/code> verpackt sie in eine ASN.1-Struktur variabler L\u00e4nge (etwa 70 bis 72 Byte). Das Format 'ieee-p1363'<\/code> h\u00e4ngt r und s einfach aneinander und liefert konstant 64 Byte bei P-256. Web-Standards wie JWT (ES256) und WebCrypto verlangen P1363. Wenn Sie mit OpenSSL-Kommandozeile oder X.509-Zertifikaten arbeiten, brauchen Sie DER. Verwechseln Sie die beiden, schl\u00e4gt jede Verifikation fehl, obwohl Schl\u00fcssel und Daten korrekt sind.<\/p>\n\n\n\n
Ein zweiter wichtiger Punkt: Jeder Aufruf von sign<\/code> erzeugt eine andere Signatur f\u00fcr dieselbe Nachricht. Das ist kein Fehler, sondern liegt an der internen Zufallszahl k. Solange diese Zufallszahl echt zuf\u00e4llig ist, ist das Verhalten korrekt und sicher.<\/p>\n\n\n\n
Schritt 4: Die Signatur verifizieren<\/h2>\n\n\n\n
Die Verifikation nutzt den \u00f6ffentlichen Schl\u00fcssel. Sie liefert einen schlichten Booleschen Wert: true<\/code> bei g\u00fcltiger Signatur, false<\/code> sonst. Wichtig ist, dass Sie exakt dieselbe dsaEncoding<\/code> wie beim Signieren angeben.<\/p>\n\n\n\n
\/\/ verify.js\nimport { verify } from 'node:crypto';\nimport { publicKey } from '.\/keys.js';\nimport { nachricht, signatur } from '.\/sign.js';\n\nconst gueltig = verify('sha256', nachricht, {\n  key: publicKey,\n  dsaEncoding: 'ieee-p1363',\n}, signatur);\n\nconsole.log('Signatur g\u00fcltig?', gueltig);   \/\/ true\n\n\/\/ Manipulationstest: ein Byte \u00e4ndern\nconst gefaelscht = Buffer.from('\u00dcberweisung: 999 EUR an Konto DE89...');\nconst gueltig2 = verify('sha256', gefaelscht, {\n  key: publicKey,\n  dsaEncoding: 'ieee-p1363',\n}, signatur);\n\nconsole.log('Manipulierte Nachricht g\u00fcltig?', gueltig2);   \/\/ false<\/code><\/pre>\n\n\n\n
Erwartete Ausgabe:<\/p>\n\n\n\n
Signatur g\u00fcltig? true\nManipulierte Nachricht g\u00fcltig? false<\/code><\/pre>\n\n\n\n
Dieser Manipulationstest demonstriert die Kernaussage jeder Signatur: Schon die \u00c4nderung eines einzigen Zeichens (250 zu 999) f\u00fchrt zu einem v\u00f6llig anderen SHA-256-Hash, und die alte Signatur passt nicht mehr. Genau dieses Prinzip sch\u00fctzt TLS-Verbindungen, Software-Updates und Blockchain-Transaktionen. Wer tiefer verstehen will, warum schon kleinste \u00c4nderungen den Hash komplett umwerfen, findet die Erkl\u00e4rung in unserem Beitrag \u00fcber digitale Signaturen<\/a>.<\/p>\n\n\n\n
Ein praktischer Sicherheitshinweis: Behandeln Sie eine false<\/code>-R\u00fcckgabe immer als Ablehnung der gesamten Anfrage. Loggen Sie den Vorfall, aber verraten Sie dem Aufrufer nie, warum genau die Pr\u00fcfung scheiterte. Detaillierte Fehlermeldungen helfen Angreifern beim systematischen Ausprobieren.<\/p>\n\n\n\n
Schritt 5: Schl\u00fcssel als PEM exportieren und laden<\/h2>\n\n\n\n
Bisher lebten die Schl\u00fcssel nur im Speicher. F\u00fcr echte Anwendungen m\u00fcssen Sie sie persistieren, etwa in einer Datei oder einem Secret-Manager. Das Standardformat daf\u00fcr ist PEM, eine base64-kodierte Textdarstellung mit Kopf- und Fu\u00dfzeile.<\/p>\n\n\n\n
\/\/ export.js\nimport { generateKeyPairSync, createPrivateKey, createPublicKey } from 'node:crypto';\nimport { writeFileSync, readFileSync } from 'node:fs';\n\nconst { publicKey, privateKey } = generateKeyPairSync('ec', {\n  namedCurve: 'prime256v1',\n});\n\n\/\/ Export als PEM-Text\nconst privPem = privateKey.export({ type: 'pkcs8', format: 'pem' });\nconst pubPem  = publicKey.export({ type: 'spki', format: 'pem' });\n\nwriteFileSync('private.pem', privPem);\nwriteFileSync('public.pem', pubPem);\nconsole.log('Schl\u00fcssel geschrieben.');\n\n\/\/ Wieder einlesen\nconst privGeladen = createPrivateKey(readFileSync('private.pem'));\nconst pubGeladen  = createPublicKey(readFileSync('public.pem'));\nconsole.log('Geladene Kurve:', privGeladen.asymmetricKeyDetails.namedCurve);<\/code><\/pre>\n\n\n\n
Die Ausgabe best\u00e4tigt das Schreiben und Laden:<\/p>\n\n\n\n
Schl\u00fcssel geschrieben.\nGeladene Kurve: prime256v1<\/code><\/pre>\n\n\n\n
Zur Terminologie: pkcs8<\/code> ist das moderne Containerformat f\u00fcr private Schl\u00fcssel, spki<\/code> das f\u00fcr \u00f6ffentliche. Diese Kombination ist 2026 die empfohlene Wahl und mit nahezu jeder anderen Krypto-Bibliothek kompatibel. Die erzeugte private.pem<\/code> beginnt mit -----BEGIN PRIVATE KEY-----<\/code>, die public.pem<\/code> mit -----BEGIN PUBLIC KEY-----<\/code>.<\/p>\n\n\n\n
Private Schl\u00fcssel niemals im Klartext ablegen<\/h3>\n\n\n\n
Eine unverschl\u00fcsselte private.pem<\/code> auf der Festplatte ist ein Risiko. In Produktion verschl\u00fcsseln Sie den privaten Schl\u00fcssel mit einer Passphrase oder lagern ihn in einem Secret-Manager wie HashiCorp Vault, AWS KMS oder einem Hardware-Sicherheitsmodul aus. F\u00fcr die passphrasen-gesch\u00fctzte Variante erg\u00e4nzen Sie beim Export einfach eine cipher<\/code>– und passphrase<\/code>-Option. Wer einen verschl\u00fcsselten Datentr\u00e4ger als zus\u00e4tzliche Schutzschicht m\u00f6chte, findet praktische Schritte in unserem Tutorial zu VeraCrypt<\/a>.<\/p>\n\n\n\n
Schritt 6: Mit secp256k1 arbeiten, der Bitcoin-Kurve<\/h2>\n\n\n\n
Bitcoin und Ethereum nutzen nicht P-256, sondern die Kurve secp256k1. Sie bietet ebenfalls rund 128 Bit Sicherheit, wurde aber mit besonders nachvollziehbaren Parametern entworfen, was Misstrauen gegen\u00fcber m\u00f6glichen Hintert\u00fcren reduziert. In Node ist sie ein einzeiliger Tausch.<\/p>\n\n\n\n
\/\/ bitcoin-curve.js\nimport { generateKeyPairSync, sign, verify } from 'node:crypto';\n\nconst { publicKey, privateKey } = generateKeyPairSync('ec', {\n  namedCurve: 'secp256k1',   \/\/ die Bitcoin- und Ethereum-Kurve\n});\n\nconst tx = Buffer.from('send 0.05 BTC to bc1q...');\nconst sig = sign('sha256', tx, { key: privateKey, dsaEncoding: 'ieee-p1363' });\nconst ok  = verify('sha256', tx, { key: publicKey, dsaEncoding: 'ieee-p1363' }, sig);\n\nconsole.log('secp256k1-Signatur g\u00fcltig?', ok);   \/\/ true\nconsole.log('Signaturl\u00e4nge:', sig.length, 'Byte'); \/\/ 64<\/code><\/pre>\n\n\n\n
Die Mechanik ist identisch zu P-256, nur die Kurve wechselt. In echten Wallets kommen jedoch zus\u00e4tzliche Konventionen hinzu: Bitcoin verlangt sogenannte Low-S-Signaturen (BIP 62), um Transaktions-Malleability zu verhindern, und nutzt double-SHA256 statt einfachem SHA-256. Das eingebaute crypto-Modul deckt die Kryptografie ab, die Blockchain-spezifischen Regeln implementieren spezialisierte Bibliotheken. Eine technische Referenz zur Kurve selbst bietet das Bitcoin-Wiki zu secp256k1<\/a>.<\/p>\n\n\n\n
Wer den privaten Schl\u00fcssel einer Kryptow\u00e4hrung verwaltet, sollte ihn niemals auf einem Server im Klartext halten. Hardware-Wallets isolieren das Schl\u00fcsselmaterial physisch. Der Unterschied zwischen den g\u00e4ngigen Ger\u00e4ten ist Thema unseres Vergleichs Ledger vs. Trezor<\/a>.<\/p>\n\n\n\n
Schritt 7: Das Nonce-Problem und deterministische Signaturen<\/h2>\n\n\n\n
Jetzt zur gef\u00e4hrlichsten Eigenschaft von ECDSA. Bei jeder Signatur w\u00e4hlt der Algorithmus eine geheime Zufallszahl k, die Nonce. Diese Zahl darf niemals zweimal mit demselben privaten Schl\u00fcssel verwendet werden, und sie darf nicht vorhersagbar sein. Versto\u00dfen Sie dagegen, l\u00e4sst sich der private Schl\u00fcssel aus zwei Signaturen mathematisch zur\u00fcckrechnen. Das ist kein theoretisches Risiko.<\/p>\n\n\n\n
Das bekannteste Beispiel ist die Sony PlayStation 3 aus dem Jahr 2010. Sony verwendete eine feste, konstante Nonce f\u00fcr alle ECDSA-Signaturen der Firmware. Angreifer extrahierten daraus den privaten Signierschl\u00fcssel und konnten beliebigen Code als offiziell signiert ausgeben. Der gesamte Schutzmechanismus der Konsole brach an einem einzigen Implementierungsfehler zusammen.<\/p>\n\n\n\n
Die gute Nachricht: Node.js und OpenSSL erzeugen die Nonce mit einem kryptografisch sicheren Zufallsgenerator. Solange Sie das eingebaute sign<\/code> nutzen und nicht selbst an der Nonce schrauben, sind Sie gesch\u00fctzt. Sie k\u00f6nnen die Robustheit zus\u00e4tzlich erh\u00f6hen, indem Sie auf deterministische ECDSA-Signaturen nach RFC 6979 setzen, die k aus dem Schl\u00fcssel und der Nachricht ableiten statt aus einem Zufallsgenerator.<\/p>\n\n\n\n
\/\/ Hinweis: Das eingebaute crypto-Modul nutzt zuf\u00e4llige Nonces.\n\/\/ F\u00fcr deterministische Signaturen nach RFC 6979 nutzen Sie\n\/\/ eine spezialisierte Bibliothek oder wechseln zu Ed25519,\n\/\/ das von Haus aus deterministisch arbeitet.\n\nimport { generateKeyPairSync, sign } from 'node:crypto';\n\nconst { privateKey } = generateKeyPairSync('ed25519');   \/\/ EdDSA, deterministisch\nconst msg = Buffer.from('keine Nonce-Sorgen');\nconst sig1 = sign(null, msg, privateKey);   \/\/ Hash-Algorithmus = null bei Ed25519\nconst sig2 = sign(null, msg, privateKey);\n\nconsole.log('Ed25519 deterministisch?', sig1.equals(sig2)); \/\/ true<\/code><\/pre>\n\n\n\n
Beachten Sie zwei Details im Ed25519-Beispiel: Der Hash-Parameter ist null<\/code>, weil Ed25519 das Hashing selbst \u00fcbernimmt, und zwei Signaturen derselben Nachricht sind identisch. Diese Determiniertheit ist genau der Grund, warum viele neue Protokolle Ed25519 bevorzugen. Die formale Grundlage f\u00fcr deterministisches ECDSA beschreibt RFC 6979<\/a>.<\/p>\n\n\n\n
Schritt 8: ECDSA in JSON Web Tokens (ES256)<\/h2>\n\n\n\n
Die h\u00e4ufigste Begegnung mit ECDSA im Web ist der Algorithmus ES256: ECDSA mit P-256 und SHA-256, der genau das P1363-Format aus Schritt 3 nutzt. Wir bauen ein minimales, signiertes Token von Hand, um zu zeigen, dass kein Zauber dahintersteckt.<\/p>\n\n\n\n
\/\/ es256.js\nimport { generateKeyPairSync, sign, verify } from 'node:crypto';\n\nconst { publicKey, privateKey } = generateKeyPairSync('ec', { namedCurve: 'prime256v1' });\n\nconst b64 = (obj) => Buffer.from(JSON.stringify(obj)).toString('base64url');\n\nconst header  = b64({ alg: 'ES256', typ: 'JWT' });\nconst payload = b64({ sub: 'user-42', role: 'admin', exp: 1781000000 });\nconst signingInput = `${header}.${payload}`;\n\nconst signature = sign('sha256', Buffer.from(signingInput), {\n  key: privateKey, dsaEncoding: 'ieee-p1363',\n}).toString('base64url');\n\nconst jwt = `${signingInput}.${signature}`;\nconsole.log('JWT:', jwt);\n\n\/\/ Verifikation\nconst [h, p, s] = jwt.split('.');\nconst ok = verify('sha256', Buffer.from(`${h}.${p}`), {\n  key: publicKey, dsaEncoding: 'ieee-p1363',\n}, Buffer.from(s, 'base64url'));\nconsole.log('Token g\u00fcltig?', ok);   \/\/ true<\/code><\/pre>\n\n\n\n
Dieses Beispiel zeigt die Anatomie eines JWT: Header, Payload und Signatur, jeweils base64url-kodiert und mit Punkten getrennt. Der entscheidende Punkt ist dsaEncoding: 'ieee-p1363'<\/code>. Mit dem Standard-DER-Format w\u00fcrde jede konforme JWT-Bibliothek das Token ablehnen, weil der ES256-Standard das feste 64-Byte-Format vorschreibt. Die formale Definition steht in RFC 7518 (JSON Web Algorithms)<\/a>.<\/p>\n\n\n\n
In der Praxis schreiben Sie JWTs nat\u00fcrlich nicht von Hand, sondern nutzen eine gepr\u00fcfte Bibliothek, die auch Ablauf, Audience und weitere Claims validiert. Das Handbeispiel dient dem Verst\u00e4ndnis. So sehen Sie, dass ein ES256-Token nichts weiter ist als eine ECDSA-Signatur \u00fcber zwei base64url-Strings.<\/p>\n\n\n\n
Schritt 9: Komplettprojekt, eine signierte REST-API<\/h2>\n\n\n\n
Jetzt f\u00fcgen wir alles zu einem lauff\u00e4higen Mini-Server zusammen. Er stellt zwei Endpunkte bereit: \/sign<\/code> erzeugt f\u00fcr eine Nachricht eine Signatur, \/verify<\/code> pr\u00fcft sie. Wir nutzen nur den eingebauten HTTP-Server, also weiterhin keine Abh\u00e4ngigkeiten.<\/p>\n\n\n\n
\/\/ server.js\nimport { createServer } from 'node:http';\nimport { generateKeyPairSync, sign, verify } from 'node:crypto';\n\n\/\/ Schl\u00fcsselpaar einmalig beim Start (in Produktion aus Secret-Manager laden)\nconst { publicKey, privateKey } = generateKeyPairSync('ec', { namedCurve: 'prime256v1' });\nconst ENC = 'ieee-p1363';\n\nfunction readBody(req) {\n  return new Promise((resolve) => {\n    let data = '';\n    req.on('data', (c) => (data += c));\n    req.on('end', () => resolve(data));\n  });\n}\n\nconst server = createServer(async (req, res) => {\n  res.setHeader('Content-Type', 'application\/json');\n  try {\n    if (req.method === 'POST' && req.url === '\/sign') {\n      const { message } = JSON.parse(await readBody(req));\n      if (typeof message !== 'string') throw new Error('message fehlt');\n      const sig = sign('sha256', Buffer.from(message), { key: privateKey, dsaEncoding: ENC });\n      res.end(JSON.stringify({ message, signature: sig.toString('base64url') }));\n      return;\n    }\n    if (req.method === 'POST' && req.url === '\/verify') {\n      const { message, signature } = JSON.parse(await readBody(req));\n      const ok = verify('sha256', Buffer.from(message), { key: publicKey, dsaEncoding: ENC },\n                        Buffer.from(signature, 'base64url'));\n      res.statusCode = ok ? 200 : 401;\n      res.end(JSON.stringify({ valid: ok }));\n      return;\n    }\n    res.statusCode = 404;\n    res.end(JSON.stringify({ error: 'not found' }));\n  } catch (err) {\n    res.statusCode = 400;\n    res.end(JSON.stringify({ error: 'bad request' }));\n  }\n});\n\nserver.listen(3000, () => console.log('ECDSA-API l\u00e4uft auf http:\/\/localhost:3000'));<\/code><\/pre>\n\n\n\n
Starten Sie den Server mit node server.js<\/code> und testen Sie ihn in einem zweiten Terminal mit curl:<\/p>\n\n\n\n
# Signieren\ncurl -s -X POST http:\/\/localhost:3000\/sign \\\n  -H 'Content-Type: application\/json' \\\n  -d '{\"message\":\"Hallo ECDSA\"}'\n# Antwort: {\"message\":\"Hallo ECDSA\",\"signature\":\"q8Fa...gekuerzt...\"}\n\n# Verifizieren (Signatur aus der Antwort oben einsetzen)\ncurl -s -X POST http:\/\/localhost:3000\/verify \\\n  -H 'Content-Type: application\/json' \\\n  -d '{\"message\":\"Hallo ECDSA\",\"signature\":\"q8Fa...gekuerzt...\"}'\n# Antwort: {\"valid\":true}<\/code><\/pre>\n\n\n\n
Damit haben Sie eine vollst\u00e4ndige, lauff\u00e4hige ECDSA-Anwendung. Der Server h\u00e4lt den privaten Schl\u00fcssel, Clients erhalten nur Signaturen und pr\u00fcfen Nachrichten. Beachten Sie die Fehlerbehandlung: Jeder Ausnahmefall endet in einem generischen 400 oder einem 401 ohne Detailinformation. Diese Zur\u00fcckhaltung ist Absicht und geh\u00f6rt zu sicherer API-Gestaltung.<\/p>\n\n\n\n
Den \u00f6ffentlichen Schl\u00fcssel verteilen<\/h3>\n\n\n\n
In einer echten Architektur w\u00fcrden Clients den \u00f6ffentlichen Schl\u00fcssel kennen, um Signaturen selbst zu pr\u00fcfen, ohne dem Server zu vertrauen. Erg\u00e4nzen Sie daf\u00fcr einen GET \/pubkey<\/code>-Endpunkt, der publicKey.export({ type: 'spki', format: 'pem' })<\/code> ausliefert. So verifiziert jeder Client lokal, was die Skalierbarkeit erh\u00f6ht und die Vertrauensbasis verkleinert.<\/p>\n\n\n\n
Schritt 10: Automatisierte Tests schreiben<\/h2>\n\n\n\n
Krypto-Code ohne Tests ist riskant, weil Fehler oft still bleiben: Eine falsche Kodierung f\u00fchrt nicht zum Absturz, sondern liefert einfach immer false<\/code>. Node 24 bringt einen eingebauten Test-Runner mit, sodass Sie keine Test-Bibliothek installieren m\u00fcssen.<\/p>\n\n\n\n
\/\/ test\/ecdsa.test.js\nimport { test } from 'node:test';\nimport assert from 'node:assert\/strict';\nimport { generateKeyPairSync, sign, verify } from 'node:crypto';\n\nconst ENC = 'ieee-p1363';\nconst keys = generateKeyPairSync('ec', { namedCurve: 'prime256v1' });\n\ntest('g\u00fcltige Signatur verifiziert als true', () => {\n  const msg = Buffer.from('test');\n  const sig = sign('sha256', msg, { key: keys.privateKey, dsaEncoding: ENC });\n  assert.equal(verify('sha256', msg, { key: keys.publicKey, dsaEncoding: ENC }, sig), true);\n});\n\ntest('manipulierte Nachricht verifiziert als false', () => {\n  const sig = sign('sha256', Buffer.from('test'), { key: keys.privateKey, dsaEncoding: ENC });\n  assert.equal(verify('sha256', Buffer.from('test!'), { key: keys.publicKey, dsaEncoding: ENC }, sig), false);\n});\n\ntest('falsches Encoding schl\u00e4gt fehl', () => {\n  const sig = sign('sha256', Buffer.from('test'), { key: keys.privateKey, dsaEncoding: 'der' });\n  assert.equal(verify('sha256', Buffer.from('test'), { key: keys.publicKey, dsaEncoding: ENC }, sig), false);\n});<\/code><\/pre>\n\n\n\n
F\u00fchren Sie die Tests mit node --test<\/code> aus. Die erwartete Ausgabe:<\/p>\n\n\n\n
\u2714 g\u00fcltige Signatur verifiziert als true\n\u2714 manipulierte Nachricht verifiziert als false\n\u2714 falsches Encoding schl\u00e4gt fehl\n\u2139 tests 3\n\u2139 pass 3\n\u2139 fail 0<\/code><\/pre>\n\n\n\n
Der dritte Test ist besonders lehrreich: Er beweist, dass eine DER-Signatur gegen einen P1363-Verifizierer scheitert, obwohl Schl\u00fcssel und Nachricht stimmen. Genau dieser Fall verursacht in der Praxis die meisten ratlosen Debug-Stunden.<\/p>\n\n\n\n
F\u00fcnf h\u00e4ufige Fehler und wie Sie sie vermeiden<\/h2>\n\n\n\n
Diese Stolperfallen tauchen immer wieder auf, wenn Entwickler ECDSA das erste Mal einsetzen. Wer sie kennt, spart sich Stunden.<\/p>\n\n\n\n