I'm designing a server which accepts anonymous messages using ECIES: as in, anonymous users send the server an ephemeral EC public key, and the server uses ECDH to derive a shared secret, and some KDF to obtain a shared symmetric key to decrypt the actual message. The problem is ECDH, which is among the fastest key exchange available, is really slow. From some quick tests, my computer can only handle about 3000 key exchanges per second.
An attacker could be constantly computing key exchanges and sending them to the server. I'm not too worried about this if the attacker has actually done the key exchanges. At least that way, the attacker will be doing as much work (slightly more with ECDH) as the server. The problem is an attacker can send a garbage key and make the server do a lot of work doing the key exchange on garbage. My first question is, in a reasonable implementation like OpenSSL, will the key exchange quickly return with an error, or take a long time doing useless computation?
Assuming the above is fixed, there are two more problems: an attacker could use the same ephemeral key over and over, keeping the shared secret but making the server do the key exchange repeatedly; and an attacker could precompute a lot of ephemeral keys beforehand and send them all at once.
One attempt at a solution to both problems is for the server to keep its own ephemeral keypair which changes every ~10 minutes. It can publish its ephemeral public key signed with its permanent private key. Then it would not be unreasonable for the server to remember the keys and corresponding secrets received during this period. However, this doesn't really solve the precomputation attack because correctly generated EC keys will still work with a key exchange, they just would produce garbage data. Is there any fast way for a server to know that a given key will actually decrypt the message?
Sorry for the long post, and thanks in advance to any comments.