Am 01.09.2011 17:09, schrieb Marcus Meissner: > On Thu, Sep 01, 2011 at 03:55:28PM +0100, Nick Kew wrote: >> On Thu, 1 Sep 2011 16:36:24 +0200 >> Marcus Meissner <[email protected]> wrote: >> >> >>> This just md5s the inodenr, right? >>> >>> If yes, this is just obfuscation if you do not add some kind of random salt. >>> >>> (You can still just do >>> for (i=0;i<...;i++) md5($i) >>> and compare, including use of Rainbow Tables.) >> >> Erm, yeah. I guess brute force on 2^64 numbers is too easy, >> even if the information leaked is of low value. >> >> Would you consider it strong enough if we aggregate >> inode+size+mtime and make the etag an md5 hash of that? >> Brings the benefit of a slightly shorter string with >> a patch that's still simple. > > Both size and mtime are easily retrievable from remote, > you need to add some stuff the attacker cannot derive ;)
where in the world is the security-problem here? mtime -> well, is directly in the header -> Last-Modified size -> well, directly in the header -> Content-Length inode -> well, where is there any security implication?
signature.asc
Description: OpenPGP digital signature
