Re: Thinking aloud.

Hi.

On 10/26/2012 10:17 AM, Nix wrote:
> On 25 Oct 2012, Nigel Cunningham verbalised:
>> 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.)
Okay. Listening to you and Ted, I think I'm not going to stress about 
just looking at SHA1 hashes and using them as the basis for the "this is 
the same contents" decision. I've written things so that changing the 
hash that's used is as simple as echoing ${HARDER_TO_BREAK_ALGO} into a 
sysfs entry.

By the way, I've just realised that you were totally write about having 
to read the page back in to check the contents are actually the same. 
Sorry for my mistake! I guess that's another reason then to rely on the 
hashes alone.
> 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.
Yes - at least 20 bytes for hash + 4/8 bytes for the identifier for the 
page = 146 pages per page at most. For Ted's 64GB image, that's 114912 
pages for storing hashes - 448MB! But if it turns out that you can now 
write a 30GB image on the second hibernation instead of a 64GB one, 
someone will consider that a gain.

Perhaps I should say I'm planning on making this functionality entirely 
optional.

Regards,

Nigel