# A PEKS-Based NDN Strategy for Name Privacy
## 6 Discussion  
As we introduced above, our main purpose is to protect the name privacy from outside attackers. We discuss and compare PEKS-based NDN with other two schemes: PrivICN [7] and ANDaNA [9] as shown in Table 2.  
* Unlinkability between ciphertexts
* Non-Usage of Master Secret Key
* Derivation of Secret Keys
* Assumption of Secure Secret-value Delivery and Management
* Trusted Party
* Name Lookup
* Fully supported cache ability on all routers in NDN network
* Var- True
* Var- False
* Unknown or unable to determine  
**Privacy:** As shown in Table 2, Unlinkability between ciphertexts (Un-L), Non-Usage of Master Secret Key (MK), Derivation of Secret Keys (DS), and Assumption of Secure Secret-value Delivery and Management (SD) are the issues relating to the privacy issues. We discuss these issues as follow:  
* Unlinkability between ciphertexts (Un-L): PrivICN uses proxy re-encryption which is done only at edge nodes and does not need to be done multiple times. The generation process of ciphertexts for the same name results in the same ciphertext because they are using a pseudorandom function, which is common to all consumers and producers instead of using a random value in the ElGamal \begin{table}
\begin{tabular}{c c c c c c c} \hline \hline
**Scheme** & **Un-L** & **MK** & **DS** & **SD** & **TP** & **NL** & **C** \\ \hline ANDaNA & – & ✓ & – & Setup & Exit-routers (fully) & fast & ✗ \\ PrivICN & ✗ & ✗ & ✗ & Period & KMS(fully), Proxy(semi) & fast & – \\ PEKS-based & ✓ & ✓ & ✓ & On-demand & Routers(semi) & slow & ✓ \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Comparison between PEKS-based NDN and other works. Figure 12: Average download time of Con1 vs cache hit ratio at router R4. encryption scheme. Because of this kind of pseudorandom function, their scheme does not guarantee the unlinkability between ciphertexts and consumers in the intermediate nodes, which are located between proxies. As a result, there remains a room for an attacker to link the packets' names with the consumers even though the names are encrypted. On the other hand, we use a random value \(r\), which makes the PEKS ciphertext more secure to protect the name in the packet. Assume that an attacker has public key of the producer, \(P_{pub}\), which is [g, \(h=g^{\alpha}\)], and the PEKS ciphertext as shown in Equation (5). \[[g^{r},H_{2}(t)]=[g^{r},e(H_{1}(N_{j}),h^{r})]=[g^{r},e(H_{1}(N_{j}),g^{ar})]\] (5) Because both \(\alpha\) and \(r\) are unknown to the attacker, it becomes difficult for him to get \(H_{1}(N_{j})\). It is proven in [22] that computing \(N_{j}\) is difficult under Bilinear Diffie-Hellman Assumption. Because of this property, PEKS_based NDN does not allow the attacker to link between ciphertexts. (b) Non-Usage of Master Secret Key (MK) and Derivation of Secret Keys (DS): PrivICN also uses a Key Management Server, which holds a master secret key \(X_{MK}\) for the whole domain. After proxy re-encryption, ciphertexts become as they are encrypted by using \(X_{MK}\). The usage of a single master secret key is not necessary in PEKS_based NDN. In PrivICN, each proxy key \(X_{proxy}\) is generated as \(X_{proxy}=X_{MK}-X_{client}\). One can figure out to get to know \(X_{proxy}\) and \(X_{client}\), e.g., collusion of a proxy and a client to derive \(X_{MK}\), which means that one can decrypt the ciphertexts of re-encryption. In PEKS_based NDN, there is no such kind of key generation and one cannot derive secret key. (c) Assumption of Secure Secret-value Delivery and Management (SD): However, it is necessary to disseminate trapdoors to the network. It is assumed that the dissemination of trapdoors is done securely and trapdoors are securely stored at routers. The assumption of secret value delivery is on-demand while PrivICN needs to deliver secret value periodically and ANDaNA only disseminates during the setup. Efficiency: The issues relating to efficiency such as Name Lookup (NL), and Fully supported cache ability on all routers in NDN network (C) are discussed follow:  
1.