Well, as often when it comes to "practical security", the answer is: it depends.
First things first, there is nothing special about the keys or the way the maths in X25519 works that would make the one or the other more secure:
- publishing many public keys will not significantly ease the process of recovering any single secret key, although each new key decreases slightly the complexity of performing a brute-force against you.
That is: if we consider Curve25519 has a security level of 128 bits (arguably), the difficult of a bruteforce attempting to find just (any) one key out of $n$ keys is such that we still have an expected running time of $2^{128}$, which means it remains way too hard as long as
you don't have more than $2^{191}$ public keys out there... (Because then plain enumeration is faster than Pollard's Rho, but note this value is ridiculously big.) (Also, notice I'm assuming that
the SHA1 collision can be used as a reference to sets the maximum
bruteforce capability of an attacker at ~64 bits nowadays, which is
not really the case in practice for most attackers, but again, it
could depend... if the stakes were high enough, it might be possible
to reach $2^{65}$)
So theoretically, no problems in both cases. Which means it's a practical problem, so let's take a look around.
You already mention the forward secrecy, so leaving it aside, here are two reasons (there could be other, but nothing else comes to my mind at the moment) you might prefer to use individuals secret keys:
- anonymity: when you are relying on the same public key to speak to different peers, it is a sensible conclusion to assume that all these peers would easily agree they were talking to the same person. (Assuming no other authentication method has been used. But careful there, since unauthenticated Diffie-Hellman is prone to man-in-the-middle attacks). Whereas using different keys for different peers might provide better "segmentation" between the peers and would make correlation more difficult (notice other PI could be used, but that's not the question.)
- having different shared secret between two sessions: it is worth noticing (but it comes back to forward secrecy) that if you use the same fixed public key all the time, then whenever you're doing the
X25519 operation with someone that also uses the same public key as previously, you would always get the same shared value (before key-derivation, since the derivation could have introduced a variable that changed between now and the last time, depending on what you're including during key-derivation, obviously.) You might want to avoid this, for example, to avoid having problems after you've transmitted too much data, or depending on what you are doing with that shared secret.
Finally, let me come back to forward secrecy and to scheme 3 (which I explain now):
- whenever you initiate an
X25519 key exchange, you want to first generate a new key and then use that key. So if you speak twice to party A and once to B, you would be using three different keys, one for each time you speak to someone. This is the way ephemeral Diffie-Hellman (EDH) works, and it is the best way from the security point of view.
Overall, the consensus is that EDH is the best way to do things, mostly because it provides forward secrecy, but notice it is also super important to always authenticate things such as your public key, as EDH is also prone to man-in-the-middle attacks, just like DH.
(Notice X25519 in the end is just a regular Diffie-Hellman on a specific elliptic curve, with specific encodings and details, and as such, it can be both ephemeral or fixed. )
