From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 vMnc6DR-2R5d for ; Thu, 14 Jul 2011 18:52:45 +0200 (CEST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mail.saout.de (Postfix) with ESMTP for ; Thu, 14 Jul 2011 18:52:44 +0200 (CEST) Message-ID: <4E1F1ED7.8040808@redhat.com> Date: Thu, 14 Jul 2011 18:52:39 +0200 From: Milan Broz MIME-Version: 1.0 References: <20110711231732.596b8622.ldarby@tuffmail.com> <20110712124717.GC31326@tansi.org> <20110714110425.GB13900@tansi.org> <20110714133533.GA19714@tansi.org> <4E1EF95D.40406@web.de> <4E1F014E.40508@andregall.de> <4E1F116D.50402@redhat.com> <4E1F1BCA.9000807@philippwendler.de> In-Reply-To: <4E1F1BCA.9000807@philippwendler.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] Status of trim for SSds? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Philipp Wendler Cc: dm-crypt@saout.de On 07/14/2011 06:39 PM, Philipp Wendler wrote: > I always thought that using trim would essentially be the same as not > writing random data to your disk before encrypting it, and this behavior > is actually the default. mkfs will TRIM the whole device, so only data written after are there. (You can do this later using fstrim command - all fs unused space is discarded.) So in your case (like device wiped by zeros initially), yes, it is the same, you can easily distinguish zeroes from random noise. But if you fill disk by random and someone later run fstrim while device was mounted, it will uncover various patterns there. This is new problem. I am almost sure that filesystem type could be detected from ciphertext device by using non-discarded block pattern analysis. What else depends on situation. If you have some analysis what is possible to recover, please post it to the list, it could be very interesting. Milan