# How does the sender obtain the receiver's public key?

Cryptography process includes encryption and decryption process. In public key cryptography public key of receiver is being used for encryption.

I want to know how public key of receiver is sent to sender?

• Normally there are CAs (certificate authorities) that function to provide ensurance that a certain public key genuinely belongs to a certain entity. The public keys of the CAs are assumed to be simply publically known (cf. the postal address of a newspaper). But that scheme obviously depends on the trustworthiness of the CAs involved. If there is un-intentional or intentional wrong work of a CA, the whole fails. There are other known common ways of transferring informations (here keys), but all naturally needs careful risk analysis, similar to transfers of other precious goods IMHO. – Mok-Kong Shen Sep 14 '16 at 10:45

The sender receives the public key through some other (secure) channel.

The whole security of public key encryption relies on precisely this "small detail": there must be a way for the sender to obtain the receiver's public key through some other, secure channel. The definition of "channel" is actually very broad here, and denotes simply a means of transferring information.

To name but a few real world examples of what can be used to exchange keys:

• A trusted key server or repository, e.g. OpenPGP public key servers like sks-keyservers.net.
• A file downloaded from a website which is trusted to belong to the person whose public key you wish to obtain, and the connection to this website is secure and properly authenticated (i.e. using HTTPS).
• The receiver sends the public key on the same channel as the one it intends to receive the message, but the key's authenticity can be verified by a trusted external party such as a PKI (Public Key Infrastructure).
• A USB stick, disk, piece of paper or some other type of media handed over in person.
• A telephone call (!).

Of course, one should nevertheless not forget that there is a myriad of attacks which can be performed on these channels too, such as using fake certificates issued by rogue CAs in order to bypass HTTPS or also flooding public keyservers with fake PGP keys. After all, a cryptographic protocol can only be as secure as the less secure of its parts.

• One could argue that a secure channel in the sense of confidential and authenticated is not strictly necessary. An authenticated channel should be sufficient. – Marc Ilunga Sep 25 '19 at 7:17

If there is no known information about the other side and there is no trusted third party (or any kind of chain of trust), then there is no encrypted comunication possible.

Cryptography always has to build upone something, it doesn't work without assumptions: You can't verify the other persons identity, you can't verify any claims, and you can't know if that public key doesn't actually belong to a man-in-the-middle.

The most common way to solve this is to say that all public values are just known to everyone. Alternatively, there is someone who actually publishes all the public value in some way, but then of course it has to be ensured somehow that no one can manipulate this. Much more complex, you assume a public key infrastructure, where you have one certificate authority at the root and then have a chain of trust leading all the way back to that root-CA. For that you need more than just encryption, because you need digital signatures to show the authenticity of certificates, and e.g. that the verification key of the root-CA is known to every participiant.

Although people could email you their public key, most people & organizations distribute their Public Keys by uploading them to keyservers enabling them to be searched and downloaded. OpenPGP's keyserver is great because it provides a predictable HTTPS path to grab public keys via script.

Here's a script I wrote to automate adding Public Keys to a GPG keyring using curl with OpenPGP's keyserver.

To adapt it, set variable PATHSCRIPTS and replace my (3) specimen key fingerprints in the Here-Doc with those of keys you wish to import into your keyring from https://keys.openpgp.org. Since HTTPS is allowed almost universally, should have no problems with firewalls grabbing keys with this method.

#!/bin/bash

# Create text file using a Here-Doc containing Key Fingerprints of keys to import into keyring:

cat <<EOF> $PATHSCRIPTS/Key-fingerprints-list.txt AEB042FFD73BAA7545EDA021343A2DF613C5E7F8 7AFAF20259E69236E43EEF521F45D0F6E89F27A6 704FCD2556C40AF8F2FBD8E2E5A1DE67F98FA66F EOF # Read the text file we created into an array readarray arrayKeyFingerprints <$PATHSCRIPTS/Key-fingerprints-list.txt

# Loop through the array adding each key in turn by its fingerprint from keys.openpgp.org:
for i in $${arrayKeyFingerprints[@]}; do curl https://keys.openpgp.org/vks/v1/by-fingerprint/$$i | gpg --import
done


Results of the above script- which was saved and executed as test.sh- shown below:

pi@pi4-ap1:~ \$ ./test.sh
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
100  3212  100  3212    0     0   7629      0 --:--:-- --:--:-- --:--:--  7629
gpg: /home/pi/.gnupg/trustdb.gpg: trustdb created
gpg: key 343A2DF613C5E7F8: public key "Terrence Houlahan (I'm the former NYPD cop living in the UK.  This is my only *personal* key.  Trust no others.) <terrence@houlahan.co.uk>" imported
gpg: Total number processed: 1
gpg:               imported: 1
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current