From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Layton Subject: Re: [RFC][PATCH] ensure i_ino uniqueness in filesystems without permanent inode numbers (via pointer conversion) Date: Fri, 17 Nov 2006 09:48:23 -0500 Message-ID: <1163774903.13410.68.camel@dantu.rdu.redhat.com> References: <1163770980.13410.39.camel@dantu.rdu.redhat.com> <20061117142435.GC18567@parisc-linux.org> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org Return-path: Received: from mx1.redhat.com ([66.187.233.31]:11502 "EHLO mx1.redhat.com") by vger.kernel.org with ESMTP id S933631AbWKQOsZ (ORCPT ); Fri, 17 Nov 2006 09:48:25 -0500 To: Matthew Wilcox In-Reply-To: <20061117142435.GC18567@parisc-linux.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Fri, 2006-11-17 at 07:24 -0700, Matthew Wilcox wrote: > I *think* the xor mask is mere obfuscation. It looks likely that you can > recover it with a little bit of trial and error. If you can force the > filesystem to hand you back new inodes quickly such that there is a high > probability you get consecutive allocations, you'll get a sequence which > would be spaced 700-odd bytes apart, except that it's been xored. Since > you know it's incrementing, if you see the sequence decrease, you'll > know that was a 1 in that bit. I think you're right, the addresses would often be sequential, so this is probably crackable. I'll look over the md5 routines when I get the chance, though if someone more cryptographically inclined than I has a different suggestion, I'd love to hear it. -- Jeff