----- Forwarded message from Jim Klimov <jimkli...@cos.ru> ----- From: Jim Klimov <jimkli...@cos.ru> Date: Thu, 04 Oct 2012 19:12:16 +0400 To: z...@lists.illumos.org CC: Pawel Jakub Dawidek <p...@freebsd.org>, Eugen Leitl <eu...@leitl.org> Subject: Re: [cryptography] ZFS dedup? hashes (Re: [zfs] SHA-3 winner announced) Reply-To: jimkli...@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. //Jim ----- 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
