Re: Merge with git-pasky II.
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> If we want to have any kind of confidence that the hash is reall
> yunbreakable, we should make it not just longer than 160 bits, we should
> make sure that it's two or more hashes, and that they are based on totally
> different principles.
Sorry, it has already been shown that combining two difference hashes
doesn't necessarily provide the security that you would hope.
I think what hasn't been discussed here is the cost of actually doing
the comparisons. In other words, what is the minimum number of
comparisons we can get away and still deal with hash collisions
successfully?
Once we know what the cost is then we can decide whether it's worthwhile
considering the odds involved.
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Merge with git-pasky II.
On Sun, Apr 17, 2005 at 03:35:17PM -0700, Linus Torvalds wrote:
>
> Quite the reverse. Again, you bring up totally theoretical arguments. In
> _practice_ it has indeed been shown that using two hashes _does_ catch
> hash colissions.
>
> The trivial example is using md5 sums with a length. The "length" is a
> rally bad "hash" of the file contents too. And the fact is, that simple
> combination of hashes has proven to be more resistant to attack than the
> hash itself. It clearly _does_ make a difference in practice.
I wasn't disputing that of course. However, the same effect can be
achieved in using a single hash with a bigger length, e.g., sha256
or sha512.
> So _please_, can we drop the obviously bogus "in theory" arguments. They
> do not matter. What matters is practice.
I agree. However, what is the actual cost in practice of detecting
collisions?
I get the feeling that it isn't that bad. For example, if we did it
at the points where the blobs actually entered the tree, then the cost
is always proportional to the change size (the number of new blobs).
Is this really that bad considering that the average blob isn't very
big?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Merge with git-pasky II.
On Mon, Apr 18, 2005 at 01:34:41AM +0200, Petr Baudis wrote:
>
> No. The collision check is done in the opposite cache - when you want to
> write a blob and there is already a file of the same hash in the tree.
> So either the blob is already in the database, or you have a collision.
> Therefore, the cost is proportional to the size of what stays unchanged.
This is only true if we're calling update-cache on all unchanged files.
If that's what git is doing then we're in trouble anyway.
Remember that prior to the collision check we've already spent the
effort in
1) Compressing the file.
2) Computing a SHA1 hash on the result.
These two steps together (especially the first one) is much more
expensive than a file content comparison of the blob versus what's
already in the tree.
Somehow I have a hard time seeing how this can be at all efficient if
we're compressing all checked out files including those which are
unchanged.
Therefore the only conclusion I can draw is that we're only calling
update-cache on the set of changed files, or at most a small superset
of them. In that case, the cost of the collision check *is* proportional
to the size of the change.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: fix mktemp (remove mktemp ;)
Paul Jackson <[EMAIL PROTECTED]> wrote:
>
> Even mktemp(1) can collide, in theory, since there is no practical way
> in shell scripts to hold open and locked the file from the instant of it
> is determined to be a unique name.
mktemp(1) creates the file before exiting. Other instances of mktemp(1)
cannot successfully create the same file (they all use O_EXCL).
Therefore this race does not exist, even in theory :)
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
