Add Comparison-Based Attacks To Reasons Not To Reuse Keys

_includes/guide_transactions.md:

* Expand the security part of the Avoiding Key Reuse subsection to also
  describe why creating more than one signature with the same private
  key might be a problem. Based on feedback from @luke-jr. Thanks!
This commit is contained in:
David A. Harding 2014-05-11 10:34:43 -04:00
parent 4c3046fbb4
commit cc2105debc

View file

@ -595,12 +595,24 @@ such as CoinJoin or merge avoidance, to make it extremely difficult to
use the block chain by itself to reliably track how users receive and use the block chain by itself to reliably track how users receive and
spend their satoshis. spend their satoshis.
Avoiding key reuse in combination with P2PH or P2SH addresses also Avoiding key reuse can also provide security against attacks which might
prevents anyone from seeing the user's ECDSA public key until he spends allow reconstruction of private keys from public keys (hypothesized) or
the satoshis sent to those addresses. This, combined with the block from signature comparisons (possible today under certain circumstances
chain, provides security against hypothetical future attacks which may described below, with more general attacks hypothesized).
allow reconstruction of private keys from public keys in a matter of
hours, days, months, or years (but not any faster). 1. Unique (non-reused) P2PH and P2SH addresses protect against the first
type of attack by keeping ECDSA public keys hidden (hashed) until the
first time satoshis stored in those addresses are spent, so attacks
are effectively useless unless they can reconstruct private keys in
less than the hour or two it takes for a transaction to be well
protected by the block chain.
2. Unique (non-reused) private keys protect against the second type of
attack by only generating one signature per private key, so attackers
never get a subsequent signature to use in comparison-based attacks.
Existing comparison-based attacks are only practical today when there
is an error in the ECDSA implementation or a lack of entropy in one
of the values used for signing.
So, for both privacy and security, we encourage you to build your So, for both privacy and security, we encourage you to build your
applications to avoid public key reuse and, when possible, to discourage applications to avoid public key reuse and, when possible, to discourage