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 LOWlmdLHjMht for ; Thu, 13 Jun 2013 07:51:54 +0200 (CEST) Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [IPv6:2a01:e0c:1:1599::12]) by mail.saout.de (Postfix) with ESMTP for ; Thu, 13 Jun 2013 07:51:54 +0200 (CEST) Received: from molly.corsac.net (unknown [78.192.68.46]) by smtp3-g21.free.fr (Postfix) with ESMTP id 5B371A61F6 for ; Thu, 13 Jun 2013 07:51:50 +0200 (CEST) Message-ID: <1371102701.4059.14.camel@scapa> From: Yves-Alexis Perez Date: Thu, 13 Jun 2013 07:51:41 +0200 In-Reply-To: <20130612234322.GA21746@citd.de> References: <1371048256.51b88940f0729@www.inmano.com> <20130612223021.GC14932@tansi.org> <20130612234322.GA21746@citd.de> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-Trj3ONIj1uf/xkwR/6XO" Mime-Version: 1.0 Subject: Re: [dm-crypt] SSD disks and cryptsetup-reencrypt List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Matthias Schniedermeyer Cc: dm-crypt@saout.de --=-Trj3ONIj1uf/xkwR/6XO Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On jeu., 2013-06-13 at 01:43 +0200, Matthias Schniedermeyer wrote: > On 13.06.2013 00:30, Arno Wagner wrote: > >=20 > > 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. >=20 > Or use one of the newer SSDs that take "the easy way" for secure=20 > erasing. >=20 > At last one or more of the current generation controller chips encrypt= =20 > the contents by default (even without enabling FDE), as the controller= =20 > has to do some form of scrambling anyway as high-entrophy is better for= =20 > the flash cells(*). So at least one does AES256 encryption always. When= =20 > you secure erase such a SSD they typically just generate a new key and= =20 > not actually erase the flash-cells. Actually they still need to erase the cells, at least as part of the garbage collection, since at one point they will be reused. And when you do a secure erase, the few seconds needed to erase all the cells doesn't really matter, I guess. That said, nobody knows exactly what the firmware do. > The unknown is if they "drop" the=20 > old key in a secure way, but if they do there is no way to decrypt older= =20 > content even if you desolder the flash-chips. >=20 > Also you have to have to hope that key generation is really random. That= =20 > is something that can't really be proven (only disproven), so personally= =20 > that is not something i could rely on. And one needs to know how it is linked to the ATA password, too. > So i classify it as a "nice to=20 > have", if it works it is a line of defense otherwise it is "nothing". Yeah, right now I don't think I'd trust a self-encrypting SSD and would put luks on top of it anyway. Note that you lose some performances here since those SEDs work way better on compressible data. >=20 > Problem is i can't remember which one(s) do(es) that, and it's bed time. > :-) SandForce (now LSI) controllers. Which can be found in OCZ and some Intel drives. Regards, --=20 Yves-Alexis --=-Trj3ONIj1uf/xkwR/6XO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAABCAAGBQJRuV3tAAoJEG3bU/KmdcClpI8H/2FxFS7joJ+5FRkz+W2p65ca 7ATRZqVFyFJuVwRxCxuKwJYyGayauYGbuwvlC7kh2qeW5IDPqDFvx2NMozLNdNR1 RUupU7TfWbcG5BxM8syXb208L6fnagUqDWPQF+qx9hFRYfWUBkjJNMsleDIQshyq GtS2WIkcS3bnctfoRSgb5MRPbQPu8i5B0FAC809+Clr59+Uv/WHG2BXovbJmRCIu ZxRc3fTgqvErbU2YEB8DQmMWbMN+ruGbqPCD7OHXBK809L9Kfx58RPzaaakltXKX KlNmFmc4ZngzucepRIY3KYT45oJfZRABpnl3eyarWZqgtXT0jYQwyKYp5uGo1pY= =wz8S -----END PGP SIGNATURE----- --=-Trj3ONIj1uf/xkwR/6XO--