Let's say I have an encrypted message. I want to make it so that someone is able to decrypt it. The only way of giving it to them is online. For the purposes of this question, I can't call, mail or meet them in person.
I want to ensure that only they are able to decrypt it. I know that the method of communication (whatever you want it to be) isn't monitored yet, but the message could be read at any time. How would I do this?
The answer to your situation, presented as it is, is that it is impossible unless you make certain assumptions.
You have two problems you need to resolve for this to work. For this example, I will use Alice and Bob as examples.
You need to have Alice and Bob exchange keys in a secure fashion. This is the easy problem. Any key exchange method like Diffie-Hellman or RSA will do.
Alice needs to know that she is performing the key exchange with Bob. This is the difficult problem which is impossible to achieve under your scenario without making some assumptions. Let's explore some of the options we have.
Bob publishes a public key that Alice will use to encrypt the encryption key with. However, how would Alice know that this public key belongs to Bob? Historically, there are two ways to accomplish this.
X.509 certificates. The X.590 standard is a centralized trust model where you have to rely on a Certificate Authority to verify Bob's identity. Alice has to trust the Certificate Authority that this particular public key belongs to Bob and not a malicious attacker. This is the model used in TLS/SSL.
PGP/GnuPU. PGP uses a decentralized trust model commonly referred to as the Web of Trust. This works by having many different users sign Bob's public key, essentially endorsing that the particular public key belongs to Bob. In this model, Alice has to trust that only the real Bob is able to garner enough endorsements from users.
I know that your question assumes that there isn't an out-of-band means for Alice to verify Bob's identity. In the hopes of making this answer more comprehensive though, I'll cover this situation a little bit as well. If Alice can meet Bob even once, the situation gets a lot easier. Alice and Bob can simply exchange public keys through a medium like USB drives and use the public keys to encrypt further communications.
Essentially, what you are asking after is a Public-key Infrastructure. As usual, do not reinvent the wheel outside of academic purposes. Use either TLS/SSL or PGP/GnuPG in practice.
You can use any key exchange protocols. Most probably Diffie–Hellman key exchange is used to exchange keys over internet.
In order to know that you are giving the encryption key to the right person, you'll need to work out some form of authentication that tells you the receiver is who you think they are.
This can often be done with PKI - the receiver can signup with a certificate provider, verify his credentials, get a signed certificate and send you his certificate. The certificate will include a public key, which (if configured correctly) can be used as an assymetric encryption key. Encrypt the symmetric encryption key with the receiver's public key and send it to him. He can then use his private key to decrypt it. As the only person who holds this private key, he's the only person who can get the encryption key for your message.
The limitation here is that your point of trust (the PKI certificate provider) is only as good as the authentication mechanism. If your colleague lives in an igloo in the North Pole and can't have any contact with humans, his means of authentication will be limited to the stuff he has with him in the igloo - presumably his Internet connection and his wallet. He may be able to send a scan of a driver's license or passport, or physical copy of his signature. He may know some information about himself that only he could know. That will qualify him for a low-end sort of PKI (I believe, for example, you can get a certificate from GoDaddy under these conditions). Other forms of certificate provisioning may require appearing in person to a qualified agent who will verify that you look like your passport, and that other means of verification are approved. That works fine for a regular situation where you and your colleague may not be able to talk out of band, but your colleague isn't necessarily in an igloo.
Protocols like TLS can also work - it's using a handshake with a key exchange that allows secure communication between two points - the only challenge is knowing for certain that you have made a TLS connection to the recipient and not a man in the middle.
Sounds like you could use the Transport Layer Security (TLS) protocol which is resistant to any eavesdropper listening to the channel. Just get the other party to send you his/her certificate and let TLS take care of the rest.
Using unilateral authentication with the other party (lets say Bob) acting as the server should suffice for your scenario. If the other party doesn't have access to the corresponding private key of the certificate, then he wont be able to decrypt the pre-master key (sent by you, encrypted with the certificate's public key) and the TLS handshake will fail. If you choose to make use of Diffie-Hellman (DH) in the TLS handshake, then it offers perfect forward secrecy - your past communications are still secure even if someone somehow discovered Bob's private key.
However, you still need some sort of authentication mechanism to ensure that the certificate indeed belongs to the Bob and not someone else's. Thus, Bob cannot use a self-signed certificate. He will need to register his certificate with a certificate authority which ideally will verify his identity for you.
The ability to do this hinges on being able to verify the subject's identity through the communications you make. It is possible to use a key exchange protocol to ensure that each end point of a communication is the only one to have a shared key, however you then need a way to verify that there isn't a man in the middle that has a connection open to both Adam and Bob.
In theory, you could combine the response to the challenge with the session key that is agreed upon between the two parties and hash that. Exchanging the hash would theoretically verify that the connection is correct so long as the key exchange derives the shared key based on information determined by both parties (ie, the attacker can't force both A and Bs sessions to use the same key) and the hash can't be easily reversed. The attacker would never know the actual answer to respond to the challenge, so they would not be able to create the hash for the second leg of the communication.
Note that there may be other cryptographic weaknesses here and there are lots of potential issues that could be run in to, however that's the only way I can think of to even approach solving your issue as stated. If you don't have any pre-shared response that can authenticate the person's identity however, then you are out of luck.
I would use the free email certificates available from, for example, comodo.com. Both parties need to get and install the cert in their email client. You can then encrypt the email to the specific sender once he/she has sent you a digitally signed email. That authenticates to the email address. If you cannot trust the email address then you have some of the problems described in the other solutions and I cannot help you. The encrypted message could be sent as an attachment or placed somewhere else on the web that is accessible to both parties. As described in other solutions, this uses PKI built around email address authentication. You are trusting the email client and the certificate generator to authenticate the other party for you because they authenticate the email address by sending an email requiring a response.
You say you want to make sure that your friend is the only person who gets the key, but you didn't provide any way to determine who he is. You say you can't call or meet in person, but his in-person identity is the only way you know him. You want to communicate with him online only, but you don't know who he is online.
If you have some pre-arranged shared secret handshake, secret knock, secret password, or other identifying characteristic, then that can be leveraged online to lead to identification. But as-is, your friend bears on distinction from anyone else. Indeed, how would he even know that you're contacting him if you can't coordinate with him?
This whole prospect is a non-starter.
