Bitcoin Forum
November 17, 2019, 12:49:11 PM *
News: Help collect the most notable posts made over the last 10 years.
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: What libraries for secp256k1 have been used for bitcoin in the past?  (Read 135 times)
Anonymous Kid
Member
**
Offline Offline

Activity: 183
Merit: 23


View Profile
January 06, 2019, 09:38:15 AM
 #1

Is it possible that at least one of them had an exploit in them?
Making all of the transactions/addresses sent during that period vulnerable to attack?
The Bitcoin Forum is turning 10 years old! Join the community in sharing and exploring the notable posts made over the years.
1573994951
Hero Member
*
Offline Offline

Posts: 1573994951

View Profile Personal Message (Offline)

Ignore
1573994951
Reply with quote  #2

1573994951
Report to moderator
1573994951
Hero Member
*
Offline Offline

Posts: 1573994951

View Profile Personal Message (Offline)

Ignore
1573994951
Reply with quote  #2

1573994951
Report to moderator
1573994951
Hero Member
*
Offline Offline

Posts: 1573994951

View Profile Personal Message (Offline)

Ignore
1573994951
Reply with quote  #2

1573994951
Report to moderator
darosior
Full Member
***
Offline Offline

Activity: 201
Merit: 239



View Profile WWW
January 06, 2019, 12:23:03 PM
Merited by ETFbitcoin (1)
 #2

Is it possible that at least one of them had an exploit in them?
Making all of the transactions/addresses sent during that period vulnerable to attack?
Hi,

To answer the question in the title : since 0.10 (maybe before?), bitcoin-core uses its own implementation of secp256k1 : https://github.com/bitcoin/bitcoin/tree/v0.10.0/src/secp256k1 .
To answer the question in the post :
Is it possible that at least one of them had an exploit in them?
It is indeed possible but I think we would have heard about it, and I think core devs read the code they use for something as touchy as Bitcoin network.

Making all of the transactions/addresses sent during that period vulnerable to attack?
How ?

EDIT : To complete the answer here is the first commit of the secp256k1 library used by bitcoin-core https://github.com/bitcoin-core/secp256k1/commit/2e4ca460721c96a560be70f86a0f9bd9f71cf699 .

Coding Enthusiast
Hero Member
*****
Offline Offline

Activity: 701
Merit: 1159


Novice C♯ Coder


View Profile WWW
January 06, 2019, 01:57:04 PM
Last edit: January 06, 2019, 02:12:58 PM by Coding Enthusiast
Merited by Anduck (2), MagicByt3 (1)
 #3

It depends on which implementation of bitcoin you have in mind when you ask this question.

For example blockchain.com (.info) had a bug in one of their wallets (I believe it was the Android wallets) where they used random.org to generate k values and one day random.org changed their API and people lost money because it revealed their private keys!

bitcoin-core (QT) used to use OpenSSL library which had exploitable bug with its DER encodings which could be exploited and cause a fork, no keys were at risk though. https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009697.html

There was another "exploit" in the way mathematics of elliptic curves work where you could replace s in a signature with -s (malleability) which would have changed the hash. Now we enforce low s values only. No keys were at risk here either. https://en.bitcoin.it/wiki/Transaction_malleability#Signature_Malleability

Projects List+Suggestion box
Donation link using BIP21
Bech32 Donation link!
BitcoinTransactionTool (0.9.2):  Ann - Source Code
Watch Only Bitcoin Wallet (supporting SegWit) (3.1.0):  Ann - Source Code
SharpPusher (broadcast transactions) (0.10.0): Ann - Source Code

ETFbitcoin
Legendary
*
Offline Offline

Activity: 1820
Merit: 2086

Use SegWit and enjoy lower fees.


View Profile WWW
January 06, 2019, 06:46:24 PM
Last edit: January 06, 2019, 08:24:16 PM by ETFbitcoin
 #4

Is it possible that at least one of them had an exploit in them?

It's possible, but IMO it won't be easy to find. It's more likely we find exploit within CSPRNG/PRNG or someone put backdoor for k values of ECDSA.

Reference link https://eprint.iacr.org/2014/848.pdf

Making all of the transactions/addresses sent during that period vulnerable to attack?

You meant all transaction/address which contain address generated with exploited library? If so, the answer is yes if the exploit allow attacker to get private key with far less computational power.

Anonymous Kid
Member
**
Offline Offline

Activity: 183
Merit: 23


View Profile
January 07, 2019, 12:16:19 PM
 #5

It's possible, but IMO it won't be easy to find. It's more likely we find exploit within CSPRNG/PRNG or someone put backdoor for k values of ECDSA.


How is it possible to backdoor 'k' value? I thought 'k' is generated from a hash of private key?
Coding Enthusiast
Hero Member
*****
Offline Offline

Activity: 701
Merit: 1159


Novice C♯ Coder


View Profile WWW
January 07, 2019, 01:37:43 PM
Merited by ETFbitcoin (1)
 #6

It's possible, but IMO it won't be easy to find. It's more likely we find exploit within CSPRNG/PRNG or someone put backdoor for k values of ECDSA.

How is it possible to backdoor 'k' value? I thought 'k' is generated from a hash of private key?

Not necessarily since it can be a random number inside (0<k<n-1). It can also be deterministic in which case it is not exactly hash of the private key. If you are using a deterministic k then it is calculated using HMAC with an appropriate hash function (SHA256 in our case) with private key as HMAC's key.

If there is a problem with implementation and you are not finding a random k and reuse the same value more than once, it is possible to calculate the private key from that.

Projects List+Suggestion box
Donation link using BIP21
Bech32 Donation link!
BitcoinTransactionTool (0.9.2):  Ann - Source Code
Watch Only Bitcoin Wallet (supporting SegWit) (3.1.0):  Ann - Source Code
SharpPusher (broadcast transactions) (0.10.0): Ann - Source Code

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!