Is it safe to use shared secret as a symmetric key in one way communication?

Question

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:

1. Such derived key is not uniformly distributed

2. 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.

Answer 1

Consider a device A and a device B. Let me paraphrase what I believed you just said.

Communication happens only from A to B. We have public keys $PK_A$, $PK_B$, and the private keys $PrK_A$, $PrK_B$.

Devices A and B apply the Diffie-Hellman key exchange protocol to obtain a shared secret, $SS$. You say that it is logical to use $SS$ as a key for AES symmetric cryptography. It is sensible that the shared secret obtained from the DH protocol is used to derive symmetric keys from.

You say that the shared secrets derived from DH are not uniformly distributed. This is indeed the case. Hashing the obtained shared secret will solve this, as any different shared secret will produce a vastly different digest. $K_{AB} = H(SS)$

Let $r$ denote a random number. You propose $H(SS|r)$ (appending pseudorandom numbers, then hashing it) but this is will not result in a differently distributed digest space than omitting the $r$. You'll have to communicate $r$ to $B$ as well so there is no security gain but only a costs increase.

You also said that in the case of $K_{AB}$ being compromised, at least one of the devices must change its key pair. To my understanding this is not true. A new Diffie-Hellman key exchange can take place with different domain parameters, since the private keys of A and B are not compromised in this scenario.