Bitcoin Forum
September 26, 2018, 04:18:57 AM *
News: ♦♦ New info! Bitcoin Core users absolutely must upgrade to previously-announced 0.16.3 [Torrent]. All Bitcoin users should temporarily trust confirmations slightly less. More info.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: ECDSA encryption replacement  (Read 1591 times)
jubalix
Legendary
*
Offline Offline

Activity: 1862
Merit: 1002


View Profile WWW
November 05, 2013, 11:47:41 AM
 #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
1537935537
Hero Member
*
Offline Offline

Posts: 1537935537

View Profile Personal Message (Offline)

Ignore
1537935537
Reply with quote  #2

1537935537
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1537935537
Hero Member
*
Offline Offline

Posts: 1537935537

View Profile Personal Message (Offline)

Ignore
1537935537
Reply with quote  #2

1537935537
Report to moderator
1537935537
Hero Member
*
Offline Offline

Posts: 1537935537

View Profile Personal Message (Offline)

Ignore
1537935537
Reply with quote  #2

1537935537
Report to moderator
1537935537
Hero Member
*
Offline Offline

Posts: 1537935537

View Profile Personal Message (Offline)

Ignore
1537935537
Reply with quote  #2

1537935537
Report to moderator
DannyHamilton
Legendary
*
Offline Offline

Activity: 2198
Merit: 1373



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
*
qt
Offline Offline

Activity: 2520
Merit: 1507



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

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

Bitcoin will not be compromised
piotr_n
Legendary
*
Offline Offline

Activity: 1932
Merit: 1018


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
*
qt
Offline Offline

Activity: 2520
Merit: 1507



View Profile
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?

Bitcoin will not be compromised
piotr_n
Legendary
*
Offline Offline

Activity: 1932
Merit: 1018


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
*
qt
Offline Offline

Activity: 2520
Merit: 1507



View Profile
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

Bitcoin will not be compromised
jubalix
Legendary
*
Offline Offline

Activity: 1862
Merit: 1002


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: 100


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:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!