Safe way to sending a public key over a socket

Question

What is a safe way to send a RSA::PublicKey to another user over a socket? I was thinking to export the key into a ByteQueue and send the byte array to the user where he can construct the public key again.

Or does this leak information that can be misuse?

//Generate keys
AutoSeededRandomPool rng;

InvertibleRSAFunction params;
params.GenerateRandomWithKeySize(rng, 3072);

//Create
RSA::PublicKey publicKey(params);

//Save
ByteQueue queue;
publicKey.Save(queue);

byte publicKeyBuffer[1000];
size_t size = queue.Get((byte*)&publicKeyBuffer, sizeof(publicKeyBuffer));

//Load
RSA::PublicKey loadkey;
ByteQueue queue2;
queue2.Put2((byte *)&publicKeyBuffer, size, 0, true);

loadkey.Load(queue2);

Answer 1

What is a safe way to send a RSA::PublicKey to another user over a socket?

Yes, you can send it plain text if privacy is not a concern. The person receiving it will need to authenticate the public key, meaning they will need to ensure its your genuine key, and not an imposter's key.

Authenticating the public key is the key distribution problem, and its a wicked hard problem in cryptography. If the key distribution problem could be solved, then a lot of privacy issues go away.

There are two ways to attempt to solve the key distribution problem: root of trust and web of trust. Root of trust is used in PKI with public and private CAs; while web of trust is used by PGP and friends.

The key distribution is 'solved' with varying degrees of success on the Internet with PKI and Public CAs. See, for example, RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, on how its supposed to work; and see Peter Gutmann's Engineering Security on how it fails in practice (sometimes in spectacular fashion).

For peer to peer applications that don't use 'root of trust' or PKI, the latest trend is to (1) uses a Short Authentication String (SAS) with the initial message, and (2) tie all subsequent sessions to past sessions (essentially forming a chain from the first session). During the initial message, the receiver verifies the public key key from the sender using voice by reading back a small digest like a public key thumbprint (voice is a great authentication mechanism).

If your peer to peer application cannot use a SAS to verify the public key, then you should employ a Trust-On-First-Use (TOFU) strategy and practice key continuity. Gutmann goes into security diversification strategies in great detail in his book Engineering Security.

---

export the key into a ByteQueue and send the byte array

This is just a presentation level detail. You could encode it any way you like, including raw, hexadecimal, Base32, or Base64. The real threat is ensuring your peer received the public key you sent (as ntoskrnl pointed out).

---

Also note that privacy can be a concern, like folks who are dissidents in an oppressed country. Dissidents and oppressive regimes aren't the only use case, and it can be a concern for certification and accreditation (C&A) as well.

I once failed an audit in US Federal because I leaked an email address. In this case, the email address was in a user certificate along with the key. (All a certificate does is bind a public key to an identity via an "authority" signature over both).