Bitcoin Forum

Bitcoin => Development & Technical Discussion => Topic started by: jubalix on November 05, 2013, 11:47:41 AM



Title: ECDSA encryption replacement
Post by: jubalix on November 05, 2013, 11:47:41 AM
I hear whispers that ECDSA is crackable....is there any way to change this part of the encryption scheme/codebase to something more secure?


Title: Re: ECDSA encryption replacement
Post by: DannyHamilton on November 05, 2013, 12:57:02 PM
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.


Title: Re: ECDSA encryption replacement
Post by: gmaxwell on November 05, 2013, 05:13:21 PM
At least get the terminology right in your FUD: ECDSA is not encryption.


Title: Re: ECDSA encryption replacement
Post by: piotr_n on November 05, 2013, 05:57:28 PM
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?


Title: Re: ECDSA encryption replacement
Post by: gmaxwell on November 05, 2013, 06:30:43 PM
:( piotr_n  you were part of the thread where we reproduced our curve parameters, were you not?


Title: Re: ECDSA encryption replacement
Post by: piotr_n on November 05, 2013, 06:34:56 PM
:( 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...


Title: Re: ECDSA encryption replacement
Post by: gmaxwell on November 05, 2013, 07:07:56 PM
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 (http://safecurves.cr.yp.to/rigid.html) 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


Title: Re: ECDSA encryption replacement
Post by: jubalix on November 06, 2013, 07:47:10 AM
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?


Title: Re: ECDSA encryption replacement
Post by: haightst on November 06, 2013, 04:03:59 PM
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 (http://safecurves.cr.yp.to/rigid.html) 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?  8) need to dig for it!


Title: Re: ECDSA encryption replacement
Post by: behindtext on November 07, 2013, 09:55:07 AM
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.