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 k_vOWFdwjfIy for ; Thu, 13 Jun 2013 01:52:59 +0200 (CEST) Received: from awesome.dsw2k3.info (awesome.dsw2k3.info [IPv6:2a01:198:661:1f::3]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Thu, 13 Jun 2013 01:52:59 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by awesome.dsw2k3.info (Postfix) with ESMTP id 79446C0C3A for ; Thu, 13 Jun 2013 01:43:25 +0200 (CEST) Received: from awesome.dsw2k3.info ([127.0.0.1]) by localhost (awesome.dsw2k3.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HhdAmBdj9IC for ; Thu, 13 Jun 2013 01:43:24 +0200 (CEST) Received: from citd.de (p50813DC7.dip0.t-ipconnect.de [80.129.61.199]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by awesome.dsw2k3.info (Postfix) with ESMTPSA for ; Thu, 13 Jun 2013 01:43:24 +0200 (CEST) Date: Thu, 13 Jun 2013 01:43:22 +0200 From: Matthias Schniedermeyer Message-ID: <20130612234322.GA21746@citd.de> References: <1371048256.51b88940f0729@www.inmano.com> <20130612223021.GC14932@tansi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130612223021.GC14932@tansi.org> Subject: Re: [dm-crypt] SSD disks and cryptsetup-reencrypt List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On 13.06.2013 00:30, Arno Wagner wrote: > > That said, unless you have high-resource attackers to defend > against, with something like, say, 8 complete-disk re-encryptions > you should be relatively secure. But don't blame me if it turns > out you are not. Or use one of the newer SSDs that take "the easy way" for secure erasing. At last one or more of the current generation controller chips encrypt the contents by default (even without enabling FDE), as the controller has to do some form of scrambling anyway as high-entrophy is better for the flash cells(*). So at least one does AES256 encryption always. When you secure erase such a SSD they typically just generate a new key and not actually erase the flash-cells. The unknown is if they "drop" the old key in a secure way, but if they do there is no way to decrypt older content even if you desolder the flash-chips. Also you have to have to hope that key generation is really random. That is something that can't really be proven (only disproven), so personally that is not something i could rely on. So i classify it as a "nice to have", if it works it is a line of defense otherwise it is "nothing". Problem is i can't remember which one(s) do(es) that, and it's bed time. :-) *: Something about preventing long streams of zeros, ones or both. -- Matthias