[cryptography] ZFS dedup? hashes (Re: [zfs] SHA-3 winner announced)

Eugen Leitl eugen at leitl.org
Thu Oct 4 10:01:23 EDT 2012


----- Forwarded message from Pawel Jakub Dawidek <pjd at FreeBSD.org> -----

From: Pawel Jakub Dawidek <pjd at FreeBSD.org>
Date: Thu, 4 Oct 2012 16:00:05 +0200
To: zfs at lists.illumos.org
Cc: Eugen Leitl <eugen at leitl.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 03:39:18PM +0200, Sašo Kiselkov wrote:
> On 10/04/2012 02:41 PM, Eugen Leitl wrote:
> > ----- Forwarded message from Adam Back <adam at cypherspace.org> -----
> > 
> > From: Adam Back <adam at cypherspace.org>
> > Date: Thu, 4 Oct 2012 13:39:35 +0100
> > To: Eugen Leitl <eugen at leitl.org>
> > Cc: cryptography at randombit.net, Jim Klimov <jimklimov at cos.ru>,
> > 	Adam Back <adam at 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.

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



More information about the cryptography mailing list