Is there a key exchange protocol that requires only one message? Say I want to exchange a secret with someone, but I only get to send one message to the other person, and then we encrypt with that secret. Diffie-Hellman and ECDH require multiple messages to be sent back and forth to get a shared secret.
Is there a key exchange that requires just one message to be sent from one party securely? (I know that sending the key over plaintext works, but that isn't secure.)
(Define message as a packet over the internet or one SMS for example)
For forward secrecy without a synchronous handshake, you want something like the "ratcheting" protocol that Signal uses. It's a quite clever system, really:


Each party generates an asymmetric key pair, and gives the public key to anybody who wants it.
Each party generates and stores some number of [EC]DH parameters - one set for everybody you expect to need to talk to soon - then signs the public part of the parameters with the private key and makes the signed part publicly available too.


In Signal's case, the keys and signed public parameters are sent to the central server. Assuming you want to start a secure communication and either trust the server, have some way to verify the public key, or don't care about authentication, you can then do the following steps:


Download the recipients's key and their next, not-yet-used public key exchange parameters (the server and the recipient both track which parameters have been used).
Optionally, authenticate the key and verify the signature on the parameters.
Generate your own ephemeral set of key exchange parameters, and sign the public portion with your private key.
Use the private portion from your parameters and the public portion from the recipient's parameters to derive a symmetric key.
Optionally, encrypt a message with that key.
Send your public key, both sides' signed public key parameters, and the message all to the recipient.
Delete the ephemeral key parameters.


The recipient:


Looks up the pre-signed key exchange parameters, and verifies that the one of theirs just received had never been used before.
Optionally, verifies the sender's public key and the signature on their public key exchange parameter.
Retrieves their corresponding private portion of the key exchange parameters, and uses it plus the sender's public portion to re-derive the symmetric key.
Deletes the now-used private portion of the key exchange parameters, to ensure forward secrecy.
Decrypts the message, and/or encrypts one to send back, using the exchanged key.


For your scenario, if you can't have the central server, you'd need to retrieve the public key exchange parameter (and optionally public key to verify it) beforehand. However, you'd then be able to complete the key exchange and initiate secure communication, asynchronously, with one message... and (at least as soon as the recipient gets the message and completes the key exchange) it would be forward-secret.