I’m a coauthor of Ristretto.<p>There is a much more concise explanation than in the linked post: in Ristretto, the encoding of group elements was constructed so that the encoding of the identity (zero) element of the group is the all-zero byte string. So it’s not surprising that the all-zero byte string has a known private key: it’s the all-zero secret key.<p>This aspect of the encoding makes it very easy to check whether a provided group element is the identity element, because “zero means zero”.<p>What the questioner seems to be looking for is a way to generate “burn addresses”, public keys with the property that everyone can be sure that no one else knows the secret key to. This is actually kind of hard: if I just give you a public key, how do you know I didn’t generate it from a secret key I know?<p>The correct answer to this “nothing-up-my-sleeve” problem is to have a group-valued hash function, which Ristretto provides. Then public keys can be specified as the outputs of the hash function.
Another footgun is that Curve25519 has a cofactor of 8, which may reveal some information about your private key if some high-order points are used [1].<p>Some curves (eg: Ristretto) were designed to alleviate this problem.<p>[1] <a href="https://neilmadden.blog/2020/05/28/whats-the-curve25519-clamping-all-about/" rel="nofollow">https://neilmadden.blog/2020/05/28/whats-the-curve25519-clam...</a>
Wow. I'm not a cryptographer by any means, but have come into contact with asymmetric cryptography often enough to not do totally stupid things... But this response is really just complete and utter gibberish to me.
I wasn't aware of this issue and it's kind of interesting because two of my blockchain projects use address 0 as the token burn address (which would basically appear to mean that a hacker could steal all the tokens ever burned). I'm now thinking that this may have scared away some potential investors. But luckily, only one of my projects is based on elliptic curves and address 0 is locked explicitly in the code (no funds can ever be moved from that address, even if the private key is known) - I guess years of coding experience taught me to always be extra careful with such edge cases. My other project is based on Lamport OTS and Merkle Signature Trees so is not affected either. Still, the PR implications are a concern.
The choice of the identity element, if one can be encoded at all, gives you one point with known key by design. Choice of the generator, if it isn't NUMS, can give you a second arbitrary value with a known key-- this latter one could even be a no-one-but-us backdoor but a somewhat contrived one.<p>Like if you want to secretly know the private key of 0xDEADBEEF, set your generator to lift(0xDEADBEEF) x (1/$secret). Now the deadbeef pubkey has a DL relative to your generator of $secret.