# IBE and friends --- ## Agenda - Key handling is hard for non-geeks - "Shamir's request" - Connections with ABE - Usecases and the catch - Boneh-Franklin - Cocks - Lattice alternatives - Eliminating the trusted PKG - Signatures - Hierarchy --- ## PKE UX dies at the first step ![pke](https://comodosslstore.com/blog/wp-content/uploads/2018/04/public-key-vs-private-key.png) --- ## Shamir's request _"In 1984 Shamir asked for a public key encryption scheme in which the public key can be an arbitrary string"_ - proceedings of Crypto 2001,volume 2139 of Lecture Notes in Computer Science --- ## Connections with ABE - The order of key-generation is reversed - Public keys are a collection (or one) arbitrary label(s) upon request - "All bus drivers with yellow hats can decrypt this message" - IBE is an ABE where the attributes restrict the receiver to an identity --- ## Common layout - Setup($\lambda$) -> (MSK, MPK) - Extract(MSK, id) -> iSK - Encrypt(id, msg) -> C - Decrypt(iSK, C) -> msg --- ## Usecases and the catch - Asymmetric broadcast encryption - Trivial forward secrecy `iSK = H(MPK || Bob || timestamp)` - Intuitive key delegation and revocation - .... even hierarchical But it needs a trusted thirdparty (ノಠ益ಠ)ノ彡┻━┻ --- ## Boneh-Franklin - IND-ID-CCA secure in the ROM using weil pairings - $\mathbb{G}_1, \mathbb{G}_2, G \in \mathbb{G}_1, e : \mathbb{G}_1 \times \mathbb{G}_1 \to \mathbb{G}_2$ given as usual - $MSK = s \xleftarrow{rand} \mathbb{Z}_p, MPK = sG$ - $iSK = sH_1("bob@evilcorp.com")$ - $C=\langle rP; M \otimes H_2(g_{ID})\rangle$ where $g_{ID} = e(H_1("bob@evilcorp.com"), MPK)$ --- ## Cocks - Alternative construction based on quadratic residues - Contra: works bit-by-bit --- ## Lattice alternatives - Highly parallelizable - Quantum-safe \o/ - Hierachy is easier to define (vectors) --- ## Boneh-Boyen-Agrawal - random lattice $A_0 \in \mathbb{Z}_q^{n \times m}$ and basis $T_{A_0}$ - random $A_1, B \in \mathbb{Z}_q^{n \times m}, u \in \mathbb{Z}_q^n$ - $MPK = (A_0, A_1, B, u), MSK = T_{A_0}$ - $iSK = TS(A_0 | A_1 + H("bob@evilcorp.com")B)$ where TS is a trapdoor sampler for "small" values --- ## Boney-Boyen-Agrawal - to encrypt, recalculate the ID from $F_{id} = A_0 | A_1 + H("bob@evilcorp.com")B$ - $R \xleftarrow{rand} \mathbb{Z}_q^{n \times m }, x, y \xleftarrow{rand} Z_q^n, z = Ry$ - $c_n = us + x + b \lfloor \frac{q}{2} \rfloor \in \mathbb{Z}_q$ - $r = F_{id}s + [y, z]^T$ - return (c_0, c_1, ... c_n, r) - Cipthertext is N + 2m where m is constant in the protocol --- ## The problem of the trusted PKG - Not all usecases of IBE require Non-repudiation... but p2p mostly does - Both boneh-franklin and BBA can be used in threshold setting. - Can we do any better? --- ## Registration based encryption - Key Generator is replaced with a Key **Curator** - Doesn't have secret keys, only maps identities - ... can be a smart contract - First construction used IO (Insdistinguisability Obfuscation) - More recent ones rely on standard (CDH, LWE) assumptions - **IBE can be trustless!** --- ## IBE implies signatures - Name the IBE master key as the signature privkey. - Name the IBE public params as the signature pubkey. - The signature on a message $M$ is the decryption key on a random message where $iSK = M$ - As long as the IBE is IND-ID-CCA secure this signature is unforgeable. --- ## Hierarchies - HIBE is constructed with vector identities - Add another PPT-algo (or generalize `Extract`) - $Derive(id, h \in \mathbb{Z_q}^{l_{-1}}) \to iSK \in \mathbb{Z_q}^{l}$ --- ## Thanks for the attention ![mail](http://www.concyteq.edu.mx/transparencia/imagenes/ZMC-EmailIcon.png =32x) silur@cryptall.co ![tg](https://upload.wikimedia.org/wikipedia/commons/thumb/9/9b/Telegram_Logo.webp/200px-Telegram_Logo.webp.png =32x) @Huohuli
{"metaMigratedAt":"2023-06-15T11:17:58.661Z","metaMigratedFrom":"Content","title":"IBE and friends","breaks":true,"contributors":"[{\"id\":\"f4d4af67-750e-4c99-b33e-c04b6d99a6c6\",\"add\":4051,\"del\":224}]"}
    284 views