# Privately Generated Key Pairs for Post Quantum Cryptography in a Distributed Network
## 2 Background Information
#### Relevant Prior Work  
[PERSON] et al. proposed a methodology of integrating PUFs as the source of seed for NIST-approved lattice, NTRU, and code-based cryptographic protocols. They used semiconductor devices as a PUF to create hardware fingerprints that replace random numbers for private/public key generation. In such a scheme, the server administrates the infrastructure and the user independently generates the key pair, which is strong as a two-way authentication [13]. [PERSON] et al. proposed a mechanism where a client device that is associated with a host device sends a public key and the associated certificate to the host device. Secure  
Figure 1: Key generation for PKI: (**a**) user-driven (**b**) third party-driven. storage associated with the client device stores the parent public key, private key, and certificate. The client device receives instructions from the host device to generate a new key pair, which is the child's private and public key. To ensure randomness and security, the child's private key is created based on the first random number produced within the secure device. Then, the client device computes the signature on the child's public key using the parent's private key stored in the secure device. Finally, the client device sends the child public key and the first signature to the host device, and the host device verifies the first signature [14]. [PERSON] et al. designed a system where a signer has an identity associated with a public key; the signer also holds two private keys: the first private key and the second private key. The second private key is stored securely with a reliable third party. When the signer wants to sign a message, they use the first private key to create a pre-signature of the message, and the signer then sends both the message and the pre-signature to the reliable third party. The reliable third party verifies the pre-signature using the signer's public key to ensure that it is valid and, upon successful verification, the third party uses the second signature to sign the final message [15]. [PERSON] used a token to generate a certificate request and send it to the CA. The request includes a public cryptographic key that is uniquely associated with the token. The CA generates a symmetric cryptographic key specifically for the token. The CA encrypts the symmetric key using the public key that was included in the token's certificate request. This ensures that only the token, which has the corresponding private key, can decrypt and access the symmetric key. The CA creates a digital certificate for the token and this digital certificate contains the encrypted symmetric key as one of its attributes. The CA sends the digital certificate back to the token. Upon receiving the digital certificate, the token uses its private key to decrypt the encrypted symmetric key and stores the decrypted key [16]. [PERSON] devised a mechanism where at the time of establishing secure communication between two parties, the first party selects an image that has been digitally signed by the second party. From the image, the first party extracts a portion, referred to as the first image portion. This portion contains an encoded part of the second party's digital signature. Figure 2: Key generation for Public Key Infrastructure as proposed in this paper. The second portion of the image, which is associated with the first portion of the image, contains an encoded part of the second party's digital signature. Both the first and second image portions contain encoded parts of the second party's digital signature. Using the second party's public key, the reconstructed digital signature is validated [17]. JNix devised a scheme where the server stores its private key, the device's public key, and the device's ephemeral public key. On the other hand, the client device stores the server's public key.