To: bitcoin-dev@lists.linuxfoundation.org
References: <20170223181409.GA6085@savin.petertodd.org>
	<20170223212802.GA7608@savin.petertodd.org>
	<76fa5d76-6c54-e13e-7b55-a4409ef536f5@gmail.com>
	<1487930694.1528.1.camel@mmci.uni-saarland.de>
From: Aymeric Vitte <vitteaymeric@gmail.com>
Message-ID: <15848c1b-2873-35e8-0588-c636126257df@gmail.com>
Date: Fri, 24 Feb 2017 16:18:43 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.3; rv:45.0) Gecko/20100101
	Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <1487930694.1528.1.camel@mmci.uni-saarland.de>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [bitcoin-dev] SHA1 collisions make Git vulnerable to attakcs by
 third-parties, not just repo maintainers
Precedence: list

Not sure that you really read deeply what I sent, because stating that
hashing files continuously instead of hashing the intermediate steps
just gives more latitude to the attacker can't be true when the attacker
has absolutely no control over the past files

I did not write this as a workaround to fix SHA1, which will be dead
soon or later but as maybe some general concept that could possibly help
whatever hash function you are using for objects that are not frozen but
extending (ie the original email stating that trees might be some kind
of worse candidates for collisions reminded me this), indeed it makes no
sense to patch SHA1 or play around, but this kind of proposal could
accompany the defunct

The drawback is that you have to keep the hash state when you close the
latest hash computation in order to start the next one

Then the question is: knowing the hash state, is it as easy to find a
collision between two files that will be computed in the next round than
finding a collision between two files only?

Knowing that you can probably modify the hash state with some
unpredictable patterns

Most likely the answer is: no, it's (astronomically?) more difficult

Please take it as a suggestion that might be explored (ps: I have the
code for this if needed) rather than an affirmation, still amazed as
shown in the few links provided (among others) that each time I raise
this subject nobody really pays attention (what's the use case?, etc)
and by the fact that it's apparently used by only one project in the
world and not supported by any library


Le 24/02/2017 à 11:04, Tim Ruffing via bitcoin-dev a écrit :
> On Fri, 2017-02-24 at 00:57 +0100, Aymeric Vitte via bitcoin-dev wrote:
>> I have not worked on this since some time, so that's just thoughts,
>> but maybe it can render things much more difficult
>> than       computing two files until the same hash is found
>>
> You basically rely on the idea that specific collisions are more
> difficult to find. This trick or similar tricks will not help. (And
> actually, the more files you add to the hash, the more freedom you give
> the attacker.)
>
> Even if certain collisions are more difficult to find today (which is
> certainly true), the general rule is that someone will prove you wrong
> in a year.
>
> Even if ignore security entirely, switching to new hash function is
> much simpler trying to fix the usage of a broken hash function.
>
> Relying on SHA1 is hopeless. We have to get rid of it.
>
> Best,
> Tim
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-- 
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms