Does Electrum leak part of the private key for every bitcoin transaction?

[adaseb]

Today on Reddit they were discussing security of Hardware Wallets and someone claimed that

https://www.reddit.com/r/Bitcoin/comments/66vka4/friendly_reminder_when_using_a_hardware_wallet/dgm8ohh/

Actually no. The private key can be leaked in the bitcoin transaction itself.
Unless the wallet is following the RFC-6979 standard, it is impossible to tell if the wallet is leaking small amounts of the private key. Even if the wallet does follow the standard, to verify that it is not actually leaking data, you would need to audit each signature, which means that your auditing code needs the private key, defeating the purpose of the hardware wallet in the first place.
Unless you trust the entire supply chain, there is an opportunity for an attacker to get private keys.
https://bitcointalk.org/index.php?topic=285142.0

So if I constantly reuse the same public BTC address and with every outgoing transaction that I perform does the transaction leak some part of the private key? If so doesn't this pose a huge security risk for everyone using Electrum since not everybody uses a new address for every transaction.

To prevent this from happening what should we do?

Use a new BTC address and never keep any BTC there if a outgoing transaction was made?

Also found this

https://en.bitcoin.it/wiki/Address_reuse

Bitcoin does not, at a low level, have any concept of addresses, only individual coins. Address reuse, at this layer, requires producing multiple digital signatures when you spend bitcoins. Multiple situations have been found where more than one digital signature can be used to calculate the private key needed to spend bitcoins. Even if you spend all the bitcoins claimed by this private key at once, it is still possible to double-spend them in theft before they confirm. While the known situations for finding the private key from signatures have been fixed, it is not prudent to assume there aren't more such situations yet unknown.

In the case of spending all the TXOs in a single transaction, there is an additional risk if someone is actively monitoring the network for vulnerable transactions. Upon receiving such a transaction, they can split up their double spends such that there is only one ECDSA verification per transaction (making a single transaction for each TXO). This will cause the attacker's transactions to relay across the rest of the nodes faster than the legitimate one, increasing success of a double spend.

[1714803614]

1714803614

[1714803614]

1714803614

[1714803614]

1714803614

[1714803614]

1714803614

[pooya87]

(i am not an expert and i would love to hear more about this from others but here is my information)

it is all about the signature and how it was created. if there is some weakness in implementations of the Elliptic Curve Digital Signature Algorithm (ECDSA) then there will be a possible way of finding the private key from the signature in the transaction. e.g. using a not-random k value.
this doesn't actually need address reuse. one signature is enough, although i believe reuse makes it easier.

read these for more information:
http://www.coindesk.com/open-source-tool-identifies-weak-bitcoin-wallet-signatures/
https://www.nilsschneider.net/2013/01/28/recovering-bitcoin-private-keys.html

[adaseb]

Yes did more reading and checked all my input scripts. I guess if your input scripts look like this

30440220617e4ccc46033376033dc546d316e54da2ff5e341255424de8be11ab0040a7d502204aa58d628ef0a8489f43fd9a8bfff191032d3fc51392511ec4301d2a3e81f31201 031af667116814cf58b4984a591bb956afb5759fbd40e390aabfc617c67784e50a   

30440220617e4ccc46033376033dc546d316e54da2ff5e341255424de8be11ab0040a7d5022048fc0b9c31ebe7b9ec31cab8776a82c52a2c0daf021a111b4535d3efe8e64aef01 031af667116814cf58b4984a591bb956afb5759fbd40e390aabfc617c67784e50a   

30450220617e4ccc46033376033dc546d316e54da2ff5e341255424de8be11ab0040a7d5022100ac5a8041d3cb0f5536bf13c7c422fc5f65ec06bfb00cdbe10c064b7bb8c3831c01 031af667116814cf58b4984a591bb956afb5759fbd40e390aabfc617c67784e50a


Where the first 30-40 characters or so are all identical, it means you have the same R and if you used the same R in more than 1 transaction, its very easy to calculate the private key.

[kolloh]

Yes did more reading and checked all my input scripts. I guess if your input scripts look like this

30440220617e4ccc46033376033dc546d316e54da2ff5e341255424de8be11ab0040a7d502204aa58d628ef0a8489f43fd9a8bfff191032d3fc51392511ec4301d2a3e81f31201 031af667116814cf58b4984a591bb956afb5759fbd40e390aabfc617c67784e50a   

30440220617e4ccc46033376033dc546d316e54da2ff5e341255424de8be11ab0040a7d5022048fc0b9c31ebe7b9ec31cab8776a82c52a2c0daf021a111b4535d3efe8e64aef01 031af667116814cf58b4984a591bb956afb5759fbd40e390aabfc617c67784e50a   

30450220617e4ccc46033376033dc546d316e54da2ff5e341255424de8be11ab0040a7d5022100ac5a8041d3cb0f5536bf13c7c422fc5f65ec06bfb00cdbe10c064b7bb8c3831c01 031af667116814cf58b4984a591bb956afb5759fbd40e390aabfc617c67784e50a


Where the first 30-40 characters or so are all identical, it means you have the same R and if you used the same R in more than 1 transaction, its very easy to calculate the private key.

What would cause multiple input scripts to use the same R value? I'm hoping this wouldn't happen with Electrum just from reusing an address?

[pooya87]

What would cause multiple input scripts to use the same R value? I'm hoping this wouldn't happen with Electrum just from reusing an address?

"some weakness in implementations of the Elliptic Curve Digital Signature Algorithm (ECDSA)"
in other words: "poorly written code"

a somewhar similar incident was blockchain.info and their Android wallets. they used random.org to generate their random number (i think it was the k value but i am no expert and have terrible memory!) and random.org changed some stuff about their url so the page gave an error page, so all the wallets created at that particular time hit a brick wall and generated the same private keys and people lost a lot of money!

[kolloh]

What would cause multiple input scripts to use the same R value? I'm hoping this wouldn't happen with Electrum just from reusing an address?

"some weakness in implementations of the Elliptic Curve Digital Signature Algorithm (ECDSA)"
in other words: "poorly written code"

a somewhar similar incident was blockchain.info and their Android wallets. they used random.org to generate their random number (i think it was the k value but i am no expert and have terrible memory!) and random.org changed some stuff about their url so the page gave an error page, so all the wallets created at that particular time hit a brick wall and generated the same private keys and people lost a lot of money!

Oh yikes. Yeah, I do remember blockchain.info having a security issue similar to this such as the following with their web wallet:
https://blog.blockchain.com/2014/12/08/blockchain-info-security-disclosure/

Does anyone know if older versions of Electrum ever had this weakness?

[SimmonenY]

OK, now I'm starting to worry. I've been using Electrum for some time now but everything's been fine.

[NeuroticFish]

Where the first 30-40 characters or so are all identical, it means you have the same R and if you used the same R in more than 1 transaction, its very easy to calculate the private key.

While I reused the same address quite a lot I've never had any issues, nor stolen coins. But I work with small amounts.
So no problems for me, neither with Multibit Classic I used at start, neither Electrum (where I imported the private key from Multibit).
And I talk here about use of the same address for more than a year.

I also looked into a few transactions and I didn't notice any of them re-use the first 30-40 characters.

[pooya87]

Does anyone know if older versions of Electrum ever had this weakness?

to my knowledge no, and it is highly unlikely because as i said these are rare cases.

OK, now I'm starting to worry. I've been using Electrum for some time now but everything's been fine.

Things are still perfectly fine. there is always a chance of unknown bugs being found but the chances are small. and the chances of those bugs being serious are much smaller. and Electrum has been being using for many years by many users. and most of these bugs show themselves through usage.

[pooya87]

And I talk here about use of the same address for more than a year.

one additional thing about address reuse you need to know is that you are also putting your public key out there.
here is the pubKey belonging to the address you put in your profile:

Code:

0470937b16d2f04f216327702c40997b0d6acda345fe5a538b55a5487297cad2e643057eb4e5dfbdb6a1fe48a499bc970c8114df35e574e4e705ca015a34381fcc

and this is directly derived from your private key after usage of ECDSA. there is no SHA256, HASH160 performed on it like your bitcoin address starting with 1.
while this is still perfectly safe and there is nothing to worry about, but in the future there may be some weakness found in ECDSA and used to find private key from that pubKey you already revealed by spending bitcoin from that key. this is a small chance but still something to consider

[NeuroticFish]

And I talk here about use of the same address for more than a year.

one additional thing about address reuse you need to know is that you are also putting your public key out there.
here is the pubKey belonging to the address you put in your profile:

Code:

0470937b16d2f04f216327702c40997b0d6acda345fe5a538b55a5487297cad2e643057eb4e5dfbdb6a1fe48a499bc970c8114df35e574e4e705ca015a34381fcc

and this is directly derived from your private key after usage of ECDSA. there is no SHA256, HASH160 performed on it like your bitcoin address starting with 1.
while this is still perfectly safe and there is nothing to worry about, but in the future there may be some weakness found in ECDSA and used to find private key from that pubKey you already revealed by spending bitcoin from that key. this is a small chance but still something to consider

Well, you pointed out very interesting info, however I was not talking about the address currently in my profile.
The address I was talking about was in my profile for more than a year, but now I don't use it anymore. It gets some referral dust now and then from a faucet, but that's all. You're welcome to hack that one

Since I've read about possible weaknesses/probability of collision I change addresses from time to time, no matter what wallet I use, no matter if I use(d) single address or more proper wallet. I try to stay safe, just in case. Thanks for the heads up though. My post was meant to make people a little more confident: the problem is not so wide spread.

[pooya87]

~ You're welcome to hack that one ~

i think you misunderstood me a bit. if it was hackable this way first ones to be hacked would have been the big exchanges hot wallets and then services which contain 100s+ bitcoins

[NeuroticFish]

~ You're welcome to hack that one ~

i think you misunderstood me a bit. if it was hackable this way first ones to be hacked would have been the big exchanges hot wallets and then services which contain 100s+ bitcoins

I would clearly not reveal any info about a wallet containing even $100 worth, really. It's not about misunderstanding you.
And I really expect the services with 100+BTC to use Bitcoin Core wallet. I mean, they sit on big amounts of money, having a computer only for this job is not an investment they cannot afford. And if that amount is customers' money... hmm.. I wish I'd know which services are sloppy and don't do the right thing (to avoid them).

[adaseb]

So the public key (not bitcoin address) is only revealed right after 1 output transaction is made?

[pooya87]

So the public key (not bitcoin address) is only revealed right after 1 output transaction is made?

it doesn't have anything to do with 1 output or 1000. that is the structure of the signature that is used inside the bitcoin transaction. it appends the public key to the end of the signature after a 1 byte hash code type (01)

[Abdussamad]

I didn't follow the whole thread but it is obvious to me that this is not something you have to worry about with electrum because it does use deterministic signatures. So it follows that RFC you talked about in the OP.