Can't seem to find this info anywhere, please advise.
Lets say I have someones public PGP key and I want to communicate with that person via encryption. I need to send them my public PGP key for them to encrypt messages, right?
Should I send my key in an encrypted message using their key or is that redundant/impossible?
you sign the message with the key
>>370551
It's unnecessary.
There is no need to treat your public key as a secret, that's why it PUBLIC. You can distribute it freely all over the web, like many do, there are huge open public key databases.
All the publickey does is enabling people to encrypt a message so that only YOU can decrypt it again.
You can give it to him over an unsafe channel.
>>370573
So, do I just "split" my message into 2 parts?
1st part with my Public Key and the 2nd with the message encrypted with the recipients public key?
>>370573
>>370551
You're both missing the problem.
Public keys are public; they're not secret.
But how do you know that a public key that says it's Bob's public key actually is the counterpart of the private key Bob keeps?
How do you know it's not actually Eve's public key, and whenever you mail Bob, she's decrypting it, reading it, switching out any public keys and fingerprints you send into ones of hers, then reencrypting it with Bob's real public key?
This is the "key distribution problem", and it has no easy solution (if it did, we could just use that solution to distribute one-time pads). PGP/GPG addresses it by having a "web of trust": "this guy, who you've actually met, says that this guy says that this guy says that this guy has this key". HTTPS has certificates authorities: "this is Mr Verisign, and he's very trustworthy. He says that this guy has this key". Whatsapp, iMessage, etc. do it this way too, though they operate their own authority.
The safest approach is to exchange keys in person, or in a way that's infeasable to bug, for example by telephone and by IM simultaneously.
>>370573
It's helpful, because it means that if you've used the right key, then all they have to do is import your attachment and then they will be using the right key.
It reduces the opportunities to fuck up from two to one.
>>370590
That still doesn't change that it is irrelevant how his friend gets his public key, it is an inherent problem of cryptosystems.
To his friend it makes no difference if he gets the key on micofilm via carrier or on a postcard.
There is no way for the friend to know if it is actually his public key until getting it from a source he can be sure it's him. In person, telephone, via WhatsApp etc.
You could send your key encrypted in a message but for that you then have to be again sure that HIS key is really his, it's a loop...
>>370624
It's not a loop: if I send Linus Torvalds my PGP key, then he has near 100% certainty that replying with the key he's been sent means that no-one but the person that sent him the key will read it. This is because Linus's public key is one of the best-known in the entire world, and the chances of me fucking up and mailing him using a key that isn't his are essentially zero.
The issues of "the public key you're using belongs to the person you think you're talking to" and "the person you think you're taking to is the person he claims to be" are separate and unrelated. The second one is outwith the purview of public-key encryption, despite PGP leveraging it to try to solve the first one.
So long as you somehow solve the first issue for the matter of you talking to him, then sending your public key obviously solves the first issue for the matter of him talking to you.
I agree that sending your public key unencrypted is not the best idea.
1) Because of the attribution problem someone else has already mentioned. It's feasible that the encrypted message and the public key for the response message come from different persons. Cold-calling someone this shouldn't make much of a difference, but if the encrypted message contains some secret, you, as an adversary, could make the recipient believe that you know that secret and are therefore trustworthy even though you don't have any clue what was encrypted and have just attached your key in plain-text to the original message you intercepted. Even if you attach your public key in plain-text first, an intercepting adversary could substitute his own and then play man-in-the-middle (which admittedly is a larger problem that can happen in many other ways as well).
2) Because of the meta data problem. Often times the contents of the message are not as important as the information who is communicating. If you are a dissident and write a PGP encrypted message to the revolutionary army, your authoritarian government probably doesn't care what you wrote. *That* you wrote to the rebels is more than enough to pick you up and torture you. Sending your public key in plain-text offers another layer of attribution. Maybe the key is linked to your name? Maybe you use it for other business of yours? Maybe you use it to communicate with someone who isn't trustworthy and knows your real identity? Using a burner e-mail doesn't cover you if your public key stays the same.