Re: Thinking aloud.

On 25 Oct 2012, Nigel Cunningham verbalised:

> On 10/25/2012 09:58 PM, Nix wrote:
>>>                        I've read that Linus isn't concerned about
>>> collisions there, but don't fully understand why it's not an issue
>>> there, but is here.
>> Well, it's not an issue there because it's insanely improbable that it
>> would happen by chance, and git hashes are not meant as a security
>> feature. It's possibly an issue here because it is quite possible for
>> e.g. cryptanalysts to be using Linux and have a page of memory filled
>> with something which they *know* will cause a hash collision because
>> they've just been studying it!
> Ah. It's the security aspect! I wasn't thinking about someone trying
> to corrupt the image on their computer to create a security
> vulnerability. In most cases it won't be a concern (personal
> laptop/computer) but I agree I can't assume "most cases".

I was thinking less of security and more of correctness here: is ToI
suddenly going to become a 'no cryptographers doing SHA-1 collision
work' system? (Sure, this is an extreme case...)

I'm not sure if it can usefully be used by an attacker. What could
someone who was able to generate an arbitrary collision do? He'd have to
get in first and dump colliding pages to disk, in order that
later-logging-in users get their pages (perhaps part of some rarely-run
binary that wouldn't have been in memory before then) transparently
replaced with his colliding pages on the next suspend/restore cycle.
This does not seem like a particularly plausible nor useful attack.
(No such collisions are known, anyway, and for this to be useful you'd
have to be able to generate them on demand *and* make them useful
pages of binaries. Not likely in the near future. Not even MD4 is that
broken.)

I suspect that in practice I am pettifogging over nothing, and you'll be
more worried by the space consumed by SHA-1s: they are not that small if
you're dealing in page-size chunks.

-- 
NULL && (void)