Bitcoin Forum
January 29, 2026, 09:02:59 AM *
News: Community awards 2025
 
   Home   Help Search Login Register More  
Pages: « 1 [2] 3 »  All
  Print  
Author Topic: Legendre Symbol Oracle Breaks ECC  (Read 385 times)
kTimesG
Full Member
***
Offline Offline

Activity: 728
Merit: 222


View Profile
January 26, 2026, 07:00:32 PM
 #21

So many things.

Like, why are you saying that G is not arbitrarily chosen? It doesn't have any distinctive properties. Any point can be chosen as G, it would not change the group structure at all, nor its arithmetic.

Scalars are basically a counter relative to "hey, let's count from this element forward", so I don't see how one can ever define a decision tree that doesn't depend strictly on the chosen G.

Endomorphism and GLV are not attacks - they allow some arithmetic shortcuts, but then again, these are agnostic to whichever G is chosen.

In short, for whatever pair of points you choose, the "scalar" relationship between them can fly all over the 2**256 domain, because that relationship only exists because an arbitrary G was chosen. In fact, you can always find some G, such that any two arbitrary points are sequential, or doubles, or whatever. This says nothing about the ECDLP itself.

Off the grid, training pigeons to broadcast signed messages.
rdenkye (OP)
Jr. Member
*
Offline Offline

Activity: 39
Merit: 1


View Profile
January 26, 2026, 07:06:02 PM
 #22

So many things.

Like, why are you saying that G is not arbitrarily chosen? It doesn't have any distinctive properties. Any point can be chosen as G, it would not change the group structure at all, nor its arithmetic.

Scalars are basically a counter relative to "hey, let's count from this element forward", so I don't see how one can ever define a decision tree that doesn't depend strictly on the chosen G.

Endomorphism and GLV are not attacks - they allow some arithmetic shortcuts, but then again, these are agnostic to whichever G is chosen.

In short, for whatever pair of points you choose, the "scalar" relationship between them can fly all over the 2**256 domain, because that relationship only exists because an arbitrary G was chosen. In fact, you can always find some G, such that any two arbitrary points are sequential, or doubles, or whatever. This says nothing about the ECDLP itself.

I can only solve it using the smallest x value. That's all it can explain for now.
rdenkye (OP)
Jr. Member
*
Offline Offline

Activity: 39
Merit: 1


View Profile
January 26, 2026, 07:07:41 PM
 #23


But for reference: the next curve y² = x³ + 7 with prime order is p=127, n=127, G=(1,32). Go ahead and show us the oracle for that one.

...

Your p=79 result is curve-fitting, not cryptanalysis.

Next week when I drop the p=127 oracle, you'll probably say "curve-fitting, not cryptanalysis" again.
But in the meantime, no one will crack it Smiley
Come on everyone, let's have some fun!
rdenkye (OP)
Jr. Member
*
Offline Offline

Activity: 39
Merit: 1


View Profile
January 26, 2026, 07:22:12 PM
 #24


I can only solve it using the smallest x value. That's all it can explain for now.

In curves where the standard base point is not the one with the smallest X coordinate;
We compute the target point using the point with the smallest X. Let's call it k1.
We compute the standard base point using the point with the smallest X. Let's call it k2.
By multiplying k1 by the inverse of k2, I calculate the point's scalar relative to the standard base point.

For Secp256k1;
G is used in the calculation:: (1,29896722852569046015560700294576055776214335159245303116488692907525646231534)
Standart G: (55066263022277343669578718895168534326250603453777594175500187360389116729240,32670510020758816978083085130507043184471273380659243275938904335757337482424)
gmaxwell
Moderator
Legendary
*
expert
Online Online

Activity: 4634
Merit: 10359



View Profile WWW
January 26, 2026, 08:33:32 PM
 #25

the security relies on the fixed G and the hardness of ECDLP from that base.
This is just pure jibberish in a group without cofactor, as you can take a problem for from one base and transfer it to any other.  They're all secure or none are secure.

This whole thread is equivalent to saying that it's secure if you have an oracle that can tell you bits of the private key.  True, but not a useful fact. In fact that's what the Legendre symbol is, just getting obscured with terminology.  So it just all sounds like the raving of someone with an AI addiction.

If someone can compute non-trivial properties of the private key from their image in the group then almost all of them translates pretty directly into a break and only with special exception do they not (like being able to identify (-x)G==-(xG)).  But the thing to actually establish there in order to be interesting is the ability to do so on a real cryptographic group, not a toy insecure group.  The fact that being able to do so would translate into a break isn't news.

As an aside, if anyone gets any private offers from the account to sell you his solution please let me know--  scammers pretending cryptographic breakthroughs then ripping people off or giving people malware is a repetitive theme on this forum though these days the LLM delusional are more common.
rdenkye (OP)
Jr. Member
*
Offline Offline

Activity: 39
Merit: 1


View Profile
January 26, 2026, 08:56:56 PM
 #26

the security relies on the fixed G and the hardness of ECDLP from that base.
This is just pure jibberish in a group without cofactor, as you can take a problem for from one base and transfer it to any other.  They're all secure or none are secure.

This whole thread is equivalent to saying that it's secure if you have an oracle that can tell you bits of the private key.  True, but not a useful fact. In fact that's what the Legendre symbol is, just getting obscured with terminology.  So it just all sounds like the raving of someone with an AI addiction.

If someone can compute non-trivial properties of the private key from their image in the group then almost all of them translates pretty directly into a break and only with special exception do they not (like being able to identify (-x)G==-(xG)).  But the thing to actually establish there in order to be interesting is the ability to do so on a real cryptographic group, not a toy insecure group.  The fact that being able to do so would translate into a break isn't news.

As an aside, if anyone gets any private offers from the account to sell you his solution please let me know--  scammers pretending cryptographic breakthroughs then ripping people off or giving people malware is a repetitive theme on this forum though these days the LLM delusional are more common.

Your warnings are very sensible and necessary. Nevertheless, I am quite disappointed.
kTimesG
Full Member
***
Offline Offline

Activity: 728
Merit: 222


View Profile
January 26, 2026, 09:24:49 PM
 #27

For Secp256k1;
G is used in the calculation:: (1,29896722852569046015560700294576055776214335159245303116488692907525646231534)

Here's a target point with a 104-bit scalar (relative to your X=1 generator) on secp256k1.

Code:
x = 0xa07f435a9492de13f58845301a81e5544c2648acaf59c9ba6786783dec5ba433
y = 0xbec7ec664d064f084bab48f48019e00c51ebcee4d34d330b0cc54f01cb3cc0f2

Since you claim to break 130 bits in 1.2 seconds or so, I assume recovering the correct private key (relative to your special generator) should be done in nanoseconds or so.

I don't have any special need for you to tell me the key, since I know it already, so it's enough if you simply post the SHA256 of the correct private key.

Off the grid, training pigeons to broadcast signed messages.
rdenkye (OP)
Jr. Member
*
Offline Offline

Activity: 39
Merit: 1


View Profile
January 26, 2026, 09:47:46 PM
 #28

For Secp256k1;
G is used in the calculation:: (1,29896722852569046015560700294576055776214335159245303116488692907525646231534)

Here's a target point with a 104-bit scalar (relative to your X=1 generator) on secp256k1.

Code:
x = 0xa07f435a9492de13f58845301a81e5544c2648acaf59c9ba6786783dec5ba433
y = 0xbec7ec664d064f084bab48f48019e00c51ebcee4d34d330b0cc54f01cb3cc0f2

Since you claim to break 130 bits in 1.2 seconds or so, I assume recovering the correct private key (relative to your special generator) should be done in nanoseconds or so.

I don't have any special need for you to tell me the key, since I know it already, so it's enough if you simply post the SHA256 of the correct private key.

I couldn't find the key. LLM was deceiving me, or they were saying "don't click on the link". The point wasn't really about proof, but I'm giving up anyway.
JackMazzoni
Jr. Member
*
Offline Offline

Activity: 188
Merit: 6


View Profile
January 27, 2026, 01:17:23 AM
 #29

The Oracle only deals with the x coordinate which is already displayed not directly with the K. It is useless.

Need Wallet Recovery? PM ME. 100% SAFE
rdenkye (OP)
Jr. Member
*
Offline Offline

Activity: 39
Merit: 1


View Profile
January 27, 2026, 08:13:58 AM
 #30

The Oracle only deals with the x coordinate which is already displayed not directly with the K. It is useless.

Yes. It doesn't work.
ThewsyRum
Newbie
*
Offline Offline

Activity: 13
Merit: 1


View Profile
January 27, 2026, 05:13:11 PM
 #31

How do you propose generating this decision tree for secp256k1? To find the constants that correctly separate the points of this curve, you would need to "train" your tree with the data. But how do you train a model on a space of 2^256 points that you cannot enumerate? Can you generate this decision tree on a real curve without iterating over all the points? Because if you need to iterate to build the tree, your attack is slower than brute force.

You have simply created a rule that works only because the dataset is tiny enough to be manually classified. If a direct and simple correlation existed between the coordinates and the most significant bit of the scalar k that was independent of group size, wouldn't ECC have been broken decades ago? Why does this supposed correlation vanish into statistical noise the moment we move from toy curves to real ones?
rdenkye (OP)
Jr. Member
*
Offline Offline

Activity: 39
Merit: 1


View Profile
January 28, 2026, 05:12:59 AM
 #32

How do you propose generating this decision tree for secp256k1? To find the constants that correctly separate the points of this curve, you would need to "train" your tree with the data. But how do you train a model on a space of 2^256 points that you cannot enumerate? Can you generate this decision tree on a real curve without iterating over all the points? Because if you need to iterate to build the tree, your attack is slower than brute force.

You have simply created a rule that works only because the dataset is tiny enough to be manually classified. If a direct and simple correlation existed between the coordinates and the most significant bit of the scalar k that was independent of group size, wouldn't ECC have been broken decades ago? Why does this supposed correlation vanish into statistical noise the moment we move from toy curves to real ones?


The tree was just one example.
It's impossible for me to go into detail right now, but I'll step up the pace over time.

Everyone seems convinced that the only way forward is for the x’s to collide like in Pollard's Kangaroo yet far fewer believe the x’s could simply sit down, talk it through, and resolve things without any collision at all. Let’s try to be a little more constructive.

Meanwhile, everyone is anxiously awaiting the quantum catastrophe from advancing Shor's algorithm. While we're all waiting for Shor... shall we say 'short from the x’s'?
kTimesG
Full Member
***
Offline Offline

Activity: 728
Merit: 222


View Profile
January 28, 2026, 12:48:48 PM
Merited by stwenhao (1)
 #33

far fewer believe the x’s could simply sit down, talk it through, and resolve things without any collision at all. Let’s try to be a little more constructive.

Probably because if that would be the case, it would break several proved theorems, like Fermat's or Lagrange's. The X values are simply element identifiers, or tags, or colors, they have zero correlation to any cycle reindexing, which is always relative.

Off the grid, training pigeons to broadcast signed messages.
rdenkye (OP)
Jr. Member
*
Offline Offline

Activity: 39
Merit: 1


View Profile
January 28, 2026, 02:17:41 PM
 #34

far fewer believe the x’s could simply sit down, talk it through, and resolve things without any collision at all. Let’s try to be a little more constructive.

Probably because if that would be the case, it would break several proved theorems, like Fermat's or Lagrange's. The X values are simply element identifiers, or tags, or colors, they have zero correlation to any cycle reindexing, which is always relative.


If the coordinates were just labels, they wouldn't form a rectangle with their siblings and cousins, in my opinion.
Sibling points with the same y value  those sharing cube roots  their sum goes to the curve's order.
With symmetries, 6 points form a rectangle.
And as an unexplored possibility... could a special comparison between a point's position in the rectangle and its half-point's position in its own rectangle reveal another feature that goes beyond mere labeling?
I'm already upset with Fermat anyway, no problem.
ActiveC
Copper Member
Newbie
*
Offline Offline

Activity: 4
Merit: 2


View Profile
January 28, 2026, 02:27:57 PM
 #35

This is not working on secp256k1. Do not waste time on this, it is useless.

Since the topic title like this is misleading, please change it!
rdenkye (OP)
Jr. Member
*
Offline Offline

Activity: 39
Merit: 1


View Profile
January 28, 2026, 02:39:12 PM
 #36

On the secp256k1 field prime p, if you set a = 1, not every b value produces a valid elliptic curve. Some b values make the curve singular. Singular means the curve stops being a proper elliptic curve and becomes a degenerate shape; in that case, standard elliptic-curve operations like point addition are not reliable, and the group structure does not hold.

Therefore, when working with a = 1, you should detect and exclude the b values that make the curve singular beforehand. That is exactly what the code I shared does: it computes and lists the singular b values for a = 1 over the secp field (typically there are two, and they are negatives of each other modulo p).


Code:

#secp256k1 alanında (p) “singular” b değerlerini (Δ=0) tek satırda bulmak
#y² = x³ + x + b mod p için Δ=0 (singular) koşulundan b köklerini çıkarma (secp256k1 p)
#Elliptic curve singularity check: finding b such that 4a³+27b²≡0 (mod p) on secp256k1 field prime

from sympy import mod_inverse, sqrt_mod
p = 115792089237316195423570985008687907853269984665640564039457584007908834671663
a = 1
target = -4 * pow(a, 3, p) * mod_inverse(27, p) % p
roots = sqrt_mod(target, p, all_roots=True)
print(roots)

Code:
[11842912595111486228085625214058158124919313799234703649739607102117954628595,
 103949176642204709195485359794629749728350670866405860389717976905790880043068]



11842912595111486228085625214058158124919313799234703649739607102117954628595, 103949176642204709195485359794629749728350670866405860389717976905790880043068

I couldn’t find these specific numbers anywhere, so I’m leaving a note here for future reference in some explanations I plan to write. I will also add the scalar values that cause the anomaly on the secp256k1 field prime p, i.e., the cases where p equals n. That will probably be a first as well.
rdenkye (OP)
Jr. Member
*
Offline Offline

Activity: 39
Merit: 1


View Profile
January 28, 2026, 02:40:59 PM
 #37

This is not working on secp256k1. Do not waste time on this, it is useless.

Since the topic title like this is misleading, please change it!

Yes, I tried it too, it didn't work.
kTimesG
Full Member
***
Offline Offline

Activity: 728
Merit: 222


View Profile
January 28, 2026, 04:10:32 PM
Last edit: January 28, 2026, 04:20:46 PM by kTimesG
 #38

If the coordinates were just labels, they wouldn't form a rectangle with their siblings and cousins, in my opinion.

Yes, they would. Group elements only have one property: they are uniquely distinct one from another. So you might as well use emojis/fruits/colors for each of them, and you'll have six emojis/fruits/colors in each family (because the emoji group structure guarantees such a behavior).

However, this says absolutely nothing about any indexing, traversal counter, or any relative repeated additions ("multiplication", "discrete logarithm", etc).

You're confusing the fact that points have actual integer coordinates with those values having any significance or bit leakage whatsoever from the scalar (actual indexing) domain, and even more absurdly, when relative to some whatever emoji/fruit/color. This correlation cannot logically exist.

Consider this: you can simply redefine all the elements in secp256k1 by adding the value 1 to the X coordinate. You'll end up with exactly the same group, same math, and same scalars, just different X values (but, those are the same points as before!). So, how can you possibly extract any useful scalar leakage from this "permuted representation of points" belonging to the exact same group, and same cycle order, you were already working with? You'll have to start subtracting 1 from X and redo your math, but what the hell is the logic behind this? If it does exist, then why should you not starting subtracting some random fixed number right now? Maybe 42 works! Try it.

And yes, the Legendre Symbol applied to some whatever emoji/fruit/color will have a single useful property as well: it will quickly tell you if a given emoji is really in the group or not, not leak out scalars.

Off the grid, training pigeons to broadcast signed messages.
rdenkye (OP)
Jr. Member
*
Offline Offline

Activity: 39
Merit: 1


View Profile
January 28, 2026, 04:22:23 PM
Last edit: January 28, 2026, 05:03:13 PM by rdenkye
 #39

If the coordinates were just labels, they wouldn't form a rectangle with their siblings and cousins, in my opinion.

Yes, they would. Group elements only have one property: they are uniquely distinct one from another. So you might as well use emojis/fruits/colors for each of them, and you'll have six emojis/fruits/colors in each family (because the emoji group structure guarantees such a behavior).

However, this says absolutely nothing about any indexing, traversal counter, or any relative repeated additions ("multiplication", "discrete logarithm", etc).

You're confusing the fact that points have actual integer coordinates with those values having any significance or bit leakage whatsoever from the scalar (actual indexing) domain, and even more absurdly, when relative to some whatever emoji/fruit/color. This correlation cannot logically exist.

Consider this: you can simply redefine all the elements in secp256k1 by adding the value 1 to the X coordinate. You'll end up with exactly the same group, same math, and same scalars, just different X values (but, those are the same points as before!). So, how can you possibly extract any useful scalar leakage from this "permuted representation of points" belonging to the exact same group, and same cycle order, you were already working with? You'll have to start subtracting 1 from X and redo your math, but what the hell is the logic behind this? If it does exist, then why should you not starting subtracting some random fixed number right now? Maybe 42 works! Try it.

And yes, the Legendre Symbol applied to some whatever emoji/fruit/color will have a single useful property as well: it will quickly tell you if a given emoji is really in the group or not, not leak out scalars.

If the opposite of what you're saying were known, we wouldn't be discussing this right now. By the way, there are cousins' children too. The related point is, not 6, but 16.
There are 10 more. 4 + 6 = 10
step-siblings. I'll explain the technical details at the first opportunity.

Actually, this isn't very relevant to the topic, so it's not an addition to the defense. I'm not adding this as a counter-argument, but since the subject came up, I'm including it because I might need to refer to it again in the future.


There are 2 points.
They have the same y-values.
Let the difference between the 2 points be "k".
These 2 points and their symmetrical counterparts, i.e., 4 points, are related by "k". I'm adding examples here;

This is a common feature in all curves, including secp256k1. For those unfamiliar, I'm adding an example from the p=79 a=1 b=7 curve for simplicity.

Code:

from ecdsa import ellipticcurve
import math


p = 79
n = 67
a = 0
b = 7
Gx =1
Gy = 18
lamda_scalar1 = 29
lamda_scalar2 = 37

curve = ellipticcurve.CurveFp(p, a, b)
G = ellipticcurve.Point(curve, Gx, Gy)


def ShortNumber(num):
    num_str = str(num)
    if len(num_str) > 15:
        return f"{num_str[:4]}...{num_str[-4:]}"
    return num_str


INFTY = ellipticcurve.INFINITY

def _same_point(P, Q):
    if P is INFTY and Q is INFTY:
        return True
    if P is INFTY or Q is INFTY:
        return False
    return (P.x() == Q.x()) and (P.y() == Q.y())

def GetKey(P, max_k=None):
    if P == 0 or P is None:
        return 0
    if max_k is None:
        max_k = n
    if max_k > 5000:
        return 0
    for k in range(1, max_k):
        if _same_point(k * G, P):
            return k
    return 0


def point_div(P, divisor):
    try:
        inv = pow(divisor, -1, n)
    except ValueError:
        return 0
    return inv * P


def powlevel(n: int) -> int:
    if n < 0:
        raise ValueError("n >= 0 olmalı")
    if n == 0:
        return 0
    return math.ceil(math.log2(n + 1)) - 1

 

def modinv(a): return pow(a, -1, n)

def getpoint(priv,isTopLevel):
    priv2= (priv * lamda_scalar1) % n
    priv3= (priv * lamda_scalar2) % n
    Q = priv * G
    Q2 = priv2 * G
    Q3 = priv3 * G
    QL=  point_div(Q,2**powlevel(priv))
    QL2=  point_div(Q,powlevel(priv))

    keyQL  = GetKey(QL)  
    keyQL2 = GetKey(QL2)  

    Q_neg = ellipticcurve.Point(curve, Q.x(), (p - Q.y()) % p)
    inv_term1 = modinv((1 - lamda_scalar1) % n)
    inv_term2 = modinv((1 - lamda_scalar2) % n)

    A = inv_term1 * Q
    C = inv_term2 * Q
    B = A + Q_neg
    D = C + Q_neg
    f1= (priv3-priv2) % n
    f2= (priv-priv3) % n
    f3= (priv2-priv) % n
    f4= (priv2-priv3) % n
    f5= (priv3-priv) % n
    f6= (priv-priv2) % n


    print(
          f"P1:{ShortNumber(priv):<2} - ({ShortNumber(Q.x()):2},{ShortNumber(Q.y()):2});{'':<2} "
          f"P2:{ShortNumber(priv2):<2} - ({ShortNumber(Q2.x()):2},{ShortNumber(Q2.y()):2});{'':<2} "
          f"P3:{ShortNumber(priv3):<2} - ({ShortNumber(Q3.x()):2},{ShortNumber(Q3.y()):2});{'':<2} "

          f"A:{ShortNumber(priv*inv_term1 % n):<2}: ({ShortNumber(A.x()):2},{ShortNumber(A.y()):2}){'':<2} "
          f"B:{ShortNumber(priv*(inv_term1-1) % n):<2}: ({ShortNumber(B.x()):2},{ShortNumber(B.y()):2}){'':<2} "
          f"C:{ShortNumber(priv*inv_term2 % n):<2}: ({ShortNumber(C.x()):2},{ShortNumber(C.y()):2}){'':<2} "
          f"D:{ShortNumber(priv*(inv_term2-1) % n):<2}: ({ShortNumber(D.x()):2},{ShortNumber(D.y()):2}){'':<2}"
          f"Diff: ({ShortNumber(f1):<3},{ShortNumber(f2):<3},{ShortNumber(f3):<3},{ShortNumber(f4):<3},{ShortNumber(f5):<3},{ShortNumber(f6):<3}){'':<2} "
    

          )
    
    if isTopLevel and 0==1:
        t1= getpoint(Q.x(),False)
        t2= getpoint(Q2.x(),False)
        t3=getpoint(Q3.x(),False)
        #print((t2+t3) % n)
        print("\n")
    return priv*(inv_term1-1) % n


# Başlık Satırı
print(f"{'P1':<18} {'P2':<18} {'P3':<18} {'A':<15} {'B':<15} {'C':<15} {'D':<14} {'Diff':<12}")
print("-" * 210)

# Döngü
for f in range(1, n):
    getpoint(f,True)



Code:
P1                 P2                 P3                 A               B               C               D              Diff        
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
P1:1  - (1 ,18);   P2:29 - (23,18);   P3:37 - (55,18);   A:55: (12,32)   B:54: (39,32)   C:13: (39,47)   D:12: (12,47)  Diff: (8  ,31 ,28 ,59 ,36 ,39 )  
P1:2  - (60,10);   P2:58 - (37,10);   P3:7  - (61,10);   A:43: (66,38)   B:41: (17,38)   C:26: (17,41)   D:24: (66,41)  Diff: (16 ,62 ,56 ,51 ,5  ,11 )  
P1:3  - (15,8 );   P2:20 - (29,8 );   P3:44 - (35,8 );   A:31: (41,35)   B:28: (74,35)   C:39: (74,44)   D:36: (41,44)  Diff: (24 ,26 ,17 ,43 ,41 ,50 )  
P1:4  - (49,5 );   P2:49 - (21,5 );   P3:14 - (9 ,5 );   A:19: (68,63)   B:15: (63,63)   C:52: (63,16)   D:48: (68,16)  Diff: (32 ,57 ,45 ,35 ,10 ,22 )  
P1:5  - (42,54);   P2:11 - (18,54);   P3:51 - (19,54);   A:7 : (61,10)   B:2 : (60,10)   C:65: (60,69)   D:60: (61,69)  Diff: (40 ,21 ,6  ,27 ,46 ,61 )  
P1:6  - (59,12);   P2:40 - (14,12);   P3:21 - (6 ,12);   A:62: (42,25)   B:56: (18,25)   C:11: (18,54)   D:5 : (42,54)  Diff: (48 ,52 ,34 ,19 ,15 ,33 )  
P1:7  - (61,10);   P2:2  - (60,10);   P3:58 - (37,10);   A:50: (75,38)   B:43: (66,38)   C:24: (66,41)   D:17: (75,41)  Diff: (56 ,16 ,62 ,11 ,51 ,5  )  
P1:8  - (43,35);   P2:31 - (41,35);   P3:28 - (74,35);   A:38: (23,61)   B:30: (55,61)   C:37: (55,18)   D:29: (23,18)  Diff: (64 ,47 ,23 ,3  ,20 ,44 )  
P1:9  - (37,69);   P2:60 - (61,69);   P3:65 - (60,69);   A:26: (17,41)   B:17: (75,41)   C:50: (75,38)   D:41: (17,38)  Diff: (5  ,11 ,51 ,62 ,56 ,16 )  
P1:10 - (26,19);   P2:22 - (45,19);   P3:35 - (8 ,19);   A:14: (9 ,5 )   B:4 : (49,5 )   C:63: (49,74)   D:53: (9 ,74)  Diff: (13 ,42 ,12 ,54 ,25 ,55 )  
P1:11 - (18,54);   P2:51 - (19,54);   P3:5  - (42,54);   A:2 : (60,10)   B:58: (37,10)   C:9 : (37,69)   D:65: (60,69)  Diff: (21 ,6  ,40 ,46 ,61 ,27 )  
P1:12 - (12,47);   P2:13 - (39,47);   P3:42 - (28,47);   A:57: (26,60)   B:45: (45,60)   C:22: (45,19)   D:10: (26,19)  Diff: (29 ,37 ,1  ,38 ,30 ,66 )  
P1:13 - (39,47);   P2:42 - (28,47);   P3:12 - (12,47);   A:45: (45,60)   B:32: (8 ,60)   C:35: (8 ,19)   D:22: (45,19)  Diff: (37 ,1  ,29 ,30 ,66 ,38 )  
P1:14 - (9 ,5 );   P2:4  - (49,5 );   P3:49 - (21,5 );   A:33: (27,63)   B:19: (68,63)   C:48: (68,16)   D:34: (27,16)  Diff: (45 ,32 ,57 ,22 ,35 ,10 )  
P1:15 - (63,63);   P2:33 - (27,63);   P3:19 - (68,63);   A:21: (6 ,12)   B:6 : (59,12)   C:61: (59,67)   D:46: (6 ,67)  Diff: (53 ,63 ,18 ,14 ,4  ,49 )  
P1:16 - (19,25);   P2:62 - (42,25);   P3:56 - (18,25);   A:9 : (37,69)   B:60: (61,69)   C:7 : (61,10)   D:58: (37,10)  Diff: (61 ,27 ,46 ,6  ,40 ,21 )  
P1:17 - (75,41);   P2:24 - (66,41);   P3:26 - (17,41);   A:64: (15,71)   B:47: (29,71)   C:20: (29,8 )   D:3 : (15,8 )  Diff: (2  ,58 ,7  ,65 ,9  ,60 )  
P1:18 - (21,74);   P2:53 - (9 ,74);   P3:63 - (49,74);   A:52: (63,16)   B:34: (27,16)   C:33: (27,63)   D:15: (63,63)  Diff: (10 ,22 ,35 ,57 ,45 ,32 )  
P1:19 - (68,63);   P2:15 - (63,63);   P3:33 - (27,63);   A:40: (14,12)   B:21: (6 ,12)   C:46: (6 ,67)   D:27: (14,67)  Diff: (18 ,53 ,63 ,49 ,14 ,4  )  
P1:20 - (29,8 );   P2:44 - (35,8 );   P3:3  - (15,8 );   A:28: (74,35)   B:8 : (43,35)   C:59: (43,44)   D:39: (74,44)  Diff: (26 ,17 ,24 ,41 ,50 ,43 )  
P1:21 - (6 ,12);   P2:6  - (59,12);   P3:40 - (14,12);   A:16: (19,25)   B:62: (42,25)   C:5 : (42,54)   D:51: (19,54)  Diff: (34 ,48 ,52 ,33 ,19 ,15 )  
P1:22 - (45,19);   P2:35 - (8 ,19);   P3:10 - (26,19);   A:4 : (49,5 )   B:49: (21,5 )   C:18: (21,74)   D:63: (49,74)  Diff: (42 ,12 ,13 ,25 ,55 ,54 )  
P1:23 - (35,71);   P2:64 - (15,71);   P3:47 - (29,71);   A:59: (43,44)   B:36: (41,44)   C:31: (41,35)   D:8 : (43,35)  Diff: (50 ,43 ,41 ,17 ,24 ,26 )  
P1:24 - (66,41);   P2:26 - (17,41);   P3:17 - (75,41);   A:47: (29,71)   B:23: (35,71)   C:44: (35,8 )   D:20: (29,8 )  Diff: (58 ,7  ,2  ,9  ,60 ,65 )  
P1:25 - (28,32);   P2:55 - (12,32);   P3:54 - (39,32);   A:35: (8 ,19)   B:10: (26,19)   C:57: (26,60)   D:32: (8 ,60)  Diff: (66 ,38 ,30 ,1  ,29 ,37 )  
P1:26 - (17,41);   P2:17 - (75,41);   P3:24 - (66,41);   A:23: (35,71)   B:64: (15,71)   C:3 : (15,8 )   D:44: (35,8 )  Diff: (7  ,2  ,58 ,60 ,65 ,9  )  
P1:27 - (14,67);   P2:46 - (6 ,67);   P3:61 - (59,67);   A:11: (18,54)   B:51: (19,54)   C:16: (19,25)   D:56: (18,25)  Diff: (15 ,33 ,19 ,52 ,34 ,48 )  
P1:28 - (74,35);   P2:8  - (43,35);   P3:31 - (41,35);   A:66: (1 ,61)   B:38: (23,61)   C:29: (23,18)   D:1 : (1 ,18)  Diff: (23 ,64 ,47 ,44 ,3  ,20 )  
P1:29 - (23,18);   P2:37 - (55,18);   P3:1  - (1 ,18);   A:54: (39,32)   B:25: (28,32)   C:42: (28,47)   D:13: (39,47)  Diff: (31 ,28 ,8  ,36 ,39 ,59 )  
P1:30 - (55,61);   P2:66 - (1 ,61);   P3:38 - (23,61);   A:42: (28,47)   B:12: (12,47)   C:55: (12,32)   D:25: (28,32)  Diff: (39 ,59 ,36 ,28 ,8  ,31 )  
P1:31 - (41,35);   P2:28 - (74,35);   P3:8  - (43,35);   A:30: (55,61)   B:66: (1 ,61)   C:1 : (1 ,18)   D:37: (55,18)  Diff: (47 ,23 ,64 ,20 ,44 ,3  )  
P1:32 - (8 ,60);   P2:57 - (26,60);   P3:45 - (45,60);   A:18: (21,74)   B:53: (9 ,74)   C:14: (9 ,5 )   D:49: (21,5 )  Diff: (55 ,54 ,25 ,12 ,13 ,42 )  
P1:33 - (27,63);   P2:19 - (68,63);   P3:15 - (63,63);   A:6 : (59,12)   B:40: (14,12)   C:27: (14,67)   D:61: (59,67)  Diff: (63 ,18 ,53 ,4  ,49 ,14 )  
P1:34 - (27,16);   P2:48 - (68,16);   P3:52 - (63,16);   A:61: (59,67)   B:27: (14,67)   C:40: (14,12)   D:6 : (59,12)  Diff: (4  ,49 ,14 ,63 ,18 ,53 )  
P1:35 - (8 ,19);   P2:10 - (26,19);   P3:22 - (45,19);   A:49: (21,5 )   B:14: (9 ,5 )   C:53: (9 ,74)   D:18: (21,74)  Diff: (12 ,13 ,42 ,55 ,54 ,25 )  
P1:36 - (41,44);   P2:39 - (74,44);   P3:59 - (43,44);   A:37: (55,18)   B:1 : (1 ,18)   C:66: (1 ,61)   D:30: (55,61)  Diff: (20 ,44 ,3  ,47 ,23 ,64 )  
P1:37 - (55,18);   P2:1  - (1 ,18);   P3:29 - (23,18);   A:25: (28,32)   B:55: (12,32)   C:12: (12,47)   D:42: (28,47)  Diff: (28 ,8  ,31 ,39 ,59 ,36 )  
P1:38 - (23,61);   P2:30 - (55,61);   P3:66 - (1 ,61);   A:13: (39,47)   B:42: (28,47)   C:25: (28,32)   D:54: (39,32)  Diff: (36 ,39 ,59 ,31 ,28 ,8  )  
P1:39 - (74,44);   P2:59 - (43,44);   P3:36 - (41,44);   A:1 : (1 ,18)   B:29: (23,18)   C:38: (23,61)   D:66: (1 ,61)  Diff: (44 ,3  ,20 ,23 ,64 ,47 )  
P1:40 - (14,12);   P2:21 - (6 ,12);   P3:6  - (59,12);   A:56: (18,25)   B:16: (19,25)   C:51: (19,54)   D:11: (18,54)  Diff: (52 ,34 ,48 ,15 ,33 ,19 )  
P1:41 - (17,38);   P2:50 - (75,38);   P3:43 - (66,38);   A:44: (35,8 )   B:3 : (15,8 )   C:64: (15,71)   D:23: (35,71)  Diff: (60 ,65 ,9  ,7  ,2  ,58 )  
P1:42 - (28,47);   P2:12 - (12,47);   P3:13 - (39,47);   A:32: (8 ,60)   B:57: (26,60)   C:10: (26,19)   D:35: (8 ,19)  Diff: (1  ,29 ,37 ,66 ,38 ,30 )  
P1:43 - (66,38);   P2:41 - (17,38);   P3:50 - (75,38);   A:20: (29,8 )   B:44: (35,8 )   C:23: (35,71)   D:47: (29,71)  Diff: (9  ,60 ,65 ,58 ,7  ,2  )  
P1:44 - (35,8 );   P2:3  - (15,8 );   P3:20 - (29,8 );   A:8 : (43,35)   B:31: (41,35)   C:36: (41,44)   D:59: (43,44)  Diff: (17 ,24 ,26 ,50 ,43 ,41 )  
P1:45 - (45,60);   P2:32 - (8 ,60);   P3:57 - (26,60);   A:63: (49,74)   B:18: (21,74)   C:49: (21,5 )   D:4 : (49,5 )  Diff: (25 ,55 ,54 ,42 ,12 ,13 )  
P1:46 - (6 ,67);   P2:61 - (59,67);   P3:27 - (14,67);   A:51: (19,54)   B:5 : (42,54)   C:62: (42,25)   D:16: (19,25)  Diff: (33 ,19 ,15 ,34 ,48 ,52 )  
P1:47 - (29,71);   P2:23 - (35,71);   P3:64 - (15,71);   A:39: (74,44)   B:59: (43,44)   C:8 : (43,35)   D:28: (74,35)  Diff: (41 ,50 ,43 ,26 ,17 ,24 )  
P1:48 - (68,16);   P2:52 - (63,16);   P3:34 - (27,16);   A:27: (14,67)   B:46: (6 ,67)   C:21: (6 ,12)   D:40: (14,12)  Diff: (49 ,14 ,4  ,18 ,53 ,63 )  
P1:49 - (21,5 );   P2:14 - (9 ,5 );   P3:4  - (49,5 );   A:15: (63,63)   B:33: (27,63)   C:34: (27,16)   D:52: (63,16)  Diff: (57 ,45 ,32 ,10 ,22 ,35 )  
P1:50 - (75,38);   P2:43 - (66,38);   P3:41 - (17,38);   A:3 : (15,8 )   B:20: (29,8 )   C:47: (29,71)   D:64: (15,71)  Diff: (65 ,9  ,60 ,2  ,58 ,7  )  
P1:51 - (19,54);   P2:5  - (42,54);   P3:11 - (18,54);   A:58: (37,10)   B:7 : (61,10)   C:60: (61,69)   D:9 : (37,69)  Diff: (6  ,40 ,21 ,61 ,27 ,46 )  
P1:52 - (63,16);   P2:34 - (27,16);   P3:48 - (68,16);   A:46: (6 ,67)   B:61: (59,67)   C:6 : (59,12)   D:21: (6 ,12)  Diff: (14 ,4  ,49 ,53 ,63 ,18 )  
P1:53 - (9 ,74);   P2:63 - (49,74);   P3:18 - (21,74);   A:34: (27,16)   B:48: (68,16)   C:19: (68,63)   D:33: (27,63)  Diff: (22 ,35 ,10 ,45 ,32 ,57 )  
P1:54 - (39,32);   P2:25 - (28,32);   P3:55 - (12,32);   A:22: (45,19)   B:35: (8 ,19)   C:32: (8 ,60)   D:45: (45,60)  Diff: (30 ,66 ,38 ,37 ,1  ,29 )  
P1:55 - (12,32);   P2:54 - (39,32);   P3:25 - (28,32);   A:10: (26,19)   B:22: (45,19)   C:45: (45,60)   D:57: (26,60)  Diff: (38 ,30 ,66 ,29 ,37 ,1  )  
P1:56 - (18,25);   P2:16 - (19,25);   P3:62 - (42,25);   A:65: (60,69)   B:9 : (37,69)   C:58: (37,10)   D:2 : (60,10)  Diff: (46 ,61 ,27 ,21 ,6  ,40 )  
P1:57 - (26,60);   P2:45 - (45,60);   P3:32 - (8 ,60);   A:53: (9 ,74)   B:63: (49,74)   C:4 : (49,5 )   D:14: (9 ,5 )  Diff: (54 ,25 ,55 ,13 ,42 ,12 )  
P1:58 - (37,10);   P2:7  - (61,10);   P3:2  - (60,10);   A:41: (17,38)   B:50: (75,38)   C:17: (75,41)   D:26: (17,41)  Diff: (62 ,56 ,16 ,5  ,11 ,51 )  
P1:59 - (43,44);   P2:36 - (41,44);   P3:39 - (74,44);   A:29: (23,18)   B:37: (55,18)   C:30: (55,61)   D:38: (23,61)  Diff: (3  ,20 ,44 ,64 ,47 ,23 )  
P1:60 - (61,69);   P2:65 - (60,69);   P3:9  - (37,69);   A:17: (75,41)   B:24: (66,41)   C:43: (66,38)   D:50: (75,38)  Diff: (11 ,51 ,5  ,56 ,16 ,62 )  
P1:61 - (59,67);   P2:27 - (14,67);   P3:46 - (6 ,67);   A:5 : (42,54)   B:11: (18,54)   C:56: (18,25)   D:62: (42,25)  Diff: (19 ,15 ,33 ,48 ,52 ,34 )  
P1:62 - (42,25);   P2:56 - (18,25);   P3:16 - (19,25);   A:60: (61,69)   B:65: (60,69)   C:2 : (60,10)   D:7 : (61,10)  Diff: (27 ,46 ,61 ,40 ,21 ,6  )  
P1:63 - (49,74);   P2:18 - (21,74);   P3:53 - (9 ,74);   A:48: (68,16)   B:52: (63,16)   C:15: (63,63)   D:19: (68,63)  Diff: (35 ,10 ,22 ,32 ,57 ,45 )  
P1:64 - (15,71);   P2:47 - (29,71);   P3:23 - (35,71);   A:36: (41,44)   B:39: (74,44)   C:28: (74,35)   D:31: (41,35)  Diff: (43 ,41 ,50 ,24 ,26 ,17 )  
P1:65 - (60,69);   P2:9  - (37,69);   P3:60 - (61,69);   A:24: (66,41)   B:26: (17,41)   C:41: (17,38)   D:43: (66,38)  Diff: (51 ,5  ,11 ,16 ,62 ,56 )  
P1:66 - (1 ,61);   P2:38 - (23,61);   P3:30 - (55,61);   A:12: (12,47)   B:13: (39,47)   C:54: (39,32)   D:55: (12,32)  Diff: (59 ,36 ,39 ,8  ,31 ,28 )  



I wrote the example in a hurry. Although it's not exactly like this here, even without knowing the scalar, it's possible to find 10 other points related to a single point. The other 6 are the differences between them.

Sample 9: A:26: (17,41)   B:17: (75,41)   C:50: (75,38)   D:41: (17,38)
26-17 = 9
50-41 = 9
Bu, iki rastgele sayı arasındaki fark değil. Bu, aynı "y" değerine sahip sayılar arasındaki farktır.

That's all the information for now, superficially. There's more to this matter than meets the eye.

The same parameters apply in the same code for secp256k1.
Code:
#The same parameters apply in the same code for secp256k1.
p= 115792089237316195423570985008687907853269984665640564039457584007908834671663
n= 115792089237316195423570985008687907852837564279074904382605163141518161494337
Gx= 55066263022277343669578718895168534326250603453777594175500187360389116729240
Gy=32670510020758816978083085130507043184471273380659243275938904335757337482424
#Gx = 1
#Gy = 29896722852569046015560700294576055776214335159245303116488692907525646231534
a = 0
b = 7
nhalf = 57896044618658097711785492504343953926418782139537452191302581570759080747169
lamda_scalar1 = 78074008874160198520644763525212887401909906723592317393988542598630163514318
lamda_scalar2 = 37718080363155996902926221483475020450927657555482586988616620542887997980018

curve = ellipticcurve.CurveFp(p, a, b)
G = ellipticcurve.Point(curve, Gx, Gy)
kTimesG
Full Member
***
Offline Offline

Activity: 728
Merit: 222


View Profile
January 28, 2026, 05:22:15 PM
 #40

Although it's not exactly like this here, even without knowing the scalar, it's possible to find 10 other points related to a single point.

All the other points on the curve are related to a single point as well. Just keep adding.

The whole idea of an endomorphism is to not do any EC operations at all. What I see in your code, is that you are actually doing EC math to get to other points, and moreover, solving DLP instances.

If you analyze the real secp256k1, you'll find that the number of points divides by 2, 3, and then, IIRC, 147, 631, etc. However, the only real endomorphism only has 2*3=6 points, the rest (like 147 points per orbit) generate points without any common X or Y, which means: they cannot be used as an attack vector, just for iterating the orbiting points (and this requires EC scalar multiplication).

Off the grid, training pigeons to broadcast signed messages.
Pages: « 1 [2] 3 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!