----- Forwarded message from Pawel Jakub Dawidek <[email protected]> -----
From: Pawel Jakub Dawidek <[email protected]> Date: Thu, 4 Oct 2012 16:00:05 +0200 To: [email protected] Cc: Eugen Leitl <[email protected]> Subject: Re: [cryptography] ZFS dedup? hashes (Re: [zfs] SHA-3 winner announced) User-Agent: Mutt/1.5.21 (2010-09-15) On Thu, Oct 04, 2012 at 03:39:18PM +0200, Sašo Kiselkov wrote: > On 10/04/2012 02:41 PM, Eugen Leitl wrote: > > ----- Forwarded message from Adam Back <[email protected]> ----- > > > > From: Adam Back <[email protected]> > > Date: Thu, 4 Oct 2012 13:39:35 +0100 > > To: Eugen Leitl <[email protected]> > > Cc: [email protected], Jim Klimov <[email protected]>, > > Adam Back <[email protected]> > > Subject: Re: [cryptography] ZFS dedup? hashes (Re: [zfs] SHA-3 winner > > announced) > > User-Agent: Mutt/1.5.21 (2010-09-15) > > > > On Thu, Oct 04, 2012 at 11:47:08AM +0200, Jim Klimov wrote: > >>> [decrypting or confirming encrypted or ACLed documents via dedup] > >>> eg say a form letter where the only blanks to fill in are the name (known > >>> suspected) and a figure (<1,000,000 possible values). > >> > >> What sort of attack do you suggest? That a storage user (attacker) > >> pre-creates a million files of this form with filled-in data? > > > > The otherway around - let the victim store their confidential but low > > entropy file. Then the attacker writes all permutations, and does timing or > > disk free stats or other side channel to tell which was the correct guess. > > Since block dedup happens at transaction group (txg) commit intervals > (i.e. the blocks aren't dedup'ed in memory, but only at txg commit to > stable storage), in order to get reliable results (from observing > storage behavior) you'd need to probe an entirely unloaded system > extremely slowly (a few blocks per txg interval at best). Needless to > say this is extremely optimistic and is still highly impractical. Any > kind of other chatter on system (other processes doing something) will > crush any hopes of this kind of attack yielding any useful data. > Moreover, dedup is typically used in large storage systems (NAS/SAN) > where one rarely gets local access (most users access the system via > some file-level sharing protocol, e.g. NFS, or block-level, such as > iSCSI or FC), which cover the inner workings of the storage system with > a thick and heavy protocol blanket. Invalidating one side channel doesn't mean there aren't more. It is safer to assume there are more. Another one that comes to my mind is to wait until the load is small and observe with df(1) if the used space grows when we write and by how much. You can even do binary search by writing many possible blocks and observing if the space grew as much as it should. If not, maybe we have a hit and we can split our blocks in half and retry, etc. This would work over NFS just fine. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org";>leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
