Topic: Is bitcoin v0.10's new libsecp256k1 safe & without mathematical backdoors? - page 3. (Read 8372 times)

You should have asked.  I was surprised people didn't. Though there are many reasons around the level of publicly visible review and software testing,  there is more elaboration available now that I couldn't include in the release notes when I wrote them: https://www.reddit.com/r/Bitcoin/comments/2rrxq7/on_why_010s_release_notes_say_we_have_reason_to/

Libsecp256k1 isn't done yet. It won't be used for consensus relevant behavior in Bitcoin core until it's more mature and reviewed. Andytoshi gave a good explanation for the why we can be reasonably comfortable with signing-- that it's verified with a separate implementation at runtime (and has been cross verified against other implementations), and the scope for attacks in signing are narrow and auditable through conventional means, though more review is always useful.

If you were going to attack cryptosystems used in Bitcoin, OpenSSL would arguably make a much better target due to its complexity, opacity, and people's habit of blindly updating it due to its frequent security issues: see also the recent issues with OpenSSL's latest update breaking Bitcoin nodes.

That's the right question Collin. Fortunately, because this is all open source you can get a definitive answer.

I thought about what the OP is saying myself when I read the release notes on the 0.10 RC... But since the code is always public, I've discarded these thoughts

andytoshi, thank you for your insight, it's pretty clear even for non techies

Hi colinistheman,


This is a good question. I should start off by mentioning that Pieter Wuille, the author of libsecp256k1, has been involved with Bitcoin Core since 2010 and by this point has written something like half of its current code. So if he is compromised, we have much bigger problems . Also, libsecp256k1 currently only used for signing, not verification, and in this case its signatures are always verified against another implementation --- so at least today it is not a great attack vector. More eyes are always better, so if you are concerned about it I encourage you to peruse the code now, before it is used more heavily.

All that said, I don't think there is any cause for concern.

I've been following libsecp256k1 since last September, shortly after its conception, when its main purpose was experimenting with speed improvements over OpenSSL. I've never contributed code, but I've read almost all of it at some point. I've also written the Rust bindings, which have many unit tests that I wrote entirely independently of the original codebase. (I'm not a random passerby by the way; I've been programming for nearly 20 years, in progress on a Ph.D. in cryptography, been involved with Bitcoin since 2011, and have been thinking about digital signatures specifically for over a year.) I've also done thorough audits on some heavily-algebraic parts of the libsecp256k1 codebase. (The Bitcoin developers have requested I do this a couple of times specifically because of my mathematical expertise; however, I can say that there isn't much knowledge required, you just need to not be allergic to symbols ).

I am more confident that libsecp256k1 is free of backdoors (deliberate or accidentally via the intrinsic fragility of ECDSA) than I am about OpenSSL's implementation of ECDSA. The reasons are pretty general: libsecp256k1's code is simpler and cleaner; it is designed specifically for ECDSA, so it is a much much smaller codebase (less room for error and reviewers can look more closely at the specific ECDSA code); its test coverage is more thorough. The code is also written in a modular way with the explicit goal of being easy to analyze. Some parts are even written with algebraic invariants commented on every line, providing a mathematical proof of correct operation. (The proof can be checked by starting on any line and checking the invariants in both directions until you hit the ends of the function.)

Technically there is also very little room for backdooring. By far the most straightforward way to backdoor an ECDSA implementation is to affect the random nonce generation. However, libsecp256k1 takes its nonce as input to its API, and from that point on signing and verification are deterministic functions. Any nonce skew would need to occur in the Bitcoin code which calls into libsecp256k1; however, since November nonce generation has been deterministic as well (using RFC6979). This code has been audited and replicated by myself and others; it is also unit tested. So I don't believe there are any nonce-skew attacks here.

Alternate means of backdooring might be to add explicit branches (which would be very visible to auditors), clever algebraic tricks (also noticeable by auditors, given how simple the correct algebra is), exploitation of behaviour outside the C spec such as use of uninitialized memory (which would appear in tools such as valgrind). I also don't believe there are any of these for the reasons just given. A final category of backdoor might be the use of sidechannels. Explicit sidechannel usage such as saving things to disk would be immediately visible in the code, while avoiding implicit sidechannels such as CPU timing or power usage is a deliberate goal of libsecp256k1 and something we check for in audits. Further, these sidechannels are measurable by definition, and these sorts of measurements are something that the developers are very interested in.


Andrew

Yes I'm aware it's public. Just wanted to know that it's been reviewed. It's not paranoia, just a legit question. Either the new library has or it hasn't been thoroughly reviewed.

The reason I feel that any mathematical vulnerabilities could get past a casual review is because the library uses different cryptographic functions which are highly mathematical. So it would require a very sharp individual to competently say it's 100% good.

This is all public.  The code is public, the comments are public.

A library like this is pretty specialized.  Not a whole lot of people are competent to review it, and I think that a good fraction of them already have.  If you have specific questions, gmaxwell could probably answer them.  General paranoia probably won't get you much attention though.

Note: Pardon me if I have any of the wording or concepts of this post incorrect.


With the recent release of the beta version of Bitcoin Core v0.10, a new library was introduced, libsecp256k1.

In the release notes it says, "we have reason to believe that libsecp256k1 is better tested and more thoroughly reviewed than the implementation in OpenSSL"

The introduction of a new library with functions as important as this could be manipulated to have mathematically introduced back-doors which would enable backward engineering of keys or other manipulations (perhaps seeming to be random when in fact having patterns to the numbers which could be used by NSA-type organizations to "infiltrate" bitcoin security). I am not saying this has happened, but just saying that this would be a sneaky and effective way to implant backdoors into bitcoin.

If I was an enemy organization (NSA, PRISM, etc) and I wanted to infiltrate bitcoin, this is how I would do it. I would handsomely pay off some coder(s) to introduce a backdoor or predictable mathematical weakness and implement it into some obscure aspect of the code, such as the elliptic curve functions in libsecp256k1. Has this possibility been considered?

While I do not have the knowledge to verify the security of this new library, does anyone else have proof that it is secure? What assurance do we have that it is as secure or more secure than the library it replaced? 99.9% of people adopting the new version are not going to know what is in that new library or how it operates.

I just wanted to voice this concern because it had been on my mind.

----------------------------------------------------

To illustrate the point further, here are two quotes from a recent Edward Snowden interview (conducted around Jan 23rd, 2015):

Edward Snowden talking about cryptography and how it takes a few years to fully vindicate that it's safe:

https://www.youtube.com/watch?x-yt-ts=1422327029&v=7Ui3tLbzIgQ&feature=player_embedded&x-yt-cl=84838260#t=713

time: 11:53-12:24

-Edward Snowden, Jan 23 2015.


Also, a little bit later in the same video, Bruce Schneier talks about backdoor entered into linux code that almost got through.

(time: 13:31-15:53)

----------------------------------------------------

These are the same kind of concerns that entered my mind. My intent of this thread is twofold: 1.) to pass this knowledge on to raise community awareness (as bitcoin is open source), and 2.) To see if any individuals can come forth to provide information that the new library is safe. And how we can know that so quickly when Snowden himself says it can take years to fully prove it (as in the first quoted passage above).

I want it to be clear that there is no present threat to Bitcoin that I'm aware of. I am being preemptive.

My logic is that if we can all spot this kind of infiltration, then it will be less likely to happen in the future. And I want a safe Bitcoin for years to come.

----------------------------------------------------

Feb 19, 2015 UPDATE:

Bitcoin Developer Peter Wuille speaks about the new lipsecp256k1 library here in this video.