From fc414239f89c0b76c149c28b34478c9f09311416 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Niels=20G=C3=B6ttsch?= Date: Sun, 14 Jun 2026 18:52:31 +0200 Subject: [PATCH] [IMP] add next cryto task --- CRYPTO-UPDATE.md | 48 +++++ test-pairing.html | 463 ++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 511 insertions(+) create mode 100644 CRYPTO-UPDATE.md create mode 100644 test-pairing.html diff --git a/CRYPTO-UPDATE.md b/CRYPTO-UPDATE.md new file mode 100644 index 0000000..32cfc84 --- /dev/null +++ b/CRYPTO-UPDATE.md @@ -0,0 +1,48 @@ +KONTEXT +Vanilla-ECMAScript-Projekt. Mein aktuelles Protokoll committet Geheimnisse +per H(secret) und teilt einen Schlüssel n-of-n auf. Ich ersetze das durch ein +2-von-3 Threshold-Schema: Pedersen-DKG + Threshold-ElGamal mit verifizierbarer +verteilter Entschlüsselung (Chaum-Pedersen-Beweise statt blankem Hash). +Die fertige npm-Library threshold-elgamal scheidet aus: sie funktioniert +zuverlässig nur mit threshold == Teilnehmerzahl, nicht mit 2-von-3. + +AUFGABE +1. Inspiziere zuerst das Repo: finde den bestehenden Commit-/Keypart-Code, + bestimme die öffentliche Schnittstelle (welche Funktionen rufen Aufrufer + auf), und liste sie mir auf, BEVOR du etwas änderst. + +2. Füge @noble/curves als Fundament hinzu (auditiert, dependency-frei). + Verifiziere die aktuelle Version aus dem npm-Registry, bevor du pinst. + KEINE selbstgebaute Feldarithmetik, KEIN eigenes BigInt-Modular-Inverse – + alles über noble. + +3. Implementiere mit threshold=2, parties=3 auf einer Prime-Order-Gruppe + (Ristretto255 via @noble/curves bevorzugt): + - Pedersen-VSS / Pedersen-DKG: zwei Polynome Grad 1, Koeffizienten- + Commitments C_k = g^a_k · h^b_k, h mit unbekanntem log_g(h). + - Verteilte Schlüsselerzeugung: jede Partei dealt einen Beitrag, jede + verifiziert jeden empfangenen Share gegen die Commitments. + - Threshold-ElGamal als KEM: Payload NICHT direkt mit ElGamal. Rekonstruiere + per 2 partiellen Entschlüsselungen das gemeinsame Gruppenelement, leite + daraus per HKDF-SHA256 einen 256-bit Key ab, verschlüssele das Payload mit + AES-256-GCM (WebCrypto subtle, nicht selbst gebaut). + - Jede partielle Entschlüsselung trägt einen Chaum-Pedersen-Beweis der + DL-Gleichheit; verifiziere VOR der Lagrange-Kombination. + +4. Behalte die bestehende öffentliche Schnittstelle bei (gleiche Signaturen), + damit Aufrufer unverändert bleiben. Markiere den alten Code deprecated statt + ihn zu löschen. + +5. Tests: (a) 2 von 3 entschlüsseln erfolgreich, (b) 1 allein scheitert, + (c) manipulierte partielle Entschlüsselung wird durch die Verifikation + abgelehnt, (d) manipulierter VSS-Share fliegt bei der DKG-Verifikation auf, + (e) echtes Payload Round-Trip. + +EINSCHRÄNKUNGEN / WARNUNG +- Das ist selbstgebaute Threshold-Krypto. Setze einen unübersehbaren Kommentar + an den Kern: nicht auditiert, Komposition über noble ist ungeprüft. +- Nutze ausschließlich noble + WebCrypto für alle Primitiven. Erfinde keine + Kurven-, Hash- oder Symmetrie-Operationen selbst. +- Konstante-Zeit-Verhalten kannst du in reinem JS nicht garantieren – halte das + im Kommentar fest. +- Ändere nichts an meiner Geheimnis-/Key-Persistenz, ohne vorher zu fragen. diff --git a/test-pairing.html b/test-pairing.html new file mode 100644 index 0000000..20b9662 --- /dev/null +++ b/test-pairing.html @@ -0,0 +1,463 @@ + + + + + + randomp2p – Pairing-Test + + + +

randomp2p Pairing-Test

+

Mock-SimplePeer statt WebRTC – testet QR-Pairing, Mesh-Aufbau und Chat

+ + +
+ + + + + + + +