From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <thornber@redhat.com>
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 TXirlm70iSc8 for <dm-crypt@saout.de>;
 Fri, 20 Jul 2012 11:51:08 +0200 (CEST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28])
 by mail.saout.de (Postfix) with ESMTP
 for <dm-crypt@saout.de>; Fri, 20 Jul 2012 11:51:07 +0200 (CEST)
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
 (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
 by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q6K9p5Ai018748
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
 for <dm-crypt@saout.de>; Fri, 20 Jul 2012 05:51:06 -0400
Date: Fri, 20 Jul 2012 09:50:59 +0000
From: Joe Thornber <thornber@redhat.com>
Message-ID: <20120720095058.GA1990@raspberrypi>
References: <ju9vdv$vpa$1@dough.gmane.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ju9vdv$vpa$1@dough.gmane.org>
Subject: Re: [dm-crypt] [dm-devel] [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: device-mapper development <dm-devel@redhat.com>
Cc: dm-crypt@saout.de

On Thu, Jul 19, 2012 at 02:49:51PM -0700, Alex Elsayed wrote:
> 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.

A couple of things spring to mind.

- If you're using a spindle device this will destroy performance,
  unless you use large block size (which I suspect you don't want
  to do because you're trying to disguise access patterns).

- How expensive will acquiring a cryptographically secure random
  destination be?