# Quantum Key Distribution with Post-Processing Driven by Physical Unclonable Functions
## 3 Conclusions  
We have considered the distribution of a common secret key between two honest users of a QKD network, which is necessary for authentication and encryption purposes during the post-processing stage in the first pairwise QKD session. Such a key (usually referred to as a pre-shared key in the QKD literature), is necessary for any QKD system because it prevents a man-in-the-middle attack. We have discussed the generation and the distribution of pre-shared keys by means of PUFs. Each QKD device (sender or receiver) is associated with a disordered token/tag, which plays the role of a unique fingerprint and allows the users to generate nearly perfect random keys as well as to authenticate their devices. Two users can generate a common secret random key by locally interrogating their tokens with the same randomly chosen challenge. The main advantages offered by the proposed scheme are the following: (i) It does not require quantum communication. (ii) In contrast to PQC protocols, the distributed pre-shared keys are information-theoretically secure, which ensures the ITS character of the entire QKD session (see also related discussion in Section 1). (iii) There is no need for distributing additional secret keys or passwords to [PERSON] and [PERSON] to ensure the secrecy of the pre-shared key. (iv) There is no need to keep the database of CRPs private. Even if an adversary obtains access to the database, they cannot deduce the possible pre-shared keys, as discussed in Section 3. (v) By definition, a PUF is hard to clone, even if one has access to it, because its response to a particular challenge is very sensitive to the internal randomness of the token (tag), which also depends on the conditions of fabrication. (vi) There is no need to ensure the authenticity of the randomly chosen challenge that is used for the establishment of the pre-shared key, unless one wishes to prevent a DoS attack (see the related discussion in Section 3). All of these features make our scheme more attractive than other currently used methods, such as the inclusion of the pre-shared key in the software that accompanies the QKD boxes, its storage in password-protected devices, the use of a trusted courier, or the distribution by means of PQC. For two users, a single CRP suffices for establishing the necessary pre-shared key for the first QKD session, provided that the length of the key that can be generated from the PUF under consideration is at least equal to the length of the pre-shared key required by the used QKD system (see also the related discussion in Section 3). In other words, by employing the right type of PUF, the present protocol does not require more pre-shared keys (or equivalently challenges) than the number required by the current QKD systems. Of course, having more CRPs available in the database, in case something goes wrong, is an additional feature which is provided by our protocol and, to the best of our knowledge, it is not an option in the QKD systems that are available on the market today. Extending this reasoning to a case of \(n\) users with a trusted KDC, one can easily see that the number of challenges (entries) required by the present protocol are as many as the number of pre-shared keys required in the QKD network without PUFs. The additional entries that are provided by a PUF is a benefit that can be exploited by the users if needed. As discussed above, the inclusion of a trusted KDC is essential in large QKD networks (many users) in order to preserve the ITS character of QKD systems. Moreover, even for two users, a trusted intermediate node may operate as a relay, which allows the distribution of a secret key beyond the distances that can be covered by a direct QKD link. In other words, the trusted KDC is not a requirement that originates from our protocol, but rather it is a necessity which originates from the point-to-point character of QKD links, the limitations of the available QKD systems, and the absence of quantum repeaters.