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

Eugen Leitl eugen at leitl.org
Thu Oct 4 09:46:39 EDT 2012


----- Forwarded message from Sašo Kiselkov <skiselkov.ml at gmail.com> -----

From: Sašo Kiselkov <skiselkov.ml at gmail.com>
Date: Thu, 04 Oct 2012 15:39:18 +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: 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 <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.

> 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



More information about the cryptography mailing list