From: Gavin Andresen <gavinandresen@gmail•com>
To: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Time to worry about 80-bit collision attacks or not?
Date: Tue, 12 Jan 2016 07:08:18 -0500 [thread overview]
Message-ID: <CABsx9T3UTSnLx_BGfMTrQB1=vR9Bdd8OJvSXy=++-_=wfv7+uw@mail.gmail.com> (raw)
In-Reply-To: <CAE-z3OVuAMdpZb+-C4JS_6FEreFohOMAsWpepgE1L5YoBOw4iA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1301 bytes --]
I'm convinced-- it is a good idea to worry about 80-bit collision attacks
now.
Thanks to all the people smarter than me who contributed to this
discussion, I learned a lot about collision attacks that I didn't know
before.
Would this be a reasonable "executive summary" :
If you are agreeing to lock up funds with somebody else, and they control
what public key to use, you are susceptible to collision attacks.
It is very likely an 80-bit-collision-in-ten-minutes attack will cost less
than $1million in 10 to twenty years (possibly sooner if there are crypto
breaks in that time).
If you don't trust the person with whom you're locking up funds and you're
locking up a significant amount of money (tens of millions of dollars
today, tens of thousands of dollars in a few years):
Then you should avoid using pay-to-script-hash addresses and instead use
the payment protocol and "raw" multisig outputs.
AND/OR
Have them give you a hierarchical deterministic (BIP32) seed, and derive a
public key for them to use.
----------
Following the security in depth and validate all input secure coding
principles would mean doing both-- avoid p2sh AND have all parties to a
transaction exchange HD seeds, add randomness, and use the resulting public
keys in the transaction.
--
--
Gavin Andresen
[-- Attachment #2: Type: text/html, Size: 1722 bytes --]
next prev parent reply other threads:[~2016-01-12 12:08 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-07 19:02 Gavin Andresen
2016-01-07 19:13 ` Matt Corallo
2016-01-07 19:19 ` Adam Back
2016-01-07 20:56 ` Dave Scotese
2016-01-07 21:06 ` Gavin Andresen
2016-01-07 22:56 ` Ethan Heilman
2016-01-07 23:39 ` Gavin Andresen
2016-01-08 1:26 ` Matt Corallo
2016-01-08 1:54 ` Gavin Andresen
2016-01-08 17:38 ` Pieter Wuille
2016-01-08 18:41 ` Peter Todd
2016-01-07 20:40 ` Ethan Heilman
2016-01-07 23:52 ` Pieter Wuille
2016-01-08 1:00 ` Gavin Andresen
2016-01-08 1:27 ` Watson Ladd
2016-01-08 3:30 ` Rusty Russell
2016-01-08 3:41 ` Matt Corallo
2016-01-08 12:02 ` Rusty Russell
2016-01-08 12:38 ` Gavin Andresen
2016-01-08 14:34 ` Watson Ladd
2016-01-08 15:26 ` Adam Back
2016-01-08 15:33 ` Anthony Towns
2016-01-08 15:46 ` Gavin Andresen
2016-01-08 15:50 ` Gavin Andresen
2016-01-08 15:59 ` Gavin Andresen
2016-01-11 20:32 ` Jorge Timón
2016-01-08 16:06 ` Gavin Andresen
2016-01-11 3:57 ` Rusty Russell
2016-01-11 6:57 ` Peter Todd
2016-01-11 23:57 ` Tier Nolan
2016-01-12 0:00 ` Tier Nolan
2016-01-12 12:08 ` Gavin Andresen [this message]
2016-01-12 23:22 ` Zooko Wilcox-O'Hearn
2016-01-08 18:52 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CABsx9T3UTSnLx_BGfMTrQB1=vR9Bdd8OJvSXy=++-_=wfv7+uw@mail.gmail.com' \
--to=gavinandresen@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox