Merge pull request #395 from harding/docsupdate-sigsecurity

Devel Docs: Add Comparison-Based Attacks To Reasons Not To Reuse Keys
This commit is contained in:
David A. Harding 2014-05-13 09:12:47 -04:00
commit 70d871d43e

View file

@ -595,12 +595,25 @@ 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 sent to 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
insufficient entropy is used in signing or when the entropy used
is exposed by some means, such as a
[side-channel attack](https://en.wikipedia.org/wiki/Side_channel_attack).
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