// experimental demo

Registration-Based Encryption — Interactive Demo

This demo shows how Registration-Based Encryption (RBE) works — a lattice-based cryptosystem that models the Key Curator as a transparent, non-trusted party. All user operations run locally in the browser; KC operations run server-side — exactly as in a real deployment.

Experimental — in development

// what is rbe — and why no certificate?

In classical PKI, Alice must have a certificate signed by a Certificate Authority (CA). Bob must verify that certificate before he can write to Alice — the CA is a central trust anchor with far-reaching powers.

Registration-Based Encryption (RBE) takes a different approach: a Key Curator (KC) handles registration but knows not a single secret key. Each user generates their key pair locally on their device and submits only the public key to the KC. The KC adds all public keys into a single aggregated value mpkAgg — the sender needs only this one value and the recipient's name (their identity).

An identity is simply a unique string — here the names "alice", "bob", "charlie". A deterministic hash algorithm turns this string into a polynomial that is mathematically baked into the ciphertext. This means Charlie demonstrably cannot read Bob's message, even though he is a legitimate user with his own valid key — this is demonstrated live in step 6.

KC Setup: Trapdoor Key Pair

All arithmetic takes place in the polynomial ring $R_{q} = Z_{q} [X] / (X^{N} + 1)$ : integer polynomials of degree < $N = 1024$ , whose coefficients are computed modulo $q = 12289$ . Multiplication is reduced modulo $X^{1024} + 1$ — making the ring well-suited for lattice-based cryptography.

The KC first chooses a uniform polynomial $a_{0}$ — all 1024 coefficients uniformly distributed in $[0, 12289)$ . This is the public reference point for all users (Common Reference String). It then draws a short polynomial $r$ with coefficients only from ${- 3, \dots, + 3}$ and computes $a_{1} = 1 - a_{0} \cdot r$ . This yields the trapdoor relation $a_{0} \cdot r + a_{1} = 1$ (the unit polynomial). $a_{0}$ and $a_{1}$ are fully public — only $r$ remains secret on the server.

Parameters: Demo vs. Paper

This demo uses reduced parameters for browser compatibility. The table below shows what a production system would look like according to the underlying research paper.

↗ Underlying paper (ePrint 2026/628)

Parameter	Demo (Browser)	Paper (Production)	Meaning
Ring modulus q	12,289 (14 bit)	~2⁵⁹ (59-bit NTT prime)	Determines the noise budget for homomorphic operations. The paper requires nearly 60 bits so that accumulated errors never exceed the decryption threshold.
Ring degree n_R	1024	256 / 512 / 1024	Degree of the cyclotomic polynomial. n_R = 1024 matches the standard for modern lattice-based cryptography (Kyber, Dilithium) and provides a high quantum-security level.
Gadget base d	2 (binary)	64	Decomposition base of the gadget matrix G. d = 64 instead of d = 2 is the key optimisation in the paper: more compact ciphertexts and faster decryption — at the cost of faster noise growth.
Lattice dimension n	1	4	Module rank of the underlying Ring-LWE problem. Higher n increases security against structural attacks.
Lattice samples m	~14	236	Number of LWE samples (approx. n · log q). More samples provide more stable error tolerance as the number of users grows.
Identity length l	8 bits	50	Maximum length of a user identity in bits/characters. l = 50 covers most enterprise use cases (IDs, short email addresses).
Max. users N_max	3 (Alice, Bob, Charlie)	1,000 / 10,000	RBE is a bounded-N system: N_max is fixed at setup and determines the mpk size. For 1,000 users the paper reports a ciphertext size of ~0.148 MB.

⚠Demo parameters are mathematically correct but not cryptographically secure. Do not use in production.