Re: [bitcoin-dev] SHA1 collisions make Git vulnerable to attakcs by third-parties, not just repo maintainers

> On Feb 26, 2017, at 12:36 AM, Pieter Wuille wrote: > > The 80-bit collision attack only applies to jointly constructed addresses > like multisig P2SH, not single-key ones. That’s the part I’m less convinced about, and why I asked the original question re SHA1 vs

Re: [bitcoin-dev] SHA1 collisions make Git vulnerable to attakcs by third-parties, not just repo maintainers

Hi Pieter, > On Feb 25, 2017, at 4:14 PM, Pieter Wuille wrote: > > Any alternative to move us away from RIPEMD160 would require: > “Any alternative”? What about reverting to: [, OP_CHECKSIG] or perhaps later [<“compressed” public_key>, OP_CHECKSIG] This appears

Re: [bitcoin-dev] SHA1 collisions make Git vulnerable to attakcs by third-parties, not just repo maintainers

On Feb 25, 2017 22:26, "Steve Davis" wrote: Hi Pieter, > On Feb 25, 2017, at 4:14 PM, Pieter Wuille wrote: > > Any alternative to move us away from RIPEMD160 would require: > “Any alternative”? What about reverting to: [,

[bitcoin-dev] Moving towards user activated soft fork activation

Some thoughts about the activation mechanism for soft forks. In the past we used IsSuperMajority and currently use BIP9 as soft fork activation methods, where a supermajority of hashrate triggers nodes to begin enforcing new rules. Hashrate based activation is convenient because it is the

Re: [bitcoin-dev] SHA1 collisions make Git vulnerable to attakcs by third-parties, not just repo maintainers

If people split their bitcoins in multiple addresses, then maybe there would be no need to worry(?), because the computational cost would be higher than what the attacker would get. >From Google: https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html *Here are some numbers

Re: [bitcoin-dev] SHA1 collisions make Git vulnerable to attakcs by third-parties, not just repo maintainers

I strongly encourage Bitcoin to move from 80-bit collision resistance (RIPEMD-160) to 128-bit collision resistance (SHA-256). On Sat, Feb 25, 2017 at 5:14 PM, Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > > On Feb 25, 2017 14:09, "Steve Davis via bitcoin-dev"

Re: [bitcoin-dev] SHA1 collisions make Git vulnerable to attakcs by third-parties, not just repo maintainers

On Feb 25, 2017 14:09, "Steve Davis via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: Hi Peter, I really, really don’t want to get into it but segwit has many aspects that are less appealing, not least of which being the amount of time it would take to reach the critical mass.

Re: [bitcoin-dev] SHA1 collisions make Git vulnerable to attakcs by third-parties, not just repo maintainers

Hi Peter, > On Feb 25, 2017, at 3:40 PM, Peter Todd wrote: > > On Sat, Feb 25, 2017 at 03:34:33PM -0600, Steve Davis wrote: >> Yea, well. I don’t think it is ethical to post instructions without an >> associated remediation (BIP) if you don’t see the potential attack. > >

Re: [bitcoin-dev] SHA1 collisions make Git vulnerable to attakcs by third-parties, not just repo maintainers

Yea, well. I don’t think it is ethical to post instructions without an associated remediation (BIP) if you don’t see the potential attack. I was rather hoping that we could have a fuller discussion of what the best practical response would be to such an issue? > On Feb 25, 2017, at 3:21 PM,

Re: [bitcoin-dev] SHA1 collisions make Git vulnerable to attakcs by third-parties, not just repo maintainers

On Sat, Feb 25, 2017 at 03:34:33PM -0600, Steve Davis wrote: > Yea, well. I don’t think it is ethical to post instructions without an > associated remediation (BIP) if you don’t see the potential attack. I can't agree with you at all there: we're still at the point where the computational costs

Re: [bitcoin-dev] SHA1 collisions make Git vulnerable to attakcs by third-parties, not just repo maintainers

I was under the impression that RIPEMD160(SHA256(msg)) is used to turn a PUBLIC key (msg) into a bitcoin address, so yeah, you could identify ANOTHER (or the same, I guess - how would you know?) public key that has the same bitcoin address if RIPEMD-160 collisions are easy, but I don't see how

Re: [bitcoin-dev] SHA1 collisions make Git vulnerable to attakcs by third-parties, not just repo maintainers

On Sat, Feb 25, 2017 at 11:12 AM, Peter Todd via bitcoin-dev wrote: > On Sat, Feb 25, 2017 at 11:10:02AM -0500, Ethan Heilman via bitcoin-dev wrote: >> >SHA1 is insecure because the SHA1 algorithm is insecure, not because >> 160bits isn't enough. >> >> I

Re: [bitcoin-dev] SHA1 collisions make Git vulnerable to attakcs by third-parties, not just repo maintainers

On Sat, Feb 25, 2017 at 03:53:12PM -0500, Russell O'Connor wrote: > On Sat, Feb 25, 2017 at 2:12 PM, Peter Todd via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > On Sat, Feb 25, 2017 at 11:10:02AM -0500, Ethan Heilman via bitcoin-dev > > wrote: > > > >SHA1 is insecure

Re: [bitcoin-dev] SHA1 collisions make Git vulnerable to attakcs by third-parties, not just repo maintainers

On Sat, Feb 25, 2017 at 12:42:56PM -0800, Watson Ladd wrote: > On Sat, Feb 25, 2017 at 11:12 AM, Peter Todd via bitcoin-dev > wrote: > > On Sat, Feb 25, 2017 at 11:10:02AM -0500, Ethan Heilman via bitcoin-dev > > wrote: > >> >SHA1 is insecure because the

Re: [bitcoin-dev] SHA1 collisions make Git vulnerable to attakcs by third-parties, not just repo maintainers

On Sat, Feb 25, 2017 at 11:10:02AM -0500, Ethan Heilman via bitcoin-dev wrote: > >SHA1 is insecure because the SHA1 algorithm is insecure, not because > 160bits isn't enough. > > I would argue that 160-bits isn't enough for collision resistance. Assuming > RIPEMD-160(SHA-256(msg)) has no flaws

Re: [bitcoin-dev] SHA1 collisions make Git vulnerable to attakcs by third-parties, not just repo maintainers

We should distinguish collision resistance from 2nd pre-image resistance, in general. As previously written, we should care both hash output length and algorithm itself. The weakness of SHA-0 (preliminary version of SHA-1) was reported in 2004, then many research on the structure of SHA-1 were

Re: [bitcoin-dev] SHA1 collisions make Git vulnerable to attakcs by third-parties, not just repo maintainers

>You have to not only produce a ripemd160 collision, you have to produce a collision that is also a valid sha-256 hash - and that's much much much more difficult. I agree that merely finding a collision in RIPEMD-160 will be hard to use in Bitcoin. However finding a collision in

Re: [bitcoin-dev] SHA1 collisions make Git vulnerable to attakcs by third-parties, not just repo maintainers

On 02/25/2017 08:10 AM, Ethan Heilman via bitcoin-dev wrote: SHA1 is insecure because the SHA1 algorithm is insecure, not because 160bits isn't enough. I would argue that 160-bits isn't enough for collision resistance. Assuming RIPEMD-160(SHA-256(msg)) has no flaws (i.e. is a random oracle),

Re: [bitcoin-dev] SHA1 collisions make Git vulnerable to attakcs by third-parties, not just repo maintainers

>SHA1 is insecure because the SHA1 algorithm is insecure, not because 160bits isn't enough. I would argue that 160-bits isn't enough for collision resistance. Assuming RIPEMD-160(SHA-256(msg)) has no flaws (i.e. is a random oracle), collisions can be generated in 2^80 queries (actually detecting

Re: [bitcoin-dev] SHA1 collisions make Git vulnerable to attakcs by third-parties, not just repo maintainers

Google recommeds "migrate to safer cryptographic hashes such as SHA-256 and SHA-3" It does not mention RIPEMD-160 https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html?m=1 Em 25/02/2017 10:47, "Steve Davis via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org>

Re: [bitcoin-dev] SHA1 collisions make Git vulnerable to attakcs by third-parties, not just repo maintainers

> On Feb 24, 2017, at 7:01 PM, Peter Todd wrote: > > On Fri, Feb 24, 2017 at 05:49:36PM -0600, Steve Davis via bitcoin-dev wrote: >> If the 20 byte SHA1 is now considered insecure (with good reason), what >> about RIPEMD-160 which is the foundation of Bitcoin addresses? >