Quote from: Valera909 on Today at 11:41:05 AM

Quote from: kTimesG on Today at 09:22:51 AM

Quote from: Valera909 on Today at 07:14:17 AM

Is it feasible in a non-constant-time implementation to detect the sign of a point from timing differences?

What are the main factors that could cause timing variations in these operations (coordinate inversion, branching, etc.)?

What best practices exist for measuring and exploiting such timing differences?

Are there known vulnerabilities or examples from popular libraries related to this?

There's no such thing as sign of a point. Points are pairs of coordinates.
There's no such thing as sign of a point's coordinate. Modular arithmetic doesn't have signs.
Best practices: don't run variable-time code if you don't want to expose everything your code computes, like any secret values. It's a critical vulnerability. If it's not required to be secure, use variable time code to gain more speed.
Known vulnerabilities: timing variations allow to completely retrieve the processed values.
Examples: a lot, OpenSSL had a while loop that ended prematurely. Some guy managed to retrieve private SSH keys remotely by timing server handshake responses.

Seems like people get more and more crazier directly proportional to the BTC price.

hanks so much for the detailed breakdown! 🙏

I’ve got a basic grasp of modular arithmetic, but initially interpreted the situation differently — like, the point −𝑃 −P kinda feels “greater” than 𝑃
P, especially when you look at it through the lens of inversion over the 𝑦 y-axis. 📉📈

Now here’s the spicy bit 🌶️:
If you start walking from − 𝑃 −P, incrementing the private key by 1 each time (i.e., checking for some 𝑘 k where 𝑘⋅𝐺=𝑃 k⋅G=P), you'll actually hit the point 𝑃 P relatively quickly — because they’re connected through the curve’s group order.
But if you go the other way — starting at 𝑃
P, trying to reach −𝑃
−P via +1 steps — you'll have to walk almost the entire group order. 🚶‍♂️🔁

That means direction matters, and that’s something we might be able to leverage. This method gives a hint about the sign or orientation of the point. 👀🧭

🤔 I'm wondering — are there any libs or implementations that let you determine which of two points is “closer to 0” or gives clues about their directional relationship?

💡 Also, are there any side channels we can sniff — like timing differences in signature verification, subtle quirks in point serialization, byte structure anomalies, or even differences when decompressing points — that could leak info about the point’s sign or help narrow the keyspace?

If there’s even the faintest trace of something like that — it’s a potential vulnerability. Would love to hear thoughts from anyone who’s dug deep into libsecp256k1 or forks. 🔬🔓

Again — massive thanks for the insights. Really appreciate the depth! 🚀🧠💥

for small curve we can trace which point is near to generator point, for curve with spaces 2^256 bits with current available tech and algo is impossible to define it.

https://imgur.com/a/pHzD18Y