// experimentelle demo

Registration-Based Encryption — Interaktive Demo

Diese Demo zeigt, wie Registration-Based Encryption (RBE) funktioniert — ein gitterbasiertes Kryptosystem, das den Key Curator als transparente, nicht-vertrauenswürdige Instanz modelliert. Alle Nutzer-Operationen laufen lokal im Browser, KC-Operationen laufen server-seitig — exakt wie in einem echten Deployment.

Experimentell — in Entwicklung

// was ist rbe — und warum kein zertifikat?

In klassischer PKI muss Alice ein Zertifikat von einer Zertifizierungsstelle (CA) signieren lassen. Bob muss dieses Zertifikat prüfen, bevor er Alice schreiben kann — die CA ist ein zentraler Vertrauensanker mit weitreichenden Befugnissen.

Registration-Based Encryption (RBE) geht einen anderen Weg: Ein Key Curator (KC) übernimmt die Registrierung, kennt aber keinen einzigen Secret Key. Jeder Nutzer generiert sein Schlüsselpaar lokal auf seinem Gerät und übergibt nur den Public Key an den KC. Dieser addiert alle Public Keys zu einem einzigen aggregierten Wert mpkAgg auf — der Sender braucht nur diesen einen Wert und den Namen des Empfängers (seine Identität).

Eine Identität ist dabei einfach ein eindeutiger String — hier die Namen "alice", "bob", "charlie". Ein deterministischer Hash-Algorithmus wandelt diesen String in ein Polynom um, das mathematisch in den Chiffretext eingebacken wird. Dadurch kann Charlie nachweisbar nicht Bobs Nachricht lesen, selbst wenn er seinen eigenen legitimen Schlüssel kennt — das wird in Schritt 6 live demonstriert.

KC-Setup: Trapdoor-Schlüsselpaar

Die gesamte Arithmetik findet im Polynomring $R_{q} = Z_{q} [X] / (X^{N} + 1)$ statt: ganzzahlige Polynome vom Grad < $N = 1024$ , deren Koeffizienten modulo $q = 12289$ gerechnet werden. Multiplikation wird modulo $X^{1024} + 1$ reduziert — das macht den Ring für gitterbasierte Kryptografie geeignet.

Der KC wählt zunächst ein uniformes Polynom $a_{0}$ — alle 1024 Koeffizienten gleichverteilt in $[0, 12289)$ . Das ist der öffentliche Referenzpunkt für alle Nutzer (Common Reference String). Dann zieht er ein kurzes Polynom $r$ mit Koeffizienten nur aus ${- 3, \dots, + 3}$ und berechnet $a_{1} = 1 - a_{0} \cdot r$ . Dadurch gilt die Trapdoor-Relation $a_{0} \cdot r + a_{1} = 1$ (das Einheitspolynom). $a_{0}$ und $a_{1}$ sind vollständig öffentlich — nur $r$ bleibt als Geheimnis auf dem Server.

Parameter: Demo vs. Paper

Diese Demo nutzt reduzierte Parameter für Browser-Kompatibilität. Die folgende Tabelle zeigt, wie ein produktives System laut dem zugrundeliegenden Forschungspaper aussehen würde.

↗ Zugrundeliegendes Paper (ePrint 2026/628)

Parameter	Demo (Browser)	Paper (Produktion)	Bedeutung
Ring-Modulus q	12 289 (14 Bit)	~2⁵⁹ (59-Bit-NTT-Primzahl)	Bestimmt den Rauschpuffer für homomorphe Operationen. Das Paper braucht fast 60 Bit, damit akkumulierte Fehler den Entschlüsselungsschwellwert nicht überschreiten.
Ring-Grad n_R	1024	256 / 512 / 1024	Grad des zyklotomischen Polynoms. n_R = 1024 entspricht dem Standard moderner gitterbasierter Kryptografie (Kyber, Dilithium) und bietet hohes Quantensicherheitsniveau.
Gadget-Basis d	2 (binär)	64	Zerlegungsbasis der Gadget-Matrix G. d = 64 statt d = 2 ist die Schlüsseloptimierung des Papers: kompaktere Chiffretexte, schnellere Entschlüsselung — auf Kosten schneller wachsenden Rauschens.
Gitter-Dimension n	1	4	Modul-Rang des Ring-LWE-Problems. Höheres n erhöht die Sicherheit gegen strukturelle Angriffe.
Gitter-Samples m	~14	236	Anzahl der LWE-Samples (ca. n · log q). Mehr Samples bedeuten stabilere Fehlertoleranz bei wachsender Nutzerzahl.
Identitätslänge l	8 Bit	50	Maximale Länge einer Nutzeridentität in Bits/Zeichen. l = 50 deckt die meisten Enterprise-Anwendungsfälle (IDs, kurze E-Mail-Adressen) ab.
Max. Nutzer N_max	3 (Alice, Bob, Charlie)	1 000 / 10 000	RBE ist ein Bounded-N-System: N_max wird beim Setup festgelegt und bestimmt die mpk-Größe. Für 1 000 Nutzer liegt der Chiffretext laut Paper bei ~0,148 MB.

⚠Demo-Parameter sind mathematisch korrekt, aber kryptografisch nicht sicher. Nicht für produktiven Einsatz verwenden.