📅 Original date posted:2016-01-08
📝 Original message:Tricky choice. On the one hand I had spotted this too before and maybe
one or two more exceptions to bitcoin's 128-bit security target and
been vaguely tut-tutting about them in the background. It's kind of a
violation of crypto rule of thumb that you want to balance things and
not have odd weak points as Watson was implying, it puts you closer to
the margin if there is a slip or other problem so you have an
imbalanced crypto format.
On the other hand it's not currently a problem as such and it's less
change and slightly more compact.
RIPEMD probably is less well reviewed than SHA2. However SHA1 has
problems, and SHA2 is a bigger SHA1 basically so, hence the NIST
motivation for SHA3 designed to fix the design flaw in SHA1 (and SHA2
in principle).
So then if we agree with this rule of thumb (and not doing so would
fly against best practices which we probably shouldnt look to do in
such a security focussed domain) then what this discussion is more
about is when is a good time to write down tech debt.
I think that comes to segregated-witness itself which writes down a
tidily organised by lines of code robust fix to a bunch of long
standing problems.
Doing a 2MB hard-fork in comparison fixes nothing really. Leaving
known issues to bake in for another N years eventually builds up on
you (not even in security just in software engineering) as another
rule of thumb. I mean if we dont fix it now that we are making a
change that connects, when will we?
In software projects I ran we always disguised the cost of tech-debt
as non-negotiable baked into our estimates without a line item to
escape the PHB syndrome of haggling for features instead of tech debt
(which is _never_ a good idea:)
Pragmatism vs refactoring as you go.
But for scale I think segregated-witness does offer the intriguing
next step of being able to do 2 of 2, 3 of 3 and N of N which give
size of one sig multisig (indistinguishable even for privacy) as well
as K of N key tree sigs, which are also significantly more compact.
There was also the other thing I mentioned further up the thread that
if we want to take an approach of living with little bit of bloat from
getting back to a universal 128-bit target, there are still some
fixable bloat things going on:
a) sending pubKey in the signature vs recovery (modulo interference
with Schnorr batch verify compatibility*);
b) using the PubKey instead of PKH in the ScriptPubKey, though that
loses the nice property of of not having the key to do DL attacks on
until the signed transaction is broadcast;
c) I think there might be a way to combine hash & PubKey to keep the
delayed PubKey publication property and yet still save the bloat of
having both.
* I did suggest to Pieter that you could let the miner decide to forgo
Schnorr batch verifiability to get compaction from recovery - the pub
key could be optionally elided from the scriptSig serialisation by the
miner.
The other thing we could consider is variable sized hashes (& a few
pubkey size choices) that is software complexity however. We might be
better of focussing on the bigger picture like IBLT/weak-blocks and
bigger wins like MAST, multiSig Schnorr & key tree sigs.
Didnt get time to muse on c) but a nice crypto question for someone :)
Another thing to note is combining has been known to be fragile to bad
interactions or unexpected behaviours. This paper talks about things
tradeoffs and weaknesses in hash combiners.
http://tuprints.ulb.tu-darmstadt.de/2094/1/thesis.lehmann.pdf
Weak concept NACK I think for losing a cleanup opportunity to store it
up for the future when there is a reasonable opportunity to fix it?
Adam
On 8 January 2016 at 15:34, Watson Ladd via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Fri, Jan 8, 2016 at 4:38 AM, Gavin Andresen via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> On Fri, Jan 8, 2016 at 7:02 AM, Rusty Russell <rusty at rustcorp.com.au> wrote:
>>>
>>> Matt Corallo <lf-lists at mattcorallo.com> writes:
>>> > Indeed, anything which uses P2SH is obviously vulnerable if there is
>>> > an attack on RIPEMD160 which reduces it's security only marginally.
>>>
>>> I don't think this is true? Even if you can generate a collision in
>>> RIPEMD160, that doesn't help you since you need to create a specific
>>> SHA256 hash for the RIPEMD160 preimage.
>>>
>>> Even a preimage attack only helps if it leads to more than one preimage
>>> fairly cheaply; that would make grinding out the SHA256 preimage easier.
>>> AFAICT even MD4 isn't this broken.
>>
>>
>> It feels like we've gone over that before, but I can never remember where or
>> when. I believe consensus was that if we were using the broken MD5 in all
>> the places we use RIPEMD160 we'd still be secure today because of Satoshi's
>> use of nested hash functions everywhere.
>>
>>>
>>> But just with Moore's law (doubling every 18 months), we'll worry about
>>> economically viable attacks in 20 years.[1]
>>>
>>>
>>> That's far enough away that I would choose simplicity, and have all SW
>>> scriptPubKeys simply be "<0> RIPEMD(SHA256(WP))" for now, but it's
>>> not a no-brainer.
>>
>>
>> Lets see if I've followed the specifics of the collision attack correctly,
>> Ethan (or somebody) please let me know if I'm missing something:
>>
>> So attacker is in the middle of establishing a payment channel with
>> somebody. Victim gives their public key, attacker creates the innocent
>> fund-locking script '2 V A 2 CHECKMULTISIG' (V is victim's public key, A is
>> attacker's) but doesn't give it to the victim yet.
>>
>> Instead they then generate about 2^81scripts that are some form of
>> pay-to-attacker ....
>> ... wait, no that doesn't work, because SHA256 is used as the inner hash
>> function. They'd have to generate 2^129 to find a cycle in SHA256.
>
> For 2^80 they simply generate 2^80 scripts that look innocent, and
> 2^80 that are not. With high probability there is a collision. I agree
> that most cryptanalysis won't work because of the nesting, but 2^80 is
> not good.
>>
>> Instead, they .. what? I don't see a viable attack unless RIPEMD160 and
>> SHA256 (or the combination) suffers a cryptographic break.
>>
>>
>> --
>> --
>> Gavin Andresen
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
>
> --
> "Man is born free, but everywhere he is in chains".
> --Rousseau.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Adam Back [ARCHIVE] /
npub1ac…lswfj
2023-06-07 17:47:44
in reply to nevent1q…thcy
Author Public Key
npub1ac86vemj7ce5z8jyxt39rna3tvwql6xd30ha3vxcd6esysp23d9qrlswfjPublished at
2023-06-07 17:47:44Event JSON
{
"id": "3cc315c675e20a18d5e22a5023c6929168b630df9c3ddabbed6aa3dddd32a3ea",
"pubkey": "ee0fa66772f633411e4432e251cfb15b1c0fe8cd8befd8b0d86eb302402a8b4a",
"created_at": 1686160064,
"kind": 1,
"tags": [
[
"e",
"e1f46f49861d474f81d81bf43d690af02c9b35e1c9c4fe5cc415112a34c1c041",
"",
"root"
],
[
"e",
"fd8da4e3e82cf944375264c5c0eb0b2f193ca901efe03f2c70f1e80a7e8ca4df",
"",
"reply"
],
[
"p",
"79da9465d0e005bd619ff8b66831e69cf4518e5322281ec55df2bd63966dbc4c"
]
],
"content": "📅 Original date posted:2016-01-08\n📝 Original message:Tricky choice. On the one hand I had spotted this too before and maybe\none or two more exceptions to bitcoin's 128-bit security target and\nbeen vaguely tut-tutting about them in the background. It's kind of a\nviolation of crypto rule of thumb that you want to balance things and\nnot have odd weak points as Watson was implying, it puts you closer to\nthe margin if there is a slip or other problem so you have an\nimbalanced crypto format.\n\nOn the other hand it's not currently a problem as such and it's less\nchange and slightly more compact.\n\nRIPEMD probably is less well reviewed than SHA2. However SHA1 has\nproblems, and SHA2 is a bigger SHA1 basically so, hence the NIST\nmotivation for SHA3 designed to fix the design flaw in SHA1 (and SHA2\nin principle).\n\nSo then if we agree with this rule of thumb (and not doing so would\nfly against best practices which we probably shouldnt look to do in\nsuch a security focussed domain) then what this discussion is more\nabout is when is a good time to write down tech debt.\n\nI think that comes to segregated-witness itself which writes down a\ntidily organised by lines of code robust fix to a bunch of long\nstanding problems.\n\nDoing a 2MB hard-fork in comparison fixes nothing really. Leaving\nknown issues to bake in for another N years eventually builds up on\nyou (not even in security just in software engineering) as another\nrule of thumb. I mean if we dont fix it now that we are making a\nchange that connects, when will we?\n\nIn software projects I ran we always disguised the cost of tech-debt\nas non-negotiable baked into our estimates without a line item to\nescape the PHB syndrome of haggling for features instead of tech debt\n(which is _never_ a good idea:)\n\nPragmatism vs refactoring as you go.\n\nBut for scale I think segregated-witness does offer the intriguing\nnext step of being able to do 2 of 2, 3 of 3 and N of N which give\nsize of one sig multisig (indistinguishable even for privacy) as well\nas K of N key tree sigs, which are also significantly more compact.\n\nThere was also the other thing I mentioned further up the thread that\nif we want to take an approach of living with little bit of bloat from\ngetting back to a universal 128-bit target, there are still some\nfixable bloat things going on:\na) sending pubKey in the signature vs recovery (modulo interference\nwith Schnorr batch verify compatibility*);\nb) using the PubKey instead of PKH in the ScriptPubKey, though that\nloses the nice property of of not having the key to do DL attacks on\nuntil the signed transaction is broadcast;\nc) I think there might be a way to combine hash \u0026 PubKey to keep the\ndelayed PubKey publication property and yet still save the bloat of\nhaving both.\n\n* I did suggest to Pieter that you could let the miner decide to forgo\nSchnorr batch verifiability to get compaction from recovery - the pub\nkey could be optionally elided from the scriptSig serialisation by the\nminer.\n\nThe other thing we could consider is variable sized hashes (\u0026 a few\npubkey size choices) that is software complexity however. We might be\nbetter of focussing on the bigger picture like IBLT/weak-blocks and\nbigger wins like MAST, multiSig Schnorr \u0026 key tree sigs.\n\nDidnt get time to muse on c) but a nice crypto question for someone :)\n\nAnother thing to note is combining has been known to be fragile to bad\ninteractions or unexpected behaviours. This paper talks about things\ntradeoffs and weaknesses in hash combiners.\nhttp://tuprints.ulb.tu-darmstadt.de/2094/1/thesis.lehmann.pdf\n\nWeak concept NACK I think for losing a cleanup opportunity to store it\nup for the future when there is a reasonable opportunity to fix it?\n\nAdam\n\n\nOn 8 January 2016 at 15:34, Watson Ladd via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e On Fri, Jan 8, 2016 at 4:38 AM, Gavin Andresen via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e On Fri, Jan 8, 2016 at 7:02 AM, Rusty Russell \u003crusty at rustcorp.com.au\u003e wrote:\n\u003e\u003e\u003e\n\u003e\u003e\u003e Matt Corallo \u003clf-lists at mattcorallo.com\u003e writes:\n\u003e\u003e\u003e \u003e Indeed, anything which uses P2SH is obviously vulnerable if there is\n\u003e\u003e\u003e \u003e an attack on RIPEMD160 which reduces it's security only marginally.\n\u003e\u003e\u003e\n\u003e\u003e\u003e I don't think this is true? Even if you can generate a collision in\n\u003e\u003e\u003e RIPEMD160, that doesn't help you since you need to create a specific\n\u003e\u003e\u003e SHA256 hash for the RIPEMD160 preimage.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Even a preimage attack only helps if it leads to more than one preimage\n\u003e\u003e\u003e fairly cheaply; that would make grinding out the SHA256 preimage easier.\n\u003e\u003e\u003e AFAICT even MD4 isn't this broken.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e It feels like we've gone over that before, but I can never remember where or\n\u003e\u003e when. I believe consensus was that if we were using the broken MD5 in all\n\u003e\u003e the places we use RIPEMD160 we'd still be secure today because of Satoshi's\n\u003e\u003e use of nested hash functions everywhere.\n\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e But just with Moore's law (doubling every 18 months), we'll worry about\n\u003e\u003e\u003e economically viable attacks in 20 years.[1]\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e That's far enough away that I would choose simplicity, and have all SW\n\u003e\u003e\u003e scriptPubKeys simply be \"\u003c0\u003e RIPEMD(SHA256(WP))\" for now, but it's\n\u003e\u003e\u003e not a no-brainer.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e Lets see if I've followed the specifics of the collision attack correctly,\n\u003e\u003e Ethan (or somebody) please let me know if I'm missing something:\n\u003e\u003e\n\u003e\u003e So attacker is in the middle of establishing a payment channel with\n\u003e\u003e somebody. Victim gives their public key, attacker creates the innocent\n\u003e\u003e fund-locking script '2 V A 2 CHECKMULTISIG' (V is victim's public key, A is\n\u003e\u003e attacker's) but doesn't give it to the victim yet.\n\u003e\u003e\n\u003e\u003e Instead they then generate about 2^81scripts that are some form of\n\u003e\u003e pay-to-attacker ....\n\u003e\u003e ... wait, no that doesn't work, because SHA256 is used as the inner hash\n\u003e\u003e function. They'd have to generate 2^129 to find a cycle in SHA256.\n\u003e\n\u003e For 2^80 they simply generate 2^80 scripts that look innocent, and\n\u003e 2^80 that are not. With high probability there is a collision. I agree\n\u003e that most cryptanalysis won't work because of the nesting, but 2^80 is\n\u003e not good.\n\u003e\u003e\n\u003e\u003e Instead, they .. what? I don't see a viable attack unless RIPEMD160 and\n\u003e\u003e SHA256 (or the combination) suffers a cryptographic break.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e --\n\u003e\u003e --\n\u003e\u003e Gavin Andresen\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\n\u003e\n\u003e\n\u003e --\n\u003e \"Man is born free, but everywhere he is in chains\".\n\u003e --Rousseau.\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev",
"sig": "44914a2373e162c2c39fb67506a293d74df34ae7c8b3dba895444d3eaaa76bf09bbf19bb55d6482f3c8b37389b3b1aaf32869cb7da136ccf5400159602ce25db"
}