Author

Topic: ECDSA encryption replacement (Read 1676 times)

full member
Activity: 121
Merit: 103
November 07, 2013, 04: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.
newbie
Activity: 42
Merit: 0
November 06, 2013, 11:03:59 AM
#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://bitcointalksearch.org/topic/m.3214237


didn't Sergio have a blog about ECDSA vulnerability?  Cool need to dig for it!
legendary
Activity: 2632
Merit: 1023
November 06, 2013, 02: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?
staff
Activity: 4284
Merit: 8808
November 05, 2013, 02: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://bitcointalksearch.org/topic/m.3214237
legendary
Activity: 2053
Merit: 1356
aka tonikt
November 05, 2013, 01: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...
staff
Activity: 4284
Merit: 8808
November 05, 2013, 01:30:43 PM
#5
Sad piotr_n  you were part of the thread where we reproduced our curve parameters, were you not?
legendary
Activity: 2053
Merit: 1356
aka tonikt
November 05, 2013, 12: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?
staff
Activity: 4284
Merit: 8808
November 05, 2013, 12:13:21 PM
#3
At least get the terminology right in your FUD: ECDSA is not encryption.
legendary
Activity: 3472
Merit: 4801
November 05, 2013, 07:57:02 AM
#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.
legendary
Activity: 2632
Merit: 1023
November 05, 2013, 06: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?
Jump to: