I have a one way communication from one device to another, which needs to be secure and there cannot be any feedback in the other direction. Now both sides happen to have ECC P-256 key pairs and they know public keys of each other. So, I thought it would be natural to use the shared secret which is already 256bit - suitable for AES256, in which sender can encrypt the message and receiver can decrypt it.
Note: By shared secret I mean the usual $x$ coordinate of multiplying public key of $A$ and private key of $B$, or public key of $B$ and private key of $A$ - which are the same. I am not referring to calculated secret that is based on some random value generated each session, that would require I believe two way communication, which is not possible in this settings.
Now I am wondering if this by itself is sufficient, maybe I am overthinking this but I see two issues:
Such derived key is not uniformly distributed
If the symmetric key gets compromised, it requires that at least one side changes its key pair, as opposed to having a key different for every session, so only data for one session would be compromised.
I thought about generating some pseudorandom sequence of bytes on the sender's side, adding it to the shared secret, then hashing it altogether and use the result as a symmetric key - using SHA-256 would again give exact size of key for AES256 (this should also address the issue 1.). Then the random sequence of bytes would be part of the message, so receiver could do the same.
Now is this secure? Is there better way to do this, within the one way communication constraint? Or maybe this all is unnecessary and just using the shared secret directly is enough?
The linked questions (duplicates) are talking about shared secret, but I don't see how they address the one way communication problem I have here. There is no issue in calculating the shared secret, and also it is no issue of how random is the shared key, it is more about whether keeping the symmetric key the same (based on shared secret) for every session, or whether to apply some additional processing to ensure it is different each session, and if so, how to do it safely.