# Comparison of Distributed Tamper-Proof Storage Methods for Public Key Infrastructures
## 6 Discussion  
The results presented in Section 5 indicate that modern distributed file-storage systems, based on the DLT, are viable candidates for replacing centralized filesystem public key stores. Some technologies, especially those which can be set up in a private configuration, are capable of executing transactions significantly faster than, e.g., their public counterparts. Therefore, some specific technologies may not be suitable for every desired use case due to a lack of required performance. In general, the performance numbers lead to the conclusion that the IPFS private setup is the most reliable and, in terms of performance, the most responsive solution for a high-performance system. Other implementation candidates on the IPFS basis have shown to be capable of being a proper alternative to the existing HLF NFC-KE extension because their performance numbers are either lower or equal to each other. Only the Sia Skynet solutions did not prove to be a valid replacement alternative for the HLF approach due to significantly higher execution times among all test scenarios. There are some additional points to the HLF performance results that need acknowledgement. First, the HLF implementaion requires a consensus among all participants to synchronize the underlying Blockchain state. Only after this process is complete, the stored data can be queried by external parties. Furthermore, HLF internally performs multiple cryptographical operations such as signing, verifying, and hashing transaction data, thereby increasing performance numbers. These points all add up to form the resulting performance of HLF. When discussing the real-world application potential of the presented DLTs for the use within PKIs, the level of decentralization needs to be considered as well. The private variants of the presented DLTs are generally less decentralized and autonomous than the public variants. This is due to the restricted access to the given network since a private DLT instance is mostly created by one single administrator and then spread to known clients within the network, e.g., a local data center or multiple office computers. Therefore, decentralization is a point to consider since these network clients are, again, connected within the same network and may be located geographically close to each other. Nevertheless, a network administrator may be able to geographically decentralize private  
Figure 6: NFC-KE Phase 2 execution time distribution-IPFS private-8 Peers. IPFS peers, e.g., by using different data centers or renting a virtual server. This would, in return, require a higher maintenance effort and would not scale dynamically because of a single authority needing to manage all peers simultaneously. Due to their public access nature, the public DLTs offer global access to the underlying network and, thus, allow for increased redundancy and outage resilience. There are also some points, that require attention when it comes to choosing a DLT for the PKI use case. DLT Platforms such as HLF or Ethereum [34] offer custom programmability and can be used as a decentralized, trusted execution environment that can enhance the trustworthiness of the given PKI. Each operation can be cryptographically signed and later verified by the DLT network. Enabling this distributed consensus renders the whole network more tamper-resistant and less prone to external intervention. In this particular case, the previously proposed NFC-KE extension using HLF used the integrated Smart Contract functionality to verify and store the exchanged public keys. This functionality had to be moved away from the DLT because the evaluated distributed file storages do not support a custom Smart Contract functionality, leaving the centralized Application Server the duty of verifying the received public keys. Therefore, the HLF approach offers increased security while not offering a true global decentralization or, in some cases, acceptable performance numbers.