ECDSA Encryption


#1

Security[edit]
In December 2010, a group calling itself fail0verflow announced recovery of the ECDSA private key used by Sony to sign software for the PlayStation 3 game console. However, this attack only worked because Sony did not properly implement the algorithm, because k was static instead of random. As pointed out in the Signature generation algorithm Section above, this makes d_A solvable and the entire algorithm useless.[6]

On March 29, 2011, two researchers published an IACR paper[7] demonstrating that it is possible to retrieve a TLS private key of a server using OpenSSL that authenticates with Elliptic Curves DSA over a binary field via a timing attack.[8] The vulnerability was fixed in OpenSSL 1.0.0e.[9]

In August 2013, it was revealed that bugs in some implementations of the Java class SecureRandom sometimes generated collisions in the k value. As discussed above, this allowed solution of the private key, in turn allowing stealing bitcoins from the containing wallet on Android app implementations, which use Java and rely on ECDSA to authenticate transactions.[10]

This issue can be prevented by deterministic generation of k, as described by RFC 6979.

Considering this, I know BitCoin secures wallets using ECDSA, if I am wrong, does this make the algorithms based on improperly implemented algorithm cause things to be solvable. I’m sure this is a noob question, though someone may also know immediately if this is solved; where the input is so random, no one can predictably attempt solution?

If so, please share that data with us? I know at least one person who could use that data.


#2

Of course improperly implemented anything may not work well (or at all).

From W:

For example, at a security level of 80 bits (meaning an attacker requires the equivalent of about 2^{80} operations to find the private key

So that’s it. If it’s done right, the amount of work required to attack is known.


#3

Bitcoin (thankfully) uses a curve that was not highlighted as possible NSA attacked. Its pretty sure the implementation is secured in bitcoin and well tested etc. so not too much to worry over there. The mailing lists how many very high level debates over curves, implementations and considerations. Here the bitcoin devs have taken great care so they should be fine. In saying all that I still think EC and magic numbers are at minimum curious and slightly uncomfortable. I think though bitcoin is a solid implementation.


#4

I intend to use a very similar security method initially for Grand Exchange; I am in the process of assembling this aspect, and first of all, before assembling the next aspects. If there is a better method to use from the get-go I will modify my approach;


#5

As I am studying the ECDSA and I thought how some implementation of this are using random numbers based on time passing, and when I read that I immediately intuited that if you just generate key pairs ahead of the algorithm, then you will have actual key pairs to test and breakthrough security. I thought I was getting ahead of myself and then glazed over the wikipedia and right in my face instances of other actually carrying this out, it was alarming; I’m glad I brought this to here, where theres a sound answer to consider; @dirvine


#6

DJB seems more trustworthy on this topic than the alternatives. Although, the research received funding from the NSF. Does one letter make a difference?


#7

A few years ago I took a CPD module with the Open University on Pure Maths. Being an Engineer and Economists, I never really had done Pure Pure Maths before, so it seemed appropos.

Part of that course was related to elliptic curves. The biggest thing I came away with is how easy it is to think you understand how elliptic curves behave when in fact you are just being ignorant. In fact, most mathematicians don’t understand diddly squat about them either, this is why a related problem has a Millennium prize attached as the Birch and Swinnerton-Dyer conjecture (warning: that conjecture hurts the mind). That field is so poorly understood by maths that they struggled to find someone to write the problem text - that is how hard elliptic curves are.

I’d said it before and I’ll say it again, encryption technologies are a field in which one should use the most mature possible technology known not to be totally broken unless you have an enormous reason not to. It pays to be as conservative as possible here. Elliptic curve cryptography libraries need at least another decade of testing before I’ll think about trusting them - I know enough about them to know almost nobody understands them well.

Niall


#8

I built out an RSA implementation, yet I was not satisfied with RSA. Perhaps,

Could you recommend some combination to incorporate into the authentication algorithm to protect something as sensitive as a client based exchange?


#9

I am not a cryptographer I am afraid. I know enough to defer to crypto experts on crypto stuff. Niall


#10

Current thinking from my perspective

RSA very mature and maths evolving fast, we can see it deteriorate, but the maths to do so is very easy to grasp. Go RSA 2048 minimum and your safe for now, the algo is only the start though the implementation is vital. (same with AES, which cypher for what reason, how many rounds etc.)
EC - as Niall says is very new and much less tested. Plus there was fright recently with some of these algo’s not many know how damaged they are. Personally they are something I have been wary of.
Lattice - Very interesting, unfinished and possibly resistant to quantum attacks.

I see us with RSA 4096 then jump across EC to Lattice, but I could be wrong. It seems likely though.

Sign up to cryptopp and alt-cryptography lists and ask a ton of questions, you will see there is no answer that is solid, but a ton of guidance. It’s a massive area to get wrong, many seem to do so though stupidly, like embedding private keys and then obfuscating code (ugh). Even the big guys do this, so at a minimum make your use secure and the algorithm is less important then. By that I mean never bend an encryption algo or try to use it in some obscured manner, make the base algorithm you use correct then secure it. It takes months and months of dedicated research per implementation.