On Feb 24, 2017, at 10:37 AM, Joerg Sonnenberger <[email protected]> wrote:
>
> On Thu, Feb 23, 2017 at 05:01:56PM -0700, Warren Young wrote:
>> But now we have new data.
>> Before, this sort of attack was theoretical only. Now it’s not only
>> proven possible, it is already within the ROI budget for certain
>> specialized attacks; attacks only get cheaper over time.
>
> Actually, the only thing that changed is that the attack now has a
> decent price tag.
We also know it can happen before most of our respective careers are over, so
it isn’t something we can boot down the road to the next generation.
In 5 years, I expect this attack to either be 10x faster or 10x cheaper,
depending on the attacker’s needs. Between distro lag for “stable” OSes and
the long time some systems stay installed, untouched, a fix today *might* be
widely distributed by then.
For example, Debian Jessie (the current stable version) is still shipping 1.29,
which is about 2.5 years old now. Stretch (the next version, due out sometime
this year) will ship 1.37 (and that can’t change, because Stretch is
hard-frozen now) which means a fix today will likely still take at least a few
years to get into the *next* Debian after that. And not all Jessie and Stretch
installs will upgrade to whatever comes next, which could ship a fix made today.
And there you are, all 5 years spent waiting on a fix magically made today to
get out to the installed base.
We should not wait until the sky is currently falling.
> Fossil had "hash collissions" issues for a long time
Really? Fossil has a very nice status page showing what your current
repository is doing in this regard: Admin > Reports > SHA1 Collisions. Example:
https://sqlite.org/src/hash-collisions
This shows that for the SQLite code base, 8 hex digits is enough to uniquely
identify any artifact currently in the DB.
But this report only tells you about accidental collisions, whereas the
SHAttered attack is about creating purposeful collisions.
> The new stored blob should be:
> - hash of the rest of the blob
> - blob type
> - content size
> - content
What does the content size buy you?
The SHAttered attack shows that if you’re only after a collision, you can
maintain the file size while making your collision. They didn’t even have to
shift the untouched bytes in the file, as shown by this simplistic diff demo:
https://news.ycombinator.com/item?id=13721633
If you’re trying to protect against preimage attacks with this modification,
the content size isn’t an independent variable with respect to the content
itself. I think if you asked a cryptographer, they’d tell you it adds nothing
to the robustness of the resulting hash.
I also don’t see what hashing the blob data twice gets you. The hash value
changes, but again not as an independent variable.
If you want to make things more difficult, you could throw a timestamp in
there, as Git does. Store it in plaintext, so it can act as a kind of
primitive salt. Better would be to include a random nonce, also stored in
plaintext alongside the blob data.
So, identifier = sha256(contenthash . blobtype . timestamp . nonce)
The latter two are an either/and situation, though having both is probably
overkill.
> Including the blob type makes it
> more robust
That I’ll agree with, because the blob type is an independent variable. You
could have the same block of text being stored as a wiki document, a ticket
comment, or a file, and it would indeed be good if they hashed differently.
> can significantly cut down in the parsing time on rebuilds.
Why? If you’re trying to find data of a particular type in the DB, doesn’t
event.type tell you what you want to know without parsing cards?
What became of the idea of skipping rebuilds for very large repos, by the way?
Fossil rebuilds are strictly optional, aren’t they?
What I’m asking is, if you have a Fossil repo like your experimental NetBSD
one, it’s just slower to access if it isn’t rebuilt, right? So, why couldn’t
Fossil let you clone it without the rebuild to begin with, then you could
schedule a rebuild to run over the weekend sometime?
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
