I have an application where it would be advantageous for an attacker to have to spend a long time generating public keys.
To do this, I require that the hash of the public key be less than a certain number. That way a typical user will take 1 second to generate a public key, and an attacker who is trying to DOS public resources will also have to spend more resources to do so than it costs for us to detect.
There are two mechanisms proposed:
Take a public key, hash it many times with an incrementing salt, and require the result to be less than a certain number.
Generate a public key, hash it once, and if the result is not less than a certain number, add one to the private key and add the generator to the public key.
The first mechanism helps mitigate DOS and spam attacks. The second mechanism helps mitigate some MITM attacks as well.
I like the features of the second, except for some drawbacks:
- This reduces the number of valid public keys that exist, and could reduce search space for an attacker attempting in the process of brute forcing public keys. Since we're using a secure hash, it seems the DLP remains equally hard with or without this hash.
- This relies on the point addition algorithm being highly efficient, and assumes an attacker may not have some new and better way to perform this operation. But this is as opposed to assuming efficient hashing, an equal assumption?
- It's possible that an unprivileged attacker observing the initial POW generation could determine some information about the key. Not a huge deal since these keys are not frequently generated, but perhaps not.
Are there other things I should be thinking about? Is there a standard out there in the wild I haven't found?