From cc2105debc9b1ea370538cb176da505ce983b92a Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Sun, 11 May 2014 10:34:43 -0400 Subject: [PATCH 1/2] 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! --- _includes/guide_transactions.md | 24 ++++++++++++++++++------ 1 file changed, 18 insertions(+), 6 deletions(-) diff --git a/_includes/guide_transactions.md b/_includes/guide_transactions.md index 9f4e4041..1a152248 100644 --- a/_includes/guide_transactions.md +++ b/_includes/guide_transactions.md @@ -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 spend their satoshis. -Avoiding key reuse in combination with P2PH or P2SH addresses also -prevents anyone from seeing the user's ECDSA public key until he spends -the satoshis sent to those addresses. This, combined with the block -chain, provides security against hypothetical future attacks which may -allow reconstruction of private keys from public keys in a matter of -hours, days, months, or years (but not any faster). +Avoiding key reuse can also provide security against attacks which might +allow reconstruction of private keys from public keys (hypothesized) or +from signature comparisons (possible today under certain circumstances +described below, with more general attacks hypothesized). + +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 applications to avoid public key reuse and, when possible, to discourage From 1885c15ba31f4ef736e95eb95c50253cc5d91d1f Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Sun, 11 May 2014 13:46:03 -0400 Subject: [PATCH 2/2] Mention Side-Channel Attacks In Addition To Lack-Of-Entropy Attacks --- _includes/guide_transactions.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/_includes/guide_transactions.md b/_includes/guide_transactions.md index 1a152248..4de1a01d 100644 --- a/_includes/guide_transactions.md +++ b/_includes/guide_transactions.md @@ -602,7 +602,7 @@ described below, with more general attacks hypothesized). 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 + 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. @@ -610,9 +610,10 @@ described below, with more general attacks hypothesized). 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. + 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 applications to avoid public key reuse and, when possible, to discourage