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

Eugen Leitl eugen at leitl.org
Thu Oct 4 11:20:01 EDT 2012

----- Forwarded message from Jim Klimov <jimklimov at cos.ru> -----

From: Jim Klimov <jimklimov at cos.ru>
Date: Thu, 04 Oct 2012 19:12:16 +0400
To: zfs at lists.illumos.org
CC: Pawel Jakub Dawidek <pjd at FreeBSD.org>, Eugen Leitl <eugen at leitl.org>
Subject: Re: [cryptography] ZFS dedup? hashes (Re: [zfs] SHA-3 winner announced)
Reply-To: jimklimov at cos.ru
Organization: JSC COS/HT
User-Agent: Mozilla/5.0 (Windows NT 5.2; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1

2012-10-04 18:00, Pawel Jakub Dawidek wrote:
> Invalidating one side channel doesn't mean there aren't more. It is
> safer to assume there are more.

True. One security project I was affiliated with began with
an axiom: "a networked system is considered broken into",
and the project was about providing safe communications -
necessarily without traditional networking gear/interfaces -
between internal data-processing subnets and those required
to face the evil internet and thus tainted and corrupted ;)

> 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.

IMHO "your" dataset's (NFS share's) used space should grow
regardless of dedup in action. However, if your viewpoint
includes the parent pool, something might be inferred indeed.
But as Saso said, you need a quiet pool doing nothing else
but your cracking task for the duration of TXG interval,
which is unlikely already - more so on shared cloud storage.


----- 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