From: Tim Ruffing <tim.ruffing@mmci•uni-saarland.de>
To: 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 17:30:49 +0100 [thread overview]
Message-ID: <1487953849.5148.2.camel@mmci.uni-saarland.de> (raw)
In-Reply-To: <15848c1b-2873-35e8-0588-c636126257df@gmail.com>
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
next prev parent reply other threads:[~2017-02-24 16:30 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-23 18:14 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 [this message]
2017-02-24 17:29 ` Aymeric Vitte
[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=1487953849.5148.2.camel@mmci.uni-saarland.de \
--to=tim.ruffing@mmci$(echo .)uni-saarland.de \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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