From owner-freebsd-fs@FreeBSD.ORG Wed Mar 20 13:04:04 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 000519B7 for ; Wed, 20 Mar 2013 13:04:03 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.35]) by mx1.freebsd.org (Postfix) with ESMTP id B25C771F for ; Wed, 20 Mar 2013 13:04:03 +0000 (UTC) Received: from [84.44.154.73] (helo=fabiankeil.de) by smtprelay01.ispgateway.de with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1UIIak-0000iK-9a; Wed, 20 Mar 2013 13:58:06 +0100 Date: Wed, 20 Mar 2013 13:57:59 +0100 From: Fabian Keil To: Daniel Kalchev Subject: Re: When will we see TRIM support for GELI volumes ? Message-ID: <20130320135759.48b5dba8@fabiankeil.de> In-Reply-To: <5149967E.4050900@digsys.bg> References: <51479D54.1040509@gibfest.dk> <20130319000232.GA18711@neutralgood.org> <5147BB5C.7020205@gibfest.dk> <5149967E.4050900@digsys.bg> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/SHPNJFjjZ8J0EguYFKqh0Ie"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 13:04:04 -0000 --Sig_/SHPNJFjjZ8J0EguYFKqh0Ie Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Daniel Kalchev wrote: > The comment before about TRIM being bad idea with encrypted storage is=20 > very valid. You don't want anyone to know the layout of the data on the=20 > drive. Considering, that today anyone can have access to huge computing=20 > farms, anything that can make the task of decrypting more difficult is=20 > more than welcome. If you want to be safe, just use more performant=20 > drive and encrypt it all, with no gaps. The bigger the drive, the safer=20 > your data is. Why would it be safer? I agree that there might be scenarios in which one might not want to disclose how much of the disk is used for actual data, but I'd expect brute force attacks to concentrate on getting the master key instead of dealing with every sector on its own. As long as a single provider is used encrypting more data shouldn't make this attack harder. Trimming could decrease the chances of recovering a previous copy of the master key, though. Are you aware of other attacks on geli? Fabian --Sig_/SHPNJFjjZ8J0EguYFKqh0Ie Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlFJsl4ACgkQBYqIVf93VJ047QCgrKwKynMskvwBFho1mDR8515S c70AoIZHBg2TjmIfTagkTbTc9dU7jHVH =rX3n -----END PGP SIGNATURE----- --Sig_/SHPNJFjjZ8J0EguYFKqh0Ie--