re-use of addresses

[Peter R]

As DeathAndTaxes pointed out, the security level is reduced from 160 bits to 128 bits when the public key is known.  This is fact.  Inspecting the 30 richest bitcoin addresses, I found 9 with publicly known public-keys, representing a total of 419,308 BTC.  The individuals and groups that control these address are obviously confident with 128-bit security and (IMO) the extremely-small risk of compromising secp256k1 by crypto-analysis or by breakthroughs in quantum computing.

Code:

Rank                 Address                      BTC
2	13Df4x5nQo7boLWHxQCbJzobN5gUNT65Hh	97832
6	1GLEtzJ1H2zoGrUA4RMbRJam5UJSdrk6T2	53880
7	16cou7Ht6WjTzuFyDBnht9hmvXytg6XdVT	53000
18	1QAHVyRzkmD4j1pU5W89htZ3c6D6E7iWDs	40870
22	15h6A2a3D31vRviBDdSpvhLtYJq3aePhdW	36937
23	14o7zMMUJkG6De24r3JkJ6USgChq7iWF86	36500
25	13ssxUjmQqemuiBfJSBsr7gFX7UWU7uXNK	34880
26	159SCycgn8weAy2XGUEhD6V1RTFni7E3iq	34409
27	12ib7dApVFvg82TXKycWBNpN8kFyiAN1dr	31000

                                        SUM = 419,308 BTC

I'll probably be torn to shreds for this comment, but it is my opinion that no one will ever lose a single satoshi due to a security weakness at the protocol level.  The vastly more real threats in my opinion are user and developer error.  User errors include losing keys due to theft, malware, damaged paper wallets, forgetfulness, trusting incompetent of unscrupulous third-parties, etc.  Developer errors centre around leaking private keys, for example due to reuse of the per-message secret number k while producing an ECDSA signature, or generating bitcoin addresses that don't actually correspond to a known private key.

[1714628281]

1714628281

[1714628281]

1714628281

[1714628281]

1714628281

[1714628281]

1714628281

[mjc]

The main reason for not exposing the PubKey is if to protect it in case the strength of that key is ever reduced in the future.  

What are you talking about?  How do you weaken the stregnth of the security by exposing the public key.  Asymmetric cryptography is built around the notion that you must expose the public key.  Doing so is a key (pun intended) part of the process.  You assume NO security around the public key and protect the private key.


Also keep in mind that is 128 Bit keys become weak, then there is a bigger problem than Bitcoin wallets.

[DeathAndTaxes]

I most agree with your assessment with the exception of "never".  Never is a very long time and I believe Bitcoin will need to be extended to more secure cryptographic primitives on a long enough timeline.  Not sure about you, but if we get to a place where known pubKeys are considered cryptographically weak and developers are implementing a transition to addresses based on stronger cryptography I would much rather wait that out holding value in unknown PubKeys.

Still I would point out that known public key and leaking private key are not mutually exclusive.   The most notable developer error involves repeat k values.  Repeat k values can only apply in an address reuse scenario.  If your wallet has a flaw which leads to a repeat k value you are insulated from that risk by not reusing addresses.   That is why I likened the PubKeyHash as a secondary safety.  Sure if the primary security system is flawless against all current and future threats then there is no need for a second safety.  I have never needed my backup chute when skydiving, and statistically I probably never will, that doesn't mean I jump with one chute though.

[Peter R]

The main reason for not exposing the PubKey is if to protect it in case the strength of that key is ever reduced in the future.  

What are you talking about?  How do you weaken the stregnth of the security by exposing the public key.  Asymmetric cryptography is built around the notion that you must expose the public key.  Doing so is a key (pun intended) part of the process.  You assume NO security around the public key and protect the private key.

It's been explained a couple times already:

    -  the security level is reduced from 160 bits to 128 bits.  
    -  finding the discrete logarithm of a random elliptic curve element with respect to a publicly known base point must remain infeasible.  

[DeathAndTaxes]

The main reason for not exposing the PubKey is if to protect it in case the strength of that key is ever reduced in the future. 

What are you talking about?  How do you weaken the stregnth of the security by exposing the public key.  Asymmetric cryptography is built around the notion that you must expose the public key.  Doing so is a key (pun intended) part of the process.  You assume NO security around the public key and protect the private key.


Also keep in mind that is 128 Bit keys become weak, then there is a bigger problem than Bitcoin wallets.

Please read.  I said explicitly that 128 bits of security is beyond brute force for both current and all conceivable future classical computing.   However that doesn't mean that ECDSA will always have 128 bit security (emphasis to the portion you quoted and ignored).

What is the strength of a 256 bit ECDSA public key if the same k value is used for multiple transactions? 0 bits
What is the strength of a 256 bit ECSDA public key in the safe of a QC implementing Shor's algorithm? Potentially very low
What is the strenght of a 256 bit ECSA public key if weaknesses are exposed which reduce the effective security of the cipher?  <128 bits (how low depends on how severe the flaw)

So while 128 bit strength is beyond brute force there is no guarantee that both today and in the future that secp256k1 will have 128 bit security.  History is full of ciphers which have degraded security.  Some degraded to a point of only academic curiosity (say 112 bits is degraded but there is no economical attack) and some degraded to a point where attacks became trivial.

Most notably in the face of flawed k value selection (Android RNG, bitcoin.js, etc) re-used addresses had an effective security of 0 bits while addresses which were not re-used (pubkey remained unknown) had 160 bits of security.

Same wallet, same set of keys, same implementation and the security varied from 0 bits to 160 bits based solely on if the key had be re-used.  Yes I would call that a reduction in security.

[Peter R]

I most agree with your assesment with the exception of "never".  Never is a very long time and I believe Bitcoin will need to be extended to more secure cryptographic primitives on a long enough timeline.

"Never" was purposely provocative.  I do agree with your assessment that given enough time bitcoin will need to be extended to more secure cryptographic primitives.  But I think that any weaknesses will emerge very slowly such that by the time it is feasible to attack one of those 9 rich addresses, the funds will be protected by better security.  

Still I would point out that known public key and leaking private key are not mutually exclusive.   The most notable developer error involves repeat k values.  Repeat k values can only apply in an address reuse scenario.  If your wallet has a flaw which leads to a repeat k value you are insulated from that risk by not reusing addresses.   That is why I likened the PubKeyHash as a secondary safety.  Sure if the primary security system is flawless against all current and future threats then there is no need for a second safety.  I have never needed my backup chute when skydiving, and statistically I probably never will, that doesn't mean I jump with one chute though.

It is a fact that repeat k-value problems can only apply in address re-use scenarios, so I agree that address re-use introduces a new risk.  You've suggested deterministic k-values in the past [as per T. Pornin, “Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA),” from Request for Comments: 6979, ISSN: 2070-1721, August 2013] and hopefully we see a push in this direction.  

But here's why I like address re-use sometimes: when someone asks me for help getting set up with bitcoin, I normally create a laminated paper wallet for them (and a TrueCrypt back-up).  But I can see it in their eyes that they don't trust the paper wallet.  So what I invariably do is (a) send the paper wallet 0.1 BTC, (b) produce a signature using the paper wallet to spend that 0.1 BTC, (c) broadcast the TX to the network (their public key is now known), and (d) prove to them that this particular paper wallet works when they see the transaction confirmed.  We then load the paper wallet with additional funds.  

I know that this is not optimally secure, but the new user is actually more confident because they've already witnessed that this particular key works.  It seems people understand that the key can't "break" in the future because it's just a number, but how do you explain to someone that the key didn't come "broken" if you never test it?  I know you can sign some text and verify the ECDSA signature locally, but this only convinces me because I understand how bitcoin works.  It is not at all convincing to my mom, for instance.  

[jonald_fyookball]

As DeathAndTaxes pointed out, the security level is reduced from 160 bits to 128 bits when the public key is known.  This is fact.  Inspecting the 30 richest bitcoin addresses, I found 9 with publicly known public-keys, representing a total of 419,308 BTC.  The individuals and groups that control these address are obviously confident with 128-bit security and (IMO) the extremely-small risk of compromising secp256k1 by crypto-analysis or by breakthroughs in quantum computing.

Good point Peter.  that's a lot of coins for the "taking"

[DeathAndTaxes]

But here's why I like address re-use sometimes: when someone asks me for help getting set up with bitcoin, I normally create a laminated paper wallet for them (and a TrueCrypt back-up).  But I can see it in their eyes that they don't trust the paper wallet.  So what I invariably do is (a) send the paper wallet 0.1 BTC, (b) produce a signature using the paper wallet to spend that 0.1 BTC, (c) broadcast the TX to the network (their public key is now known), and (d) prove to them that this particular paper wallet works when they see the transaction confirmed.  We then load the paper wallet with additional funds.  

I know that this is not optimally secure, but the new user is actually more confident because they've already witnessed that this particular key works.  

Agreed.  I would never say address re-use should never occur.  Also for a small amount of funds the risk (and potential loss) is minimal.  Sometimes accepting lower security is an acceptable option.  The important part is making an informed decision.  At BitSimple we do allow address reuse on "deposit addresses" <gasp>.  There is no way to technically prohibit a user from depositing more than once.  If we ask them not to, some users will still do.  However we do periodically sweep deposit addresses and prevent reuse in the primary wallet.

[jbrnt]

I reuse my address all the time, but after reading this, i will consider retiring my main receiving address.

I believe brute forcing an address takes time. So, I assume it would still be safe to reuse an address over a short period of time. My address do not have much anyway.

[DeathAndTaxes]

I reuse my address all the time, but after reading this, i will consider retiring my main receiving address.

I believe brute forcing an address takes time. So, I assume it would still be save to reuse an address over a short period of time. My address do not have much anyway.

There is no risk of brute forcing an address.  PubKeys with 128 bit security are beyond brute force for both current and future classical computing.  The laws of physics protect the PubKey from brute force attacks, the PubKeyHash provides a secondary line of defense against other potential attacks (quantum computing, cryptanalysis of ECDSA, flawed k value generation, etc).  It is still a good idea to no reuse addresses but the possibility of someone by brute force generating the same private key is essentially for all practical purposes zero.

[jonald_fyookball]

I reuse my address all the time, but after reading this, i will consider retiring my main receiving address.

I believe brute forcing an address takes time. So, I assume it would still be save to reuse an address over a short period of time. My address do not have much anyway.

When i said coins for the "taking" (in quotes), I was being facetious. 
(If they can't take the 419,308 coins, they won't be coming after yours.)

[serje]

Why all the really interesting threads only get a few hundred views? Topic: re-use of addresses  (Read 726 times)

while the ponzies get thousands of thousands views

This is really one interesting topic! And you can actually learn something from it!

[BitCoinDream]

I can see the long tech discussions in the whole thread where the outcome is Dont use an address twice. Now just think how bad impact it will have on an average person in terms of use. It is like asking him to create a new email ID for every mail communication. I wonder, if an wallet can solve this problem ? Like the person will only provide a certain unique identity for send/receive and rest will be managed internally that he does not need to bother. Please note, the average Joe is more bothered about ease of use rather than security. And if the security is breached, he'll be the first to yell at us saying Bitcoin protocol is broken and we are all scammer.

Please think about it...

[DeathAndTaxes]

Like the person will only provide a certain unique identity for send/receive and rest will be managed internally

Those unique identifiers are called addresses.  Addresses are more like order numbers than email addresses.   Wallets do manage this internally for users.   They can request a new address, the wallet keeps track of all the private keys and when the user wants to spend funds he just says how much and the wallet finds the set of unspent outputs corresponding to those multiple addresses that have sufficient value for the transaction.

[BitCoinDream]

Like the person will only provide a certain unique identity for send/receive and rest will be managed internally

Those unique identifiers are called addresses.  Addresses are more like order numbers than email addresses.   Wallets do manage this internally for users.   They can request a new address, the wallet keeps track of all the private keys and when the user wants to spend funds he just says how much and the wallet finds the set of unspent outputs corresponding to those multiple addresses that have sufficient value for the transaction.

So he'll only receive & never send ?

[jonald_fyookball]

I can see the long tech discussions in the whole thread where the outcome is Dont use an address twice. Now just think how bad impact it will have on an average person in terms of use. It is like asking him to create a new email ID for every mail communication. I wonder, if an wallet can solve this problem ? Like the person will only provide a certain unique identity for send/receive and rest will be managed internally that he does not need to bother. Please note, the average Joe is more bothered about ease of use rather than security. And if the security is breached, he'll be the first to yell at us saying Bitcoin protocol is broken and we are all scammer.

Please think about it...

I don't think you read that carefully.

the outcome was:  don't use an address twice but if you do, it probably won't matter as long as its not a flawed wallet.  That being said, many wallets do automatically give you new addresses.

[DeathAndTaxes]

Like the person will only provide a certain unique identity for send/receive and rest will be managed internally

Those unique identifiers are called addresses.  Addresses are more like order numbers than email addresses.   Wallets do manage this internally for users.   They can request a new address, the wallet keeps track of all the private keys and when the user wants to spend funds he just says how much and the wallet finds the set of unspent outputs corresponding to those multiple addresses that have sufficient value for the transaction.

So he'll only receive & never send ?

When he sends the only address which needs to be provided is the receivers.  The wallet internally (just like you asked) figures out which of the unspent outputs to reference in the new transaction.  From the users point it is just send X to Y.

[Valle]

ok, so I understand that you shouldn't re-use an address
because then people will see the public key rather than
the hex-encoded hash, and it weakens the security
from 160 bit to 128 bit...

But, can you receive multiple transactions at the same
address (as long as you dont send) with no security
compromise?

Private key is 256 bit. Public key is 256 bit too. Hash of public key is 160 bit. How revealing of public key (256 bit) reduce strength to 128 bit? It's reduced to 256 bit ECDSA. I fail to see the 128 bit strength :-)

[DeathAndTaxes]

ok, so I understand that you shouldn't re-use an address
because then people will see the public key rather than
the hex-encoded hash, and it weakens the security
from 160 bit to 128 bit...

But, can you receive multiple transactions at the same
address (as long as you dont send) with no security
compromise?

Private key is 256 bit. Public key is 256 bit too. Hash of public key is 160 bit. How revealing of public key (256 bit) reduce strength to 128 bit? It's reduced to 256 bit ECDSA. I fail to see the 128 bit strength :-)

The bit strength of a key refers to the equivalent strength of a symmetric key of that length.  The key strength is only equal to the length of the key for uncompromised symmetric ciphers (and usually hashing algorithms).  For public key cryptography, the bit strength will always be less than the key size.  For ECDSA it is 1/2 the key length if the algorithm is uncompromised.   That means the 256 bit ECDSA keys used in Bitcoin have 128 bit security.  As algorithms are weakened through cryptanalysis the effective security sometimes drops below the initial spec.


I don't know why Satoshi chose a 160 bit PubKeyHash to pair with a 256 bit PubKey (128 bit effective security).  It probably would have made more sense to either use 128 bit PubKeyHash and 256 bit ECDSA (same security and shorter addresses) or 160 bit PubKeyHash and 320 bit ECDSA (higher key security for same size addresses).  As a side note sometimes people ask why was ECDSA chosen instead of RSA? To achieve 128 bit security using RSA would require a 3,072 bit public key and that would mean very large transactions.  It gets even worse if higher security keys are needed in the future.  For ECDSA the security is linear and thus double security (256 bit) could be achieved with double the key size (512 bit) but for RSA to achieve 256 bit security would require a 15,384 bit key.

[Valle]

ok, so I understand that you shouldn't re-use an address
because then people will see the public key rather than
the hex-encoded hash, and it weakens the security
from 160 bit to 128 bit...

But, can you receive multiple transactions at the same
address (as long as you dont send) with no security
compromise?

Private key is 256 bit. Public key is 256 bit too. Hash of public key is 160 bit. How revealing of public key (256 bit) reduce strength to 128 bit? It's reduced to 256 bit ECDSA. I fail to see the 128 bit strength :-)

The bit strength of a key refers to the equivalent strength of a symmetric key of that length.  The key strength is only equal to the length of the key for uncompromised symmetric ciphers (and usually hashing algorithms).  For public key cryptography, the bit strength will always be less than the key size.  For ECDSA it is 1/2 the key length.  For 256 bit ECDSA keys used in Bitcoin that means 128 bit security.  I don't know why Satoshi chose a 160 bit PubKeyHash as a 128 bit one would be sufficient and would result in shorter addresses.

As a side note sometimes people ask why ECC, why not RSA? To achieve 128 bit security using RSA would require a 3,072 bit public key and that would mean very large transactions.

Can you give any links what proves the point please? I can understand that hashing to 160 bit means that there are many ECDSA 256bits what corresponds to an address, but saying that real security of ECDSA is 340282366920938463463374607431768211456 times lower than it's key size sounds... strange.