From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <glkdd-dm-crypt@m.gmane.org>
Received: from mail.saout.de ([127.0.0.1])
 by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 2afOStT922nB for <dm-crypt@saout.de>;
 Fri, 20 Jul 2012 00:10:16 +0200 (CEST)
Received: from plane.gmane.org (plane.gmane.org [80.91.229.3])
 (using TLSv1 with cipher AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mail.saout.de (Postfix) with ESMTPS
 for <dm-crypt@saout.de>; Fri, 20 Jul 2012 00:10:16 +0200 (CEST)
Received: from list by plane.gmane.org with local (Exim 4.69)
 (envelope-from <glkdd-dm-crypt@m.gmane.org>) id 1Srygh-0006g1-Fv
 for dm-crypt@saout.de; Thu, 19 Jul 2012 23:55:11 +0200
Received: from rain.gmane.org ([80.91.229.7])
 by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
 id 1AlnuQ-0007hv-00
 for <dm-crypt@saout.de>; Thu, 19 Jul 2012 23:55:11 +0200
Received: from eternaleye+usenet by rain.gmane.org with local (Gmexim 0.1
 (Debian)) id 1AlnuQ-0007hv-00
 for <dm-crypt@saout.de>; Thu, 19 Jul 2012 23:55:11 +0200
From: Alex Elsayed <eternaleye+usenet@gmail.com>
Date: Thu, 19 Jul 2012 14:49:51 -0700
Message-ID: <ju9vdv$vpa$1@dough.gmane.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7Bit
Subject: [dm-crypt] [RFC] dm-thin: Random block placement strategy?
List-Id: <dm-crypt.saout.de>
List-Unsubscribe: <http://www.saout.de/mailman/options/dm-crypt>,
 <mailto:dm-crypt-request@saout.de?subject=unsubscribe>
List-Archive: <http://www.saout.de/pipermail/dm-crypt>
List-Post: <mailto:dm-crypt@saout.de>
List-Help: <mailto:dm-crypt-request@saout.de?subject=help>
List-Subscribe: <http://www.saout.de/mailman/listinfo/dm-crypt>,
 <mailto:dm-crypt-request@saout.de?subject=subscribe>
To: dm-crypt@saout.de
Cc: dm-devel@redhat.com

This may be insufficiently useful to justify implementing, but I thought it 
was an interesting concept.

One of the current issues with dm-crypt and discard is that enabling it can 
leak information about the filesystem and usage patterns of the disk[1].

If a dm-thin device with a random block placement strategy is layered on top 
of dm-crypt however, this could solve some of the issues involved and 
partially mitigate others.

Such a random block placement strategy would heavily disguise any layout 
patterns that could be used to identify the filesystem, most likely to the 
point of being completely unrecognizable.

Issues arising from discarded blocks being nonzero are avoided by default 
due to dm-thin pre-zeroing allocations (unless skip_block_zeroing is 
enabled).

However, some issues would still be present:

While the *distribution* of unused sectors would be concealed, their 
existence and how many there are would still be detectable.

In addition, the issues with trim and a hidden device are still present.

[1] http://asalor.blogspot.com/2011/08/trim-dm-crypt-problems.html