----- Forwarded message from Sašo Kiselkov <skiselkov...@gmail.com> -----
From: Sašo Kiselkov <skiselkov...@gmail.com> Date: Thu, 04 Oct 2012 15:39:18 +0200 To: z...@lists.illumos.org CC: Eugen Leitl <eu...@leitl.org> Subject: Re: [cryptography] ZFS dedup? hashes (Re: [zfs] SHA-3 winner announced) User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 On 10/04/2012 02:41 PM, Eugen Leitl wrote: > ----- Forwarded message from Adam Back <a...@cypherspace.org> ----- > > From: Adam Back <a...@cypherspace.org> > Date: Thu, 4 Oct 2012 13:39:35 +0100 > To: Eugen Leitl <eu...@leitl.org> > Cc: cryptography@randombit.net, Jim Klimov <jimkli...@cos.ru>, > Adam Back <a...@cypherspace.org> > 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. > Given that one can get a private key out of an RSA private key holding > server by being another unprivileged process, based on cache lines, timing > etc it seems to me likely you would be able to tell dedup. And maybe you > can dedup lots of times, eg create, delete, wait for space reclaim, write > again (to get better accuracy stats from having lots of timing samples.) As mentioned above, you'll be probably limited by txg commit intervals, making this attack highly impractical. Cheers, -- Saso ----- 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 cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
