Paper 2026/1062 Original: eprint.iacr.org/2026/1062 ↗

Pairing-Based Registered ABE for Boolean Formulas with a Linear-Size CRS

Abstract

Registered attribute-based encryption (ABE) is a generalization of ABE that replaces the central trusted key-issuer with an untrusted key curator. In registered (ciphertext-policy) ABE, users generate their own public keys and there is a transparent aggregation process that takes the public keys of the users together with their attributes and aggregates them into a short master public key that functions as the public key for a standard ABE scheme. A sequence of works has focused on improving the efficiency and expressivity of pairing-based registered ABE. Today, all constructions of pairing-based registered ABE rely on a structured common reference string (CRS) whose size scales with the total number of users in the system $N$. While the first pairing-based constructions needed a CRS of size $O(N^2)$, a recent line of work has shown how to reduce it to $N^{1 + o(1)}$ in the case of general policies (albeit with extremely large constant factors), and to $O(N)$ if we restrict the policy family to conjunctions and DNFs (earlier schemes could support general monotone Boolean formulas) and if we analyze security in the generic group model (earlier schemes could be proven secure in the plain model). In this work, we give the first pairing-based registered ABE scheme with a linear-size CRS that supports general policies (i.e., monotone span programs which include monotone Boolean formulas as well as threshold policies). We can show static security based on a $q$-type assumption in the plain model and adaptive security if we instead work in the random oracle model. Our scheme is also the first pairing-based construction where users can be identified by arbitrary strings (e.g., identities) rather than by integers from a polynomial-size range. This directly enables registered ABE with stateless key-generation. Namely, users in our system can sample their key independently of the current state of the system. Previous approaches require users either to first retrieve the current state of the system before they could generate their key or to generate multiple public keys to avoid collisions.