Is Elliptic Curve Diffie-Hellman (ECDH) still secure if I use the public key more than one time? Elliptic Curve Diffie-Hellman (ECDH) with

Public parameters: Ep (a,b) and G  = (x, y)
Private Keys: Na, Nb
Public Key: Pa = Na x G, Pb = Nb x G
Secret key: k = Na x Pb = Nb x Pa  

Is the algorithm still secure if public key Pb is used more than once with different private keys Nb? Or are there any requirements to use use a public key more than once in a secure way?
Is the algorithm still secure if public key Pb is used more than once? Or are there any requirements to use use a public key more than once in a secure way?


I'll amend the question to what I think you mean ("is ECDH secure if we reuse our private value across multiple exchanges"), and answer it, "yes, it can be done securely, but (under some scenarios) you MUST perform validity checking on the value you receive from the peer".

The biggest thing you need to check is "is the value you receive a point on the curve?".  After all, you take the values $x_b, y_b$ that you received, and plug them into the EC point multiplication routine, and perform a series of point additions/doublings.  These routines generally assume the point they're given is already on the curve; if not, they'll assume a curve that the point is on.  That is, you are performing the operations on a curve which may be $y^2 = x^3 + ax + c'$, for a $c'$ that the attacker selected.  The attacker can select such a curve to have an order with a small factor $r$, give you a point of order $r$, and so the shared secret would be one of $r$ values (and which one would indicate the value $N_a \bmod r$.  By doing this several times with different curves (and different values of $r$), he can deduce the value $N_a$.

Now, one variant of ECDH is for both sides exchange only the $x$ values (and have the shared secret depend only on $x$); this largely avoids this problem (but not entirely, unless you have a curve with "twist security"), and is done by (for example) Curve25519 .  However, it is not universal; sometimes you are implementing an existing protocol that insists on exchanging $x, y$ values.

If you must exchange both $x$ and $y$ values, the fix is actually pretty easy: just plug the values you receive into the curve equation and see if it satifies it; that is, if $y_b^2 = x_b^3 + ax_b + c$; if not, abort the key exchange.

There is also a second (far less serious) issue; suppose that you receive a public value that's a valid point on the curve (and so passes the above check), is not the point at infinity (you do check for that, don't you?), but isn't in the prime order subgroup that $G$ is in.  We normally do ECDH in a curve of order $hq$, where $h$ is a small integer, and $q$ is a large prime (and is the order of $G$).  By giving us a point that's in the larger curve, the attacker can potentially learn $N_a \bmod h$.  This isn't nearly as serious (as the attacker can't try different values of $h$), however it is still a leakage.

Things we can do about this:


Use a prime order curve; that is, one where $h=1$.  In that case, the attacker learns nothing (as any point on the curve he gives us is also within the subgroup)
Do "cofactor DH" instead; this modifies the secret derivation to $k = (hN_a)P_b = (hN_b)P_a$; by including $h$ in the final computation, this attack would give the attacker the value $hN_a \bmod h$, but that's always 0, independent of what $N_a$ is.  Of course, this may not be an option if you're implementing an existing protocol.
Verify that $qN_b = 0$ (that point at infinity); this works, but this is a fairly expensive computation; no cheaper than selecting a fresh ECDH private value each time.
Just live with it; even if $h&gt;1$, it is typically a small value, such as 4 or 8; giving the attacker a few bits of the private value doesn't help him that much