From: "C. Scott Ananian" <cscott@cscott.net>
To: Tom Lord <lord@emf.net>
Cc: git@vger.kernel.org, robj@unrealities.com
Subject: Re: Val Henson's critique of hash-based content storage systems
Date: Fri, 29 Apr 2005 16:17:25 -0400 (EDT) [thread overview]
Message-ID: <Pine.LNX.4.61.0504291608410.32145@cag.csail.mit.edu> (raw)
In-Reply-To: <200504291952.MAA27541@emf.net>
On Fri, 29 Apr 2005, Tom Lord wrote:
> I would expect someone to have on hand a small number of blobs that are
> different but have different hashes and, eventually, to drop said files
> into a blob-based infrastructure to wreak havoc.
This is just ridiculous. The number of known collisions in SHA1 is
*exactly zero* at this point in time --- not guaranteed to stay that way,
of course, but generating collisions is likely to remain relatively
expensive for some time. The collisions are highly structured; they are
not just arbitrary blobs. If, after doing your 2^69 work or so to
generate a real honest-to-goodness SHA-1 collision, you think an
attacker would "DROP THEM IN A REPOSITORY TO CREATE HAVOC"? You'd have to
break into the repository, etc, and then you'd find that *NOTHING
REFERENCED THEM* and so *ABSOLUTELY NOTHING WOULD HAPPEN*.
It's far more likely that SHA1 collisions will be used to generate forged
X509 certificates, for a number of highly technical reasons.
Git's highly constrained and derided 'brittle' file formats also serve
to protect against the collision attacks against SHA-1 which are beginning
to look possible.
> So: a way to locally mark a given checksum as "controversial" seems
> prudent, to me (hence, support for such in my blob-db code/spec).
Arguably that's what *upgrades* to the spec might be for -- git has a
solid philosophy of not creating 'features' unless it is sure that they
are needed/will be used, and I think this is always the wise route in
software development. Of much specification comes no code.
And, if you actually create a 'flexible' blob-db spec with 'room for
expansion' -- congratulations, you've just made yourself more vulnerable
to collision attacks.
--scott
terrorist MI5 SKILLET hack AMLASH security KMPLEBE KUFIRE SCRANTON
D5 SLBM LINCOLN KUDESK SMOTH Kojarena Moscow HTAUTOMAT WSBURNT Chechnya
( http://cscott.net/ )
next prev parent reply other threads:[~2005-04-29 20:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-29 0:06 Val Henson's critique of hash-based content storage systems Rob Jellinghaus
2005-04-29 19:45 ` Linus Torvalds
2005-04-29 19:52 ` Tom Lord
2005-04-29 20:17 ` C. Scott Ananian [this message]
2005-04-29 20:37 ` Tom Lord
2005-04-29 20:41 ` C. Scott Ananian
2005-04-29 20:14 ` H. Peter Anvin
2005-04-29 20:47 ` Morten Welinder
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.61.0504291608410.32145@cag.csail.mit.edu \
--to=cscott@cscott.net \
--cc=git@vger.kernel.org \
--cc=lord@emf.net \
--cc=robj@unrealities.com \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).