Topic: In what ways might a basepoint be compromised? (Read 104 times)

maybe this can help.Superfast method for solve ECDLP but for specific privkeys
z =115481771728459905245102424859900657047113141323743738905491223467302634970004


like G^privkey

https://github.com/cysecud/ecc_weak_keys/issues/2

Hardly possible. But anything goes if not proved otherwise.
Here is some strange project: https://github.com/mrezaakbari/ECC
But I heard many times of it before like there exists some master key value to the curve.
Many ideas can be checked if one chooses a smaller curve with properties similar to secp256k1 like p and n both prime and p > n.

Thank you for the reply. it is making sense now. Even if I had knowledge of a relationship s * H = G ... Substituting d * (s*h)=Q and shuffling around still leaves you with Q' = d*H which is a ECDLP.

I have heard that the NIST standards that define G don't give any reason why... and some have said "Oh look at that... they might know something we dont!" But from what you are saying... There's really nothing to know.

Chatgpt is really frequently bad, this is an example of it.

Take any field element s on the finite field of the curve order P. Compute H = (1/s) *G.  Tada, you now have an "H" of the form in the example: s * H = G.  This doesn't have any security implication at all.  It's a relation easily computed for any element on the field of curve-order.

The choice of G doesn't have any security relevance in any ordinary usage.

It only has relevance in special and somewhat contrived usage.   E.g. I want to convince you that I don't know the discrete log of some point with respect to G.  So I do something like pick that point with sha256.  So you think "oh surely you can't know the discrete log of that, it was selected by a hash!" and that would be generally true unless G itself was generated based on this supposedly "nothing up my sleeve" point (causing the relationship between them to be known).   To avoid this risk any protocol that needs a nothing-up-my-sleeve point should construct it by using a hash that includes G, which proves (absent a hash collision) that G couldn't have been created as some multiple of the nums point.

If this isn't making much sense to you it's because there are relatively few reasons to have a nothing up my sleeve point, and none when it comes to ordinary bitcoin usage.  They're required in some zero knowledge proof setups.

This is a quote I found in this forum from gmaxwell


I couldn't find much literature on this so I asked chatGPT which explained to me (quite possibly incorrectly) that:

Under normal circumstances d * G = Q (where d is the private key, G is the basepoint, Q is the public key, '*' represents scalar multiplication.) But if you were aware of a deeper relationship, by design or otherwise, where s * H = G (s is a scalar in the range of 2-N, H is a valid point on the curve) This would allow you to solve any private key in the system instantly, no ECDLP required, because you can substitute in d * (s*H) = G and solve it algebraically.

So can someone tell me if this is correct or incorrect?

I have struggled for days trying to understand this. If someone could let me know, maybe even make a python example that uses an example basepoint with a hidden relationship to demonstrate how it would work. That would mean a lot to me and anyone else interested in the same thing.

Regardless of whether or not SECP256k1's basepoint was chosen with a hidden relationship in mind, those hidden relationships still exist theoretically right? It's just another interesting way of looking at ECDLP.

Thank you