Bitcoin Forum
November 16, 2024, 08:54:53 PM *
News: Check out the artwork 1Dq created to commemorate this forum's 15th anniversary
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: ECDSA encryption replacement  (Read 1672 times)
jubalix (OP)
Legendary
*
Offline Offline

Activity: 2646
Merit: 1023


View Profile WWW
November 05, 2013, 11:47:41 AM
Last edit: November 06, 2013, 07:43:30 AM by jubalix
 #1

I hear whispers that ECDSA is crackable....is there any way to change this part of the encryption scheme/codebase to something more secure?

Admitted Practicing Lawyer::BTC/Crypto Specialist. B.Engineering/B.Laws

https://www.binance.com/?ref=10062065
DannyHamilton
Legendary
*
Offline Offline

Activity: 3486
Merit: 4851



View Profile
November 05, 2013, 12:57:02 PM
 #2

I hear whispers that ECSDA is crackable....is there any way to change this part of the encryption scheme/codebase to something more secure?

Is there a way?  Yes.

Is it going to happen just because you are hearing whispers?  Probably not.
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4284
Merit: 8808



View Profile WWW
November 05, 2013, 05:13:21 PM
 #3

At least get the terminology right in your FUD: ECDSA is not encryption.
piotr_n
Legendary
*
Offline Offline

Activity: 2055
Merit: 1359


aka tonikt


View Profile WWW
November 05, 2013, 05:57:28 PM
 #4

I hear whispers that ECSDA is crackable....is there any way to change this part of the encryption scheme/codebase to something more secure?
There are no proofs of ECSDA being crackable.
Though, there are indeed some rumors, and IMHO they are not completely baseless...

The point is: if this specific encryption method has nothing to hide, then why is it such a big mystery how exactly the proper organizations had shaped our curves?

Call it an encryption or whatever you like, but it is probably the only math known to men that uses constants which calculations cannot be reproduced.
So it is kind of suspicious, to say the least, isn't it?

Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.
PGP fingerprint: AB9E A551 E262 A87A 13BB  9059 1BE7 B545 CDF3 FD0E
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4284
Merit: 8808



View Profile WWW
November 05, 2013, 06:30:43 PM
 #5

Sad piotr_n  you were part of the thread where we reproduced our curve parameters, were you not?
piotr_n
Legendary
*
Offline Offline

Activity: 2055
Merit: 1359


aka tonikt


View Profile WWW
November 05, 2013, 06:34:56 PM
 #6

Sad piotr_n  you were part of the thread where we reproduced our curve parameters, were you not?
I'm not sure if we are talking about the same thread... maybe you should have linked to it.

You mean the thread when a guy from some company said in an email that part of the seed used to pick up the G point was an ASCII encoded name of one of his colleges?
Well I hope you understand that 'part of the seed' leaves a lot of space for a potential corruption. So I am rather worried about the other part...

Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.
PGP fingerprint: AB9E A551 E262 A87A 13BB  9059 1BE7 B545 CDF3 FD0E
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4284
Merit: 8808



View Profile WWW
November 05, 2013, 07:07:56 PM
 #7

Well I hope you understand that 'part of the seed' leaves a lot of space for a potential corruption. So I am rather worried about the other part...
None of our parameters are from a seed. Thats how the NIST *r curves are constructed. Our parameters are completely explicable based on performance considerations, unlike the NIST ones, and meet DJB's fully rigid definition (our generator point is random, as are DJBs , but if one generator is weak all are weak).

Here is code the reproduces our parameters from performance and security principles: https://bitcointalk.org/index.php?topic=289795.msg3214237#msg3214237
jubalix (OP)
Legendary
*
Offline Offline

Activity: 2646
Merit: 1023


View Profile WWW
November 06, 2013, 07:47:10 AM
 #8

At least get the terminology right in your FUD: ECDSA is not encryption.

yeah ok, my error,

the ECDSA scheme that is used, and if it can be reverse engineered makeing all coins remaining in a address that has spent coins, able to be acquired.

The loss of confidence by itself would be very damaging.

Is there any way to replace this with a more secure mathematical scheme?

Admitted Practicing Lawyer::BTC/Crypto Specialist. B.Engineering/B.Laws

https://www.binance.com/?ref=10062065
haightst
Newbie
*
Offline Offline

Activity: 42
Merit: 0


View Profile
November 06, 2013, 04:03:59 PM
 #9

Well I hope you understand that 'part of the seed' leaves a lot of space for a potential corruption. So I am rather worried about the other part...
None of our parameters are from a seed. Thats how the NIST *r curves are constructed. Our parameters are completely explicable based on performance considerations, unlike the NIST ones, and meet DJB's fully rigid definition (our generator point is random, as are DJBs , but if one generator is weak all are weak).

Here is code the reproduces our parameters from performance and security principles: https://bitcointalk.org/index.php?topic=289795.msg3214237#msg3214237


didn't Sergio have a blog about ECDSA vulnerability?  Cool need to dig for it!
behindtext
Full Member
***
Offline Offline

Activity: 121
Merit: 103


View Profile WWW
November 07, 2013, 09:55:07 AM
 #10

At least get the terminology right in your FUD: ECDSA is not encryption.

yeah ok, my error,

the ECDSA scheme that is used, and if it can be reverse engineered makeing all coins remaining in a address that has spent coins, able to be acquired.

The loss of confidence by itself would be very damaging.

Is there any way to replace this with a more secure mathematical scheme?

gmaxwell makes a fair point that the secp256k1 curve parameters are not especially magical and can be deduced based on logic. however, that does not rule out the curve having some hidden degeneracy that substantially weakens the encryption.

gmaxwell has, in the past, suggested that djb's Ed25519 is an interesting alternative to secp256k1. the trouble with swapping out ecdsa is that it is rather smart about keeping the key size small, meaning that any replacement would have to compete on the key size vs security parameter. most post quantum algorithms have a relatively large key size vs security parameter and there aren't a whole lot of alternatives out there to ecc. the average tx size would go up along with the average key size, leading to blockchain bloat.

even if the USG et al can break secp256k1, i'll take that over banking as it currently stands. unless the weakness in ecdsa, specifically secp256k1, is really acute, you can get an edge by spreading your coins out between many addresses, i.e. keep less than X BTC at each address. this way it makes it more expensive to steal those coins, assuming someone can break ecdsa.

Pages: [1]
  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!