Search content
Sort by
Showing 20 of 57 results by CrunchyF
⭐ Merited by Cricktor (2)
Surprisingly the way to generate the k from 1LN4yp6rQALjwg53SKsi44teq1fp2v5wqR doesn't seems weak.
This my method to say that
Step 1 :
recovered every tx signed by 1LN4yp6rQALjwg53SKsi44teq1fp2v5wqR (total sent136 BTC!!!!)
Step2 :
identified the two input where r==b42646001435ec60a40982735c4e73d31be13d0086be394eaf5ce10b0f38f689
Step 3:
recovered k for this two input with nonce reused formula
this is the result:
But 1 sample of k is too low to see a patern or some biased entropy so I made the assumption that every k was generate with the same (probably) weak RNG.
Step 4:
recovered every k for 1LN4yp6rQALjwg53SKsi44teq1fp2v5wqR (priv = 28608884601749819904852249207473436882265395560722309163084982020290971201593) with this formula
there is 675 different k for 1LN4yp6rQALjwg53SKsi44teq1fp2v5wqR
removed the one the two duplicate ( not to false entropy)
Step 5 : used a bunch of rng testing statiscal test from this google repo :
http://[code]https://github.com/google/paranoid_crypto[/code]
this is the result (p values of tests)
!! A bad p_value is very low (for ex 10e-7)
(0.7526555431379823, 'Frequency')
(0.8922205625150528, 'LongestRuns')
(0.17401029065157583, 'Runs')
(0.09841635668060003, 'BinaryMatrixRank')
(0.133636, 'LargeBinaryMatrixRank_64_*_64')
(0.711212, 'LargeBinaryMatrixRank_128_*_128')
(0.711212, 'LargeBinaryMatrixRank_256_*_256')
(0.13004210277109796, 'OverlappingTemplateMatching')
(0.9204344990860858, 'UniversalImpl1')
(0.7418997106144236, 'UniversalImpl2')
(0.9851583654051379, 'LinearComplexity_dist')
(0.32331377641368286, 'LinearComplexity_extreme')
(0.5797307681237995, 'ApproximateEntropy_0')
(0.7235022428413989, 'ApproximateEntropy_1')
(0.6577288253868533, 'ApproximateEntropy_2')
(0.49821641104893855, 'ApproximateEntropy_3')
(0.6156687031532114, 'ApproximateEntropy_4')
(0.45974516471567906, 'ApproximateEntropy_5')
(0.21884604607320576, 'ApproximateEntropy_6')
(0.2414807578348784, 'ApproximateEntropy_7')
(0.15020972293729182, 'ApproximateEntropy_8')
(0.18459092265541552, 'Spectral')
(0.4303553446832167, 'RandomWalk_0')
(0.7000550793665439, 'RandomWalk_1')
(0.7229207109153853, 'LatticeFindBias')
The latest test is the more important and perform a Lattice Reduction with samples of k. It is very powerful to identify a bias in a lcg or a lot of weak prng (according to this docs of the library :https://github.com/google/paranoid_crypto/blob/main/docs/ecdsa_signature_tests.md
This my method to say that
Step 1 :
recovered every tx signed by 1LN4yp6rQALjwg53SKsi44teq1fp2v5wqR (total sent136 BTC!!!!)
Step2 :
identified the two input where r==b42646001435ec60a40982735c4e73d31be13d0086be394eaf5ce10b0f38f689
Step 3:
recovered k for this two input with nonce reused formula
Code:
k=((Z1-Z2)*modinv((S1-S2),N))%N
Code:
priv=((k*S1-Z1)*modinv(R1,N))%N
this is the result:
Code:
k=26475164152595312352287465285862042771800478662956312110460154998405937836058 (base10)
Code:
priv=28608884601749819904852249207473436882265395560722309163084982020290971201593 (base10)
But 1 sample of k is too low to see a patern or some biased entropy so I made the assumption that every k was generate with the same (probably) weak RNG.
Step 4:
recovered every k for 1LN4yp6rQALjwg53SKsi44teq1fp2v5wqR (priv = 28608884601749819904852249207473436882265395560722309163084982020290971201593) with this formula
Code:
k=(R*priv+Z)*modinv(S,N)
there is 675 different k for 1LN4yp6rQALjwg53SKsi44teq1fp2v5wqR
removed the one the two duplicate ( not to false entropy)
Step 5 : used a bunch of rng testing statiscal test from this google repo :
http://[code]https://github.com/google/paranoid_crypto[/code]
this is the result (p values of tests)
!! A bad p_value is very low (for ex 10e-7)
(0.7526555431379823, 'Frequency')
(0.8922205625150528, 'LongestRuns')
(0.17401029065157583, 'Runs')
(0.09841635668060003, 'BinaryMatrixRank')
(0.133636, 'LargeBinaryMatrixRank_64_*_64')
(0.711212, 'LargeBinaryMatrixRank_128_*_128')
(0.711212, 'LargeBinaryMatrixRank_256_*_256')
(0.13004210277109796, 'OverlappingTemplateMatching')
(0.9204344990860858, 'UniversalImpl1')
(0.7418997106144236, 'UniversalImpl2')
(0.9851583654051379, 'LinearComplexity_dist')
(0.32331377641368286, 'LinearComplexity_extreme')
(0.5797307681237995, 'ApproximateEntropy_0')
(0.7235022428413989, 'ApproximateEntropy_1')
(0.6577288253868533, 'ApproximateEntropy_2')
(0.49821641104893855, 'ApproximateEntropy_3')
(0.6156687031532114, 'ApproximateEntropy_4')
(0.45974516471567906, 'ApproximateEntropy_5')
(0.21884604607320576, 'ApproximateEntropy_6')
(0.2414807578348784, 'ApproximateEntropy_7')
(0.15020972293729182, 'ApproximateEntropy_8')
(0.18459092265541552, 'Spectral')
(0.4303553446832167, 'RandomWalk_0')
(0.7000550793665439, 'RandomWalk_1')
(0.7229207109153853, 'LatticeFindBias')
The latest test is the more important and perform a Lattice Reduction with samples of k. It is very powerful to identify a bias in a lcg or a lot of weak prng (according to this docs of the library :https://github.com/google/paranoid_crypto/blob/main/docs/ecdsa_signature_tests.md
Ok thanks.
I generated 300 randoms privkeys in the range of puzzle 64-65.
I obtain that with all factors of every key:
the specific pattern you noticed occurs around 1/10 times (as you found before)
so i don't think that this a way to say that the priv key of the puzzle was not generated randomly.
I generated 300 randoms privkeys in the range of puzzle 64-65.
I obtain that with all factors of every key:
the specific pattern you noticed occurs around 1/10 times (as you found before)
so i don't think that this a way to say that the priv key of the puzzle was not generated randomly.
So instead of blind bruteforcing we could try to find the maximum likelihood range. This off course may not work for each of the remaining puzzle but if we see them together as a whole there seems to be a way of approach for many of them.
Privatekey being a composite number will have several factors. We are not interested in the Prime Factors but instead all the possible factors. Because once we have (somehow) a factor of the privatekey then the difficulty of that Key is reduced. Before thinking about how we can get a factor of the unknown Key, Lets analyze this concept in the already Found Keys first. There are some interesting observation. Some Keys are
what do you mean by "all the possible factors"?
this is what i found by factorizing the priv keys
Code:
0x1 : 1 : 1
0x3 : 3 : 3
0x7 : 7 : 7
0x8 : 8 : 2^3
0x15 : 21 : 3 * 7
0x31 : 49 : 7^2
0x4c : 76 : 2^2 * 19
0xe0 : 224 : 2^5 * 7
0x1d3 : 467 : 467
0x202 : 514 : 2 * 257
0x483 : 1155 : 3 * 5 * 7 * 11
0xa7b : 2683 : 2683
0x1460 : 5216 : 2^5 * 163
0x2930 : 10544 : 2^4 * 659
0x68f3 : 26867 : 67 * 401
0xc936 : 51510 : 2 * 3 * 5 * 17 * 101
0x1764f : 95823 : 3^4 * 7 * 13^2
0x3080d : 198669 : 3 * 47 * 1409
0x5749f : 357535 : 5 * 23 * 3109
0xd2c55 : 863317 : 7 * 13 * 53 * 179
0x1ba534 : 1811764 : 2^2 * 19 * 31 * 769
0x2de40f : 3007503 : 3^3 * 23 * 29 * 167
0x556e52 : 5598802 : 2 * 11 * 254491
0xdc2a04 : 14428676 : 2^2 * 19 * 189851
0x1fa5ee5 : 33185509 : 7 * 4740787
0x340326e : 54538862 : 2 * 7^2 * 556519
0x6ac3875 : 111949941 : 3 * 43 * 867829
0xd916ce8 : 227634408 : 2^3 * 3^3 * 1053863
0x17e2551e : 400708894 : 2 * 83 * 2413909
0x3d94cd64 : 1033162084 : 2^2 * 47 * 5495543
0x7d4fe747 : 2102388551 : 19^2 * 43 * 167 * 811
0xb862a62e : 3093472814 : 2 * 23 * 3001 * 22409
0x1a96ca8d8 : 7137437912 : 2^3 * 11 * 751 * 107999
0x34a65911d : 14133072157 : 19 * 41 * 131 * 138493
0x4aed21170 : 20112871792 : 2^4 * 13 * 96696499
0x9de820a7c : 42387769980 : 2^2 * 3^2 * 5 * 235487611
0x1757756a93 : 100251560595 : 3 * 5 * 6683437373
0x22382facd0 : 146971536592 : 2^4 * 60037 * 153001
0x4b5f8303e9 : 323724968937 : 3^2 * 138319 * 260047
0xe9ae4933d6 : 1003651412950 : 2 * 5^2 * 20073028259
0x153869acc5b : 1458252205147 : 23 * 63402269789
0x2a221c58d8f : 2895374552463 : 3^2 * 59 * 5452682773
0x6bd3b27c591 : 7409811047825 : 5^2 * 587 * 2903 * 173933
0xe02b35a358f : 15404761757071 : 2783789 * 5533739
0x122fca143c05 : 19996463086597 : 157 * 193 * 7477 * 88261
0x2ec18388d544 : 51408670348612 : 2^2 * 5839 * 2201090527
0x6cd610b53cba : 119666659114170 : 2 * 3^3 * 5 * 7 * 17 * 89 * 41847781
0xade6d7ce3b9b : 191206974700443 : 3 * 13 * 4902742941037
0x174176b015f4d : 409118905032525 : 3^2 * 5^2 * 23 * 197 * 1663 * 241313
0x22bd43c2e9354 : 611140496167764 : 2^2 * 3^2 * 12211 * 1390232159
0x75070a1a009d4 : 2058769515153876 : 2^2 * 3 * 7 * 43 * 53 * 197 * 2477 * 22039
0xefae164cb9e3c : 4216495639600700 : 2^2 * 5^2 * 53 * 795565215019
0x180788e47e326c : 6763683971478124 : 2^2 * 14359547 * 117755873
0x236fb6d5ad1f43 : 9974455244496707 : 7019 * 76123 * 18668011
0x6abe1f9b67e114 : 30045390491869460 : 2^2 * 5 * 19 * 79066817083867
0x9d18b63ac4ffdf : 44218742292676575 : 3^2 * 5^2 * 13 * 15117518732539
0x1eb25c90795d61c : 138245758910846492 : 2^2 * 23 * 1002377 * 1499107913
0x2c675b852189a21 : 199976667976342049 : 13 * 167 * 2511323 * 36678953
0x7496cbb87cab44f : 525070384258266191 : 307^2 * 5571097669559
0xfc07a1825367bbe : 1135041350219496382 : 2 * 13 * 31 * 71 * 269 * 587 * 3637 * 34537
0x13c96a3742f64906 : 1425787542618654982 : 2 * 13 * 54837982408409807
0x363d541eb611abee : 3908372542507822062 : 2 * 3 * 43 * 62922991 * 240750329
0x7cce5efdaccf6808 : 8993229949524469768 : 2^3 * 7 * 251 * 2383 * 268491108091
0xf7051f27b09112d4 : 17799667357578236628 : 2^2 * 3 * 19 * 3761 * 408229 * 50847529
0x1a838b13505b26867 : 30568377312064202855 : 5 * 67 * 5639 * 16181749866767
0x3 : 3 : 3
0x7 : 7 : 7
0x8 : 8 : 2^3
0x15 : 21 : 3 * 7
0x31 : 49 : 7^2
0x4c : 76 : 2^2 * 19
0xe0 : 224 : 2^5 * 7
0x1d3 : 467 : 467
0x202 : 514 : 2 * 257
0x483 : 1155 : 3 * 5 * 7 * 11
0xa7b : 2683 : 2683
0x1460 : 5216 : 2^5 * 163
0x2930 : 10544 : 2^4 * 659
0x68f3 : 26867 : 67 * 401
0xc936 : 51510 : 2 * 3 * 5 * 17 * 101
0x1764f : 95823 : 3^4 * 7 * 13^2
0x3080d : 198669 : 3 * 47 * 1409
0x5749f : 357535 : 5 * 23 * 3109
0xd2c55 : 863317 : 7 * 13 * 53 * 179
0x1ba534 : 1811764 : 2^2 * 19 * 31 * 769
0x2de40f : 3007503 : 3^3 * 23 * 29 * 167
0x556e52 : 5598802 : 2 * 11 * 254491
0xdc2a04 : 14428676 : 2^2 * 19 * 189851
0x1fa5ee5 : 33185509 : 7 * 4740787
0x340326e : 54538862 : 2 * 7^2 * 556519
0x6ac3875 : 111949941 : 3 * 43 * 867829
0xd916ce8 : 227634408 : 2^3 * 3^3 * 1053863
0x17e2551e : 400708894 : 2 * 83 * 2413909
0x3d94cd64 : 1033162084 : 2^2 * 47 * 5495543
0x7d4fe747 : 2102388551 : 19^2 * 43 * 167 * 811
0xb862a62e : 3093472814 : 2 * 23 * 3001 * 22409
0x1a96ca8d8 : 7137437912 : 2^3 * 11 * 751 * 107999
0x34a65911d : 14133072157 : 19 * 41 * 131 * 138493
0x4aed21170 : 20112871792 : 2^4 * 13 * 96696499
0x9de820a7c : 42387769980 : 2^2 * 3^2 * 5 * 235487611
0x1757756a93 : 100251560595 : 3 * 5 * 6683437373
0x22382facd0 : 146971536592 : 2^4 * 60037 * 153001
0x4b5f8303e9 : 323724968937 : 3^2 * 138319 * 260047
0xe9ae4933d6 : 1003651412950 : 2 * 5^2 * 20073028259
0x153869acc5b : 1458252205147 : 23 * 63402269789
0x2a221c58d8f : 2895374552463 : 3^2 * 59 * 5452682773
0x6bd3b27c591 : 7409811047825 : 5^2 * 587 * 2903 * 173933
0xe02b35a358f : 15404761757071 : 2783789 * 5533739
0x122fca143c05 : 19996463086597 : 157 * 193 * 7477 * 88261
0x2ec18388d544 : 51408670348612 : 2^2 * 5839 * 2201090527
0x6cd610b53cba : 119666659114170 : 2 * 3^3 * 5 * 7 * 17 * 89 * 41847781
0xade6d7ce3b9b : 191206974700443 : 3 * 13 * 4902742941037
0x174176b015f4d : 409118905032525 : 3^2 * 5^2 * 23 * 197 * 1663 * 241313
0x22bd43c2e9354 : 611140496167764 : 2^2 * 3^2 * 12211 * 1390232159
0x75070a1a009d4 : 2058769515153876 : 2^2 * 3 * 7 * 43 * 53 * 197 * 2477 * 22039
0xefae164cb9e3c : 4216495639600700 : 2^2 * 5^2 * 53 * 795565215019
0x180788e47e326c : 6763683971478124 : 2^2 * 14359547 * 117755873
0x236fb6d5ad1f43 : 9974455244496707 : 7019 * 76123 * 18668011
0x6abe1f9b67e114 : 30045390491869460 : 2^2 * 5 * 19 * 79066817083867
0x9d18b63ac4ffdf : 44218742292676575 : 3^2 * 5^2 * 13 * 15117518732539
0x1eb25c90795d61c : 138245758910846492 : 2^2 * 23 * 1002377 * 1499107913
0x2c675b852189a21 : 199976667976342049 : 13 * 167 * 2511323 * 36678953
0x7496cbb87cab44f : 525070384258266191 : 307^2 * 5571097669559
0xfc07a1825367bbe : 1135041350219496382 : 2 * 13 * 31 * 71 * 269 * 587 * 3637 * 34537
0x13c96a3742f64906 : 1425787542618654982 : 2 * 13 * 54837982408409807
0x363d541eb611abee : 3908372542507822062 : 2 * 3 * 43 * 62922991 * 240750329
0x7cce5efdaccf6808 : 8993229949524469768 : 2^3 * 7 * 251 * 2383 * 268491108091
0xf7051f27b09112d4 : 17799667357578236628 : 2^2 * 3 * 19 * 3761 * 408229 * 50847529
0x1a838b13505b26867 : 30568377312064202855 : 5 * 67 * 5639 * 16181749866767
i don't understand how you found the "special" pattern you talked about
I code a quick and dirty CUDA program for sha1 mining.
The speed i observe is around 5 Giga hash (tries) / second on a RTX3090.
The big problem would be the way to generate the password candidate. (probably slower than the hash)
Have anyone think about it?
the solution with the linux pipe "|"
The speed i observe is around 5 Giga hash (tries) / second on a RTX3090.
The big problem would be the way to generate the password candidate. (probably slower than the hash)
Have anyone think about it?
the solution with the linux pipe "|"
Code:
generator | ./cuda_hasher_sha1
would be the more convenient but i don't think than it can support such a speed6. Make sure that "n" is different than "p".
7. Validate that if you pick "n" as the starting prime, and go through all steps, you will reach "p".
You didn't explain why you want these properties of 2 curves forming a 2-cycle.7. Validate that if you pick "n" as the starting prime, and go through all steps, you will reach "p".
Is it just because this is the case for secp256k1, as noted for example (together with other interesting properties) in [1] ?
[1] https://hackmd.io/@dJO3Nbl4RTirkR2uDM6eOA/Bk0NvC8Vo
Tromp could u explain more what sort of coincidence you speak about on your link [1]
This sage script doesn't find that it is rare to have the property of the post linked when P and N are primes...:
Code:
ROUNDS=10000
for i in range(ROUNDS):
P=randint(1,2**256)
P=next_prime(P)
F=FiniteField(P)
C = EllipticCurve([F(0), F(7)])
N=C.order()
if is_prime(N):
print(P,N)
print(EllipticCurve(GF(P), [0, 1]).order())
print(EllipticCurve(GF(N), [0, 1]).order())
print('')
for i in range(ROUNDS):
P=randint(1,2**256)
P=next_prime(P)
F=FiniteField(P)
C = EllipticCurve([F(0), F(7)])
N=C.order()
if is_prime(N):
print(P,N)
print(EllipticCurve(GF(P), [0, 1]).order())
print(EllipticCurve(GF(N), [0, 1]).order())
print('')
Little explanation.
b. we know partial WIF of privatekey as nonce - we can use Monte Carlo together with LLL
c. recentering for partial integers plus BKZ or LLL.
becouse: IF OP has partial WIF example knowns MSB , not known middle, and Known LSB - it is easy even for 23 missing characters.
Post Scriptum: depends how much MSB with LSB we know - maybe we need implement enumeration.
b. we know partial WIF of privatekey as nonce - we can use Monte Carlo together with LLL
c. recentering for partial integers plus BKZ or LLL.
becouse: IF OP has partial WIF example knowns MSB , not known middle, and Known LSB - it is easy even for 23 missing characters.
Post Scriptum: depends how much MSB with LSB we know - maybe we need implement enumeration.
Do u mean that you can use Lattice attack only with one signature? Have u sources or studies to show about this attack?
any help will be appreciated too much
Could you give us the public address of your wallet?
Main question, what would be the result of finding such points on secp256k1?
Absolutely nothing because one Generator in not different from another in term of security
How do you know that? Is there any simple way to check, if for a given p-value, there is such point or not?
x³+7=y² mod(P)
or
x³+7-y²=0 mod(P)
if x=y
then
x³-x²+7=0
this equation is a polynomial of degree 3 in Finite Field and have no roots (solutions)
Quote
but there is one where x==y+1
Nice result! But how it was calculated?
Nice result! But how it was calculated?
instead of looking for x=y we can find if roots exists replacing x=y+c in the polynomial equation
where c in a constant varying between the range [-10;10] e.g
This is my Sage script:
Code:
P=0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f
C = EllipticCurve([F(0), F(7)])
F=GF(P)
R.<x>=F[]
for c in range(-10,10,1):
f=((x)**3+7)-(x+c)**2
rts=f.roots()
for r in rts:
try:
G=C.lift_x(r[0])
print(c,G,-G)
except:
pass
C = EllipticCurve([F(0), F(7)])
F=GF(P)
R.<x>=F[]
for c in range(-10,10,1):
f=((x)**3+7)-(x+c)**2
rts=f.roots()
for r in rts:
try:
G=C.lift_x(r[0])
print(c,G,-G)
except:
pass
We test G and -G to see if one corresponding to x==y+c
Quote
Now I only wonder, what algorithm is needed to get there?
see above...This is wrong. You think x==y as pointy on curve.
Theo real value is y == modinv(x.n) or x == modinv(y,n)
I have found only 5 points with this. One is satoshi pubkey
Theo real value is y == modinv(x.n) or x == modinv(y,n)
I have found only 5 points with this. One is satoshi pubkey
Sorry i don't understand your post...and why I'm wrong
I speak about coordinate in affine plan
as Q->(x,y)
Q : (103219894018170979103981239500535823206309202530631329673674059809050911020508,103219894018170979103981239500535823206309202530631329673674059809050911020507)
or 04e43463c1a7b06b6e49f555d75238bd140690ee0f689fda75d87623e10acf95dce43463c1a7b06 b6e49f555d75238bd140690ee0f689fda75d87623e10acf95db (uncompresed pubkey)
or 03e43463c1a7b06b6e49f555d75238bd140690ee0f689fda75d87623e10acf95dc
is a perfect valid bitcoin pubkey
No there is no point in secp256k1 where x==y
but there is one where x==y+1
x=103219894018170979103981239500535823206309202530631329673674059809050911020508
y=103219894018170979103981239500535823206309202530631329673674059809050911020507
but there is one where x==y+1
x=103219894018170979103981239500535823206309202530631329673674059809050911020508
y=103219894018170979103981239500535823206309202530631329673674059809050911020507
Well, I'm not interested in signatures and related stuff, the entire elliptic curve system revolves around public keys, so that is the only entry point for me to try all I got and find the best solution. "If there are no known method to correctly guess the position of any X coordinate of k, then finding a way should be a goal.
I have been studying the secp256k1 for the past 2 months, and tried at least 40-50 methods to figure out which one could be used to crack the target k by hand, not using automated existing tools.
What actually is bothering me is a lack of a safe environment to publish study results without worrying about other people exploiting them! Though I'm in the learning phase, no breakthroughs yet!😉
Without to be paranoiac finding a weakness on ECC such secp256k1 and stay anonymous in a "safe place" is near impossible in this hyper-connected world
After this discover billions of dollars will be instantly at the fingertips of the researcher and at the others well informed (notice that the most probable issue is that the price of bitcoin will drop to zero).
Armed forces, governments,research consortium,mathematicians, big tech societies, will deploy all possible mean to obtain the study (and not only the legal ways
). just to insure that if secp256k1 is broken or partially broken means that the other curve (like the very close secp256r1 widely used) aren't compromised too.Today every secures communications (website certificate, https, bank,cryptocurrency, army, administration... on internet use ECC.And a lot of our economy is based on the security of the communications.
The cake is simply too big...
Hi there again with more trouble and questions, I'd appreciate the time you'd spend to respond.
Is it possible to determine which X coordinate of our k is -N or is -k inverse without obviously looking at the k ?
Is it possible to determine which X coordinate of our k is -N or is -k inverse without obviously looking at the k ?
No there is no knowed way to guess any information of private key with any information of public key, even little
IF YOU used a good random number generator.
ECDSA (and every asymmetric cryptography like RSA is based on the assumption that the derivation of a private key in a public key "seems" perfectly randomly distributed.
it is not finished.
try your self. secp256k1 if you add abstract thinking you will see "there are another properties" that you can use.
You should observe the values as output and think what is going on and test it.
a lot of us had make thousend test to verify thousends posiibilities.
some times you must "go away" and create you own pattern , sometimes expand "calculation" for new coeffs.
I still observe and have a good result.
no one on this forum will really share with his knowledge. TRY Harder and be positive.
🥰🥰try your self. secp256k1 if you add abstract thinking you will see "there are another properties" that you can use.
You should observe the values as output and think what is going on and test it.
a lot of us had make thousend test to verify thousends posiibilities.
some times you must "go away" and create you own pattern , sometimes expand "calculation" for new coeffs.
I still observe and have a good result.
no one on this forum will really share with his knowledge. TRY Harder and be positive.
This attack is not applicable to Bitcoin. Because you need that the message are the same in the two signature (it not possible in the blockchain)
I did not find any leading zero. that point is in the middle of secp256k1 subgroup.(additive inverse of middle of range point)
57896044618658097711785492504343953926418782139537452191302581570759080747168
0400000000000000000000003b78ce563f89a0ed9414f5aa28ad0d96d6795f9c633f3979bf72ae8 202983dc989aec7f2ff2ed91bdd69ce02fc0700ca100e59ddf3
57896044618658097711785492504343953926418782139537452191302581570759080747169 (multiplicative inverse of 2 mod secp256k1 n)
0400000000000000000000003b78ce563f89a0ed9414f5aa28ad0d96d6795f9c63c0c686408d517 dfd67c2367651380d00d126e4229631fd03f8ff35eef1a61e3c
First off I have visual generator. You can set any scalar from secp256k1 range and it will generate subgroup in full correspondence to secp256k1 subgroup.
Secondly all group operation with points(addition, scalar_multiplication, subtraction, division) are isomorphic to (Zp,+,*) where we fix p as secp256k1 n.
N = 115792089237316195423570985008687907852837564279074904382605163141518161494337
lambda1 = 37718080363155996902926221483475020450927657555482586988616620542887997980018
lambda2 = 78074008874160198520644763525212887401909906723592317393988542598630163514318
def multiplicative_inverse(x, m):
return pow(x, m - 2, m)
def additive_inverse(a):
return N - a
def add(a, b): #addition
return (a + b) % N
def sub(a, b): #subtraction
return (a + additive_inverse(b)) % N
def mul(a, b): #multiplication
return (a * b) % N
def div(a, b): #division
return (a * multiplicative_inverse(b, N)) % N
print(div(1, 61168582499785340698020811768434254152333414806039741990912550463524917977698))
print(div(57896044618658097711785492504343953926418782139537452191302581570759080747169,
61168582499785340698020811768434254152333414806039741990912550463524917977698))
I did a mistake I don't see that your first point is just a hexadecimal representation of the point (G/2) i talked about
Quote
Secondly all group operation with points(addition, scalar_multiplication, subtraction, division) are isomorphic to (Zp,+,*) where we fix p as secp256k1 n.
Can u explain more how you fix p
Youtube: Nadia Heninger - 48ce563f89a0ed9414f5aa28ad0d96d6795f9c62
As outlined in the video, the string "8ce563f89a0ed9414f5aa28ad0d96d6795f9c6" is common to the x coordinate of G*inv2 of all secp-k1 curves. I think it is very likely that 48ce563f89a0ed9414f5aa28ad0d96d6795f9c62 (with perhaps the first and last character (4 bits) changed) was/is generated by hashing some input, and then that was used as the basis for arriving at G.
It would be interesting to know what the original input to the hash function was, and the rationale behind the changed/added bits.
As outlined in the video, the string "8ce563f89a0ed9414f5aa28ad0d96d6795f9c6" is common to the x coordinate of G*inv2 of all secp-k1 curves. I think it is very likely that 48ce563f89a0ed9414f5aa28ad0d96d6795f9c62 (with perhaps the first and last character (4 bits) changed) was/is generated by hashing some input, and then that was used as the basis for arriving at G.
It would be interesting to know what the original input to the hash function was, and the rationale behind the changed/added bits.
Yes thanks this is an interesting video
for example:
in subgroup generated by
0447316cb65cc8f20d539616cf65bc78479c686c3f70454cf5aab84c579b57efcd18a6a630cef25 44625d80b0297017dc9fef77712bd494fb3374974096e4dc278
that has scalar(61168582499785340698020811768434254152333414806039741990912550463524917977698) in secp256k1 subgroup
0479be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c 4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8 G of secp256k1
will be at position(have scalar) 54229698599845083480280347574976582697435195709826937379446800456474139525780
0400000000000000000000003b78ce563f89a0ed9414f5aa28ad0d96d6795f9c63c0c686408d517 dfd67c2367651380d00d126e4229631fd03f8ff35eef1a61e3c
will be at position(have scalar) 27114849299922541740140173787488291348717597854913468689723400228237069762890
we can find generator point so that some point be at certain position in the subgroup.
or we can retrieve point by generator and position.
and we can do so with any point from secp256k1 if we take point and its scalar. good for research only.
will not be able to break secp256k1 curve with that.
in your
Code:
G = 0447316cb65cc8f20d539616cf65bc78479c686c3f70454cf5aab84c579b57efcd18a6a630cef2544625d80b0297017dc9fef77712bd494fb3374974096e4dc278
k=27114849299922541740140173787488291348717597854913468689723400228237069762890
k.G = 0400000000000000000000003b78ce563f89a0ed9414f5aa28ad0d96d6795f9c63c0c686408d517dfd67c2367651380d00d126e4229631fd03f8ff35eef1a61e3c
k=27114849299922541740140173787488291348717597854913468689723400228237069762890
k.G = 0400000000000000000000003b78ce563f89a0ed9414f5aa28ad0d96d6795f9c63c0c686408d517dfd67c2367651380d00d126e4229631fd03f8ff35eef1a61e3c
Nice generation of points!
how do you find such point with x having many leading zeros and the corresponding scalar?
I name it pt0 for convenient
do you start from it and randomly pick a scalar that point pt0/scalar = G
of inversly fix a random G and randomly generate a scalar k unless you find a point with x having sufficient leading zero?
I don't think that x coordinates on secp256k1 are uniformly distributed.
You can actually see visually that they're not. (I know this is not over Zp, but you get the idea)
[/quote]
if you work in Finite Field F(P) around a half of x coordinate between 1-2^256 lie on the curve y**2=x**3 + 7 (mod P) and there are perfectly distributed (even we wish for) . because if not ECSDA will be have a bias and it can be broken..
You can actually see visually that they're not. (I know this is not over Zp, but you get the idea)
[/quote]
if you work in Finite Field F(P) around a half of x coordinate between 1-2^256 lie on the curve y**2=x**3 + 7 (mod P) and there are perfectly distributed (even we wish for) . because if not ECSDA will be have a bias and it can be broken..
But anyway what do you think about the goal of this anomaly?
I don't know how G was chosen, but I don't think it's an anomaly or indicative of anything, really. You can find patterns or 'magic numbers' anywhere and everywhere.I'm agree about the fact that you can find magic pattern and voodoo belief anywhere when you speak of a chance of 1/1000 or 1/1000000 (see the Christ in the cloud, see a alien on a cigaret pack etc...)
But i'm totaly disagree when the chance is 1/100000000000000000000000000
10^26 is so big that it is totally impossible that it is due to an human misinterpretation.
it will takes millions years to a standard computer before reaching only one point with a x coordinate like this by traversing randomly the curve.
So your pretty gif is totally irrelevant
⭐ Merited by o_e_l_e_o (4) ,BlackHatCoiner (4) ,ETFbitcoin (3) ,tromp (2) ,witcher_sense (2) ,davis196 (1) ,DdmrDdmr (1)
The generator G of secp256k1 is the point
if you divide this point by 2 with a group operation => a multiplication by the inverse_mod of 2
you obtain this point:
a x coordinate in the range of 10^50 - 10^51 occurs only around every 10^(77-51) = 1 on 10^26
So for me it's a proof that it is extremely unlikely that G was chosen randomly
It's not what we can called a weakness because normally every generator generate an high entropy between every scalar multiplication 1.G 2.G 3.G etc...
you can for example choose the point
G: (1,29896722852569046015560700294576055776214335159245303116488692907525646231534) without problem
But anyway what do you think about the goal of this anomaly?
Code:
(0x79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798,0x483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8)
or Code:
(55066263022277343669578718895168534326250603453777594175500187360389116729240, 32670510020758816978083085130507043184471273380659243275938904335757337482424) in base10
if you divide this point by 2 with a group operation => a multiplication by the inverse_mod of 2
you obtain this point:
Code:
inv2=inverse_mod(2,N)
G*inv2= (86918276961810349294276103416548851884759982251107, 87194829221142880348582938487511785107150118762739500766654458540580527283772)
G*inv2= (86918276961810349294276103416548851884759982251107, 87194829221142880348582938487511785107150118762739500766654458540580527283772)
a x coordinate in the range of 10^50 - 10^51 occurs only around every 10^(77-51) = 1 on 10^26
So for me it's a proof that it is extremely unlikely that G was chosen randomly
It's not what we can called a weakness because normally every generator generate an high entropy between every scalar multiplication 1.G 2.G 3.G etc...
you can for example choose the point
G: (1,29896722852569046015560700294576055776214335159245303116488692907525646231534) without problem
But anyway what do you think about the goal of this anomaly?