However, for the practical application of the scheme, this leads to a problem. If we look at the public generator \(g_{1}\) and its use in the ciphertext element \(C_{1}\), we notice that if the discrete logarithm \(a\) of \(g_{1}\) to base \(g\) is known, it can function as a backdoor since any ciphertext could be decrypted by computing \(e(C_{1},\hat{g})^{1/a}=e(g_{1}^{r},\hat{g})^{1/a}=e(g^{ar},\hat{g})^{1/a}=K\). In the base scheme, \(g_{1}\) is chosen uniformly at random, which in practice could be achieved by hashing a nothing-up-my-sleeve value, e.g., digits of \(\pi\) or a fixed string into \(\mathbb{G}\). In contrast, in the transformed scheme, \(a\) is explicitly chosen in the setup method to compute \(g_{1}\) and \(\hat{g}_{1}\), which would pose a virtually insurmountable hurdle to establishing trust in the scheme in a practical instantiation. To tackle this issue, we propose an alternative transformation of the scheme that does not exhibit this design flaw in the following section. ## 4 Our PRE Scheme Design

In this section, we present our manual transformation of the base scheme to the Type 3 setting. The transformation fixes the identified design flaw of the automated transformation by preventing the duplication of generators to both source groups. This introduces the need for adjustments to the security proof, which can be found in Section 4.2. ### Manually Transformed Scheme

As in Section 3.2, differences to the base scheme are highlighted in gray (Algorithms 17-24). ```
1:Choose Type 3 bilinear groups \(\mathbb{G}_{1}\), \(\mathbb{G}_{T}\) of prime order \(p>2^{k}\)
2:\(g,u,v,w\)\(\mathbb{G}\)\(\mathbb{G}\)
3:\(\mathbb{G}_{1}\)\(\mathbb{G}_{2}\)
4:\(Z=e(g,\mathbb{G})\)
5:Choose a TCR hash function \(H\): \(\mathbb{G}_{2}\times\{0,1\}^{\ell}\rightarrow\mathbb{Z}_{p}^{*}\)
6:Choose a PRF \(F\): \(\mathbb{G}_{T}\times\mathbb{G}_{2}\rightarrow\{0,1\}^{\ell-\ell_{1}}\times\{ 0,1\}^{\ell_{1}}\)
7:return\(param=(p,\mathbb{G}_{1},\mathbb{G}_{2},\mathbb{G}_{T},g,u,v,w,\mathbb{G}, \mathbb{G},\mathbb{G},Z,H,F,\ell_{1},\ell)\)
```

**Algorithm 17** Setup(\(1^{k}\))

```
1:\(x_{i}\)\(\mathbb{G}\)\(\mathbb{Z}_{p}^{*}\)
2:\(pk_{i}=(pk_{i,1},\mathbb{G}_{2})=(g^{x_{i}},\mathbb{G})\)
3:\(sk_{i}=x_{i}\)
4:return\((pk_{i},sk_{i})\)
```

**Algorithm 18** KeyGen(\(k_{i}\), \(pk_{j}\))

```
1:\(rk_{i\to j}=\left|pk_{i,2}^{1/3}\right|=g^{x_{j}/x_{i}}\)
2:return\(rk_{i\to j}\)
```

**Algorithm 19** ReKeyGen(\(sk_{i}\), \(pk_{j}\))



### Transforming the Security Proof

The base scheme has been proven to be IND-2 PRE-CCA-secure and IND-1 PRE-CCA-secure. Given the analogous structure of the two proofs, the strategy for transforming the proofs to the Type 3 setting is applicable to both. In the manually transformed scheme, \(C_{1}\in\mathbb{G}_{1}\) is chosen from a different group than \(C_{2},C_{3},C_{4}\in\mathbb{G}_{2}\) and the generators are not duplicated to both source groups. This prevents the implicit transformation of the security proofs from the base scheme that would otherwise occur through the automated transformation. Consequently, we present the necessary adjustments for transforming the proof to the Type 3 setting. As indicated in Section 2.3, we replace the symmetric pairing-based assumption used by [PERSON] et al. in the base scheme with the 3-wDBDHI\({}_{3}\) assumption (Definition 1) in the security proof.