secp256k1

end result is usually that I go and read the changes that fix the vulnerability, if possible-- sometimes they're made somewhat surreptitiously and hard to disentangle from the other changes--; and convince myself that it really was the issue I understood it to be... and rest back on my prior constant time testing results and our design countermeasures to be confident that no similar issue exists. > One could choose just random hobby ECDSA implementations and list them as likely vulnerable, these are just a few that are worthy of listing because of their popularity. Fair enough. I think actually searching to see how many other projects have copied the vulnerable code might be a better proxy than stars, since there is no particular reason to click the star button if you're using a piece of code. Often end users will pick up vulnerable code via a popular program that links or embed it, and the bulk of users never directly see the repo for the crypto library. For years searching for "python eddsa" yielded an extremely vulnerable first result (including setting K to H(private key), using double and add, non-constant time infinity handling, etc.) that by all appearances was some random hobby project but because it was the first google hit, it actually got used in a fair number of places.