Leandro Coutinho [ARCHIVE] on Nostr: đź“… Original date posted:2017-02-25 đź“ť Original message:Google recommeds "migrate ...
đź“… Original date posted:2017-02-25
đź“ť Original message: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 at lists.linuxfoundation.org> escreveu:
> On Feb 24, 2017, at 7:01 PM, Peter Todd <pete at petertodd.org> 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?
>
> SHA1 is insecure because the SHA1 algorithm is insecure, not because
160bits isn't enough.
>
> AFAIK there aren't any known weaknesses in RIPEMD160,
…so far. I wonder how long that vacation will last?
> but it also hasn't been
> as closely studied as more common hash algorithms.
...but we can be sure that it will be, since the dollar value held in
existing utxos continues to increase...
> That said, Bitcoin uses
> RIPEMD160(SHA256(msg)), which may make creating collisions harder if an
attack
> is found than if it used RIPEMD160 alone.
Does that offer any greater protection? That’s not so clear to me as the
outputs (at least for p2pkh) only verify the public key against the final
20 byte hash. Specifically, in the first (notional) case the challenge
would be to find a private key that has a public key that hashes to the
final hash. In the second (realistic) case, you merely need to add the
sha256 hash into the problem, which doesn’t seem to me to increase the
difficulty by any significant amount?
/s
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170225/30468d23/attachment.html>;
đź“ť Original message: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 at lists.linuxfoundation.org> escreveu:
> On Feb 24, 2017, at 7:01 PM, Peter Todd <pete at petertodd.org> 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?
>
> SHA1 is insecure because the SHA1 algorithm is insecure, not because
160bits isn't enough.
>
> AFAIK there aren't any known weaknesses in RIPEMD160,
…so far. I wonder how long that vacation will last?
> but it also hasn't been
> as closely studied as more common hash algorithms.
...but we can be sure that it will be, since the dollar value held in
existing utxos continues to increase...
> That said, Bitcoin uses
> RIPEMD160(SHA256(msg)), which may make creating collisions harder if an
attack
> is found than if it used RIPEMD160 alone.
Does that offer any greater protection? That’s not so clear to me as the
outputs (at least for p2pkh) only verify the public key against the final
20 byte hash. Specifically, in the first (notional) case the challenge
would be to find a private key that has a public key that hashes to the
final hash. In the second (realistic) case, you merely need to add the
sha256 hash into the problem, which doesn’t seem to me to increase the
difficulty by any significant amount?
/s
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170225/30468d23/attachment.html>;