Date: Wed, 20 Mar 2013 13:57:59 +0100 From: Fabian Keil <freebsd-listen@fabiankeil.de> To: Daniel Kalchev <daniel@digsys.bg> Cc: freebsd-fs@freebsd.org 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/SHPNJFjjZ8J0EguYFKqh0Ie Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Daniel Kalchev <daniel@digsys.bg> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130320135759.48b5dba8>