attack on ECDSA using projective structural decomposition

I've been working on this for a few months, so please hang in there with me. It looks like there's a structural shortcut in ECDSA that I couldn’t find documented anywhere. So, while digging into the signature equation and thinking of it like a 2D rectangle sum equation one axis for the scalars and another for the x-coordinate I found a way to break down both axes in a bidirectional manner. Let’s say we expand this: s·k = r·d + r(k − d) + (s − r)d + (s − r)(k − d) If we cancel out r·d, we get a new representation that hasn’t been seen before: h = r(k − d) + (s − r)d + (s − r)(k − d) This shows h as a sum of three parts that are structurally independent, isolating the interactions between known signature values and the unknowns k and d. Visually, it’s like three rectangles being summed up through the differences of the products between the disjoint projective (log x) and scalar components of the equation (the ground truth). What’s really interesting is that this breakdown changes the dependency graph in a way that lets us reduce candidates iteratively. For any guess dᵢ, we can calculate: kᵢ = s⁻¹(r·dᵢ + h) mod n But with this 3-term breakdown, k − d shows up in two separate terms. So, if we guess d wrong, it creates correlated distortions across several parts instead of just a single scalar mismatch. From what I’ve seen, this implies that the solution space isn’t evenly flat; it actually has some structure that can be spotted when projected through this breakdown. So instead of just checking k through kG.x ≡ r, we might catch inconsistencies earlier by taking a closer look at the internal workings.

I thought this topic was interesting, so I did some digging. Knowing the number K does not reveal KG, this is because KG is a geometric point on a curve. The numbers do satisfy the modular equation, but ECDSA requires that K makes a curve point whose X-Coordinate equals R (https://csrc.nist.gov/pubs/fips/186-5/final, https://crypto.stackexchange.com/questions/67627/why-doesnt-the-formula-work-when-checking-two-ecdsa-signatures?utm_source=chatgpt.com). When we plug in your three-component equation it works (as it should be default), however the chance that you've actually guessed a private key is essentially zero. By essentially zero I mean that for real curves like secp256k1 (𝑛=2²⁵⁶), the probability is about 1/115,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000, rounded down, and in written form about one-hundred-fifty-septillion to one. To put simply your equation checks numbers using only normal arithmetic, whereas ECDSA also involves points on a curve. The extra geometric dimension in the equation makes it NEARLY impossible to break with this method (https://www.secg.org/sec1-v2.pdf, https://books.google.com/books/about/Guide_to_Elliptic_Curve_Cryptography.html?id=V5oACAAAQBAJ&utm). Best Regards, -Ryan MacQuarrie

Thanks for the detailed reply, really appreciate the references and the probability breakdown. I fully agree with your main point: without the EC relation (kG → R.x = r), any scalar-only check is usually insufficient, and the probability of randomly hitting a valid key would effectively be zero for secp256k1. What I was trying to explore is slightly orthogonal to that. Starting from the decomposition: h = r(k − d) + (s − r)d + (s − r)(k − d) this makes the interaction between k and d explicit across multiple coupled terms, rather than a single linear relation. Now, in the standard view: k = s⁻¹(r·d + h) mod n an incorrect guess for d simply maps to a different k, with no immediate scalar-level inconsistency. However, in the decomposed form, (k − d) appears in two separate terms, meaning that an incorrect d propagates into multiple components simultaneously. This raises the question of whether those deviations remain uniformly random, or whether they introduce detectable structure under certain constraints. One scenario that seems worth thinking about is deterministic nonce generation (RFC 6979). In that case, k is no longer uniformly random, but a function of (d, h). If we assume d lies in a constrained interval of size 2ⁿ, then k is effectively drawn from at most 2ⁿ possible values as well, rather than the full group order. That doesn’t break the scheme, of course, but it changes the shape of the search space: instead of arbitrary (d, k) pairs, we’re looking at a structured subset where k and d are functionally linked. In that context, the decomposition can be visualized as overlapping areas: Here, h is not a separate rectangle but the L-shaped region of (s·k) not covered by (r·d). When d is incorrect, both the horizontal (k − d) and vertical (s − r) offsets shift together. So the question becomes: in a constrained or deterministic setting, do these coupled offsets remain indistinguishable from random noise, or could they serve as a weak pre-filter before EC validation? So this “multi-term coupling” view must be considered in the context of structured nonce generation.