Is using different public keys for different peers safer than reusing the public key, beyond forward secrecy? In X25519 (ECDH over Curve25519) Peer A and B exchange their Public Keys PkA and PkB and then calculate a shared-secret SecAB using cominationOf(SkA, PkB) == combinationOf(SkB, PkA).

For forward secrecy, I think it's recommended for A and B to re-negotiate a new shared-secret regularly (thus advertise new Public Keys).

Leaving that aside is there any other disadvantage if A uses the same Public Key that they have with everyone to get corresponding shared-secret VS if they use new Public Key with each new peer ?

In other words:


Peer A gives PkA to all, B, C, D ..., and as usual calculates shared-secret using PkB, PkC, PkD as SecAB, SecAC, SecAD and so on and uses those to encrypt/decrypt messages to the corresponding peers.
Peer A gives new Public Keys to each. So PkAB to B, PkAC to C, PkAD to D and so on. Then, just like before, calculate the shared-secret after using Public Keys of the corresponding peers as SecAB, SecAC, SecAD and so on.


Is 1. above less secure in context of how X25519 (and its maths) works than 2. ? Or is it just wasteful to do 2. and 1. is equally good ?
Generally for forward secrecy you should not just limit the use of the private key (and thus public key) in time, but also per connection. For that reason, you can assume that in most implementations that require forward secrecy that there will be one ephemeral key pair per connection, not per time frame.

Similarly, you're assuming that a new key pair is generated regularly, but please note that this kind of wording may be interpreted as once in a certain time frame. It makes a lot of difference how much the key is actually used within that particular time frame. So I think in your scheme you're using the private keys too much (you could tie that to forward secrecy, but you haven't made is explicit that you did see this tie to PFS).

One of the big disadvantages of your scheme is that the delivery of the public keys is required for each party. Some parties actually may not be active at all, and therefore distribution of the keys would be waste full. It also means that there must a central distribution point, which could wreak havoc in a distributed design.



Possibly you should simply exchange public keys each time you want to generate a new symmetric key, tying the validity of the private key to the symmetric key. How long you want to keep that symmetric key active is another matter. I'd say you could keep it active for a certain amount of actions within a specific time frame; having two rather than one limit for invalidating key pair and generating new ones. I'd certainly do that for each connection separately as indicated in the first section.