* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> On Sun, 17 Apr 2005, Ingo Molnar wrote:
> >
> > in fact, this attack cannot even be proven to be malicious, purely via
> > the email from Malice: it could be incredible bad luck that caused that
> > good-looking patch to be mistakenly matching a dangerous object.
>
> I really hate theoretical discussions.
i was only replying to your earlier point:
> > > Almost all attacks on sha1 will depend on _replacing_ a file with
> > > a bogus new one. So guys, instead of using sha256 or going
> > > overboard, just make sure that when you synchronize, you NEVER
> > > import a file you already have.
which point i still believe is subtly wrong. You were suggesting to
concentrate on file replacement to counter most of the practical
attacks, while i pointed out an attack _using the same basic mechanism
that your point above supposed_.
[ if you can replace a file with a known hash, with a bogus new one, and
you still have enough control over the contents of your bogus new file
that it is 1) a valid file that builds 2) compromises the kernel, then
you likely have the same amount of control my 'theoretical' attack
requires. ]
> And the thing is, _if_ somebody finds a way to make sha1 act as just a
> complex parity bit, and comes up with generating a clashing object
> that actually makes sense, then going to sha256 is likely pointless
> too [...]
yes, that's why i suggested to not actually trust the hash to be
cryptographically secure, but to just assume it's a good generic hash we
can design a DB around, and to turn -DCOLLISION_CHECK on and enforce
consistency rules on boundaries.
[ it's not bad to keep sha1 because even my suggested enhancement still
leaves 'content-less trust-pointers to untrusted content via email'
vectors open against attack (maintainer sends you an email that commit
X in Malice's repository Y is fine to pull, and you pull it blindly,
while the attacker has replaced his content with the compromised one
meanwhile), but it at least validates the bulk traffic that goes into
the DB: patches via emails and trusted repositories. ]
so all i was suggesting was to extend your suggested 'overwrite
collision check' to a stricter 'content we throw away and use the sha1
shortcut for needs to be checked against the in-DB content as well'.
in other words, your suggested 'rename check' is checking for 'positive
duplicate content', while my addition would also check for 'negative
duplicate content' as well.
but as usual, i could be wrong, so dont take this too serious :-)
Ingo
-
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
