public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Aymeric Vitte <vitteaymeric@gmail.com>
To: Tim Ruffing <tim.ruffing@mmci.uni-saarland.de>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] SHA1 collisions make Git vulnerable to attakcs by third-parties, not just repo maintainers
Date: Fri, 24 Feb 2017 18:29:50 +0100	[thread overview]
Message-ID: <b557a0de-2492-80a1-eff7-229503ae382d@gmail.com> (raw)
In-Reply-To: <1487953849.5148.2.camel@mmci.uni-saarland.de>

??? apparently we are not discussing the same thing

Maybe I did not provide the right links (reading them again I myself
don't find them so clear), see maybe again
https://github.com/whatwg/streams/issues/33#issuecomment-28045860

a - b - c -d

hash(a)

hash(a+b)

etc

But you are not going to rehash from the beginning, then:

update a --> keep the remaining bytes a_ (+ hash state 1) --> digest
a=hash(a)

update a_+b from hash state 1--> keep the remaining bytes b_ (+ hash
state 2) --> digest a_+b=hash(a+b)

etc

Basically that's similar to a real time progressive hash of chunks of a
file that you are streaming and therefore don't know what will come next
(per opposition to hashing a file that you already have), this could
apply to trees

This is different from something like:

hash(a)

hash(hash(a) +hash(b))

etc

There is no initial state, and the attacker can't modify what was
already hashed, to make it more difficult you can probably modify the
hash state N


Le 24/02/2017 à 17:30, Tim Ruffing via bitcoin-dev a écrit :
> On Fri, 2017-02-24 at 16:18 +0100, Aymeric Vitte via bitcoin-dev wrote:
>> 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
> What prevents the attacker to provide different past files when talking
> to parties who are still in the initial state?
>
> 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?
> With the original usage of the hash function, the hash state is always
> the initial state. Now that the attacker has some control over the hash
> state even. In other words, if the original use of the hash function
> was vulnerable, then your scheme is vulnerable for the initial state.
>
> Concrete attack: If you can find x != y with H(x) = H(y), then you can
> also find m, x != y, with H(m||x) = H(m||y), just by setting m = "". 
>
> Not sure if this is the right place to discuss that issue though...
>
> 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



  reply	other threads:[~2017-02-24 17:29 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-23 18:14 [bitcoin-dev] SHA1 collisions make Git vulnerable to attakcs by third-parties, not just repo maintainers Peter Todd
2017-02-23 21:28 ` Peter Todd
2017-02-23 23:57   ` Aymeric Vitte
2017-02-24 10:04     ` Tim Ruffing
2017-02-24 15:18       ` Aymeric Vitte
2017-02-24 16:30         ` Tim Ruffing
2017-02-24 17:29           ` Aymeric Vitte [this message]
     [not found] <mailman.22137.1487974823.31141.bitcoin-dev@lists.linuxfoundation.org>
2017-02-24 23:49 ` Steve Davis
2017-02-25  1:01   ` Peter Todd
2017-02-25 12:04     ` Steve Davis
2017-02-25 14:50       ` Leandro Coutinho
2017-02-25 16:10         ` Ethan Heilman
2017-02-25 17:45           ` Shin'ichiro Matsuo
2017-02-27  9:15             ` Henning Kopp
2017-02-25 18:19           ` Alice Wonder
2017-02-25 18:36             ` Ethan Heilman
2017-02-25 19:12           ` Peter Todd
2017-02-25 20:42             ` Watson Ladd
2017-02-25 20:57               ` Peter Todd
2017-02-25 20:53             ` Russell O'Connor
2017-02-25 21:04               ` Peter Todd
2017-02-25 21:21                 ` Dave Scotese
2017-02-25 21:34                   ` Steve Davis
2017-02-25 21:40                     ` Peter Todd
2017-02-25 21:54                       ` Steve Davis
2017-02-25 22:14                         ` Pieter Wuille
2017-02-25 22:34                           ` Ethan Heilman
2017-02-26  6:26                           ` Steve Davis
2017-02-26  6:36                             ` Pieter Wuille
2017-02-26  7:16                               ` Steve Davis
     [not found]                                 ` <CAPg+sBirowtHqUT5GUJf9hmDEACKVX19HAon-rrz7GmO8OBsNg@mail.gmail.com>
2017-02-26 16:53                                   ` Steve Davis
2017-02-25 23:09                       ` Leandro Coutinho

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=b557a0de-2492-80a1-eff7-229503ae382d@gmail.com \
    --to=vitteaymeric@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=tim.ruffing@mmci.uni-saarland.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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