From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dm-crypt@andregall.de>
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 7_kjTDGGPQhq for <dm-crypt@saout.de>;
 Thu, 14 Jul 2011 17:01:59 +0200 (CEST)
Received: from scc-mailout.scc.kit.edu (scc-mailout.scc.kit.edu
 [129.13.185.202]) (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>; Thu, 14 Jul 2011 17:01:58 +0200 (CEST)
Message-ID: <4E1F014E.40508@andregall.de>
Date: Thu, 14 Jul 2011 16:46:38 +0200
From: =?ISO-8859-1?Q?Andr=E9_Gall?= <dm-crypt@andregall.de>
MIME-Version: 1.0
References: <20110711231732.596b8622.ldarby@tuffmail.com>
 <20110712124717.GC31326@tansi.org>
 <CAL1L0DEOJRMhbqP3EESWokTGcj9sEfx=B5Vhw69wXCEWB6-d_g@mail.gmail.com>
 <20110714110425.GB13900@tansi.org>
 <CAL1L0DGNM3CGcA7U6AqHgAw5v7ygXsMag9wWr9Y4TisNewOVcw@mail.gmail.com>
 <20110714133533.GA19714@tansi.org> <4E1EF95D.40406@web.de>
In-Reply-To: <4E1EF95D.40406@web.de>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: [dm-crypt] Status of trim for SSds?
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

Hello,

I'd like to know the current status about the compatibility of TRIM
(http://en.wikipedia.org/wiki/TRIM) for SSDs and dm-crypt. It is my
understanding, that the current version of dm-crypt does not support
trim operations and therefore SSDs that are encrypted with dm-crypt are
not able to work as efficiently and fast as they would with working trim.

One argument that is often heard in discussions about encryption and
trim, is that trim enables an attacker to tell used blocks from empty
blocks and that this might make an attack easier. However, I have never
heard of a case, where the knowlege about the used blocks lead to a
successfull attack of state-of-the-art crypto-algorithms and
implementations. Of course the attacker might be able to make some
guesses or assumptions about the content of the encrypted storage-device
by analysing the distribution of used blocks, but in most scenarios this
isn't an issue.

Is the support of TRIM a feature that's planned for the future? If so,
when? If not, why not?

Andr=E9