Date: Fri, 04 Jul 2014 08:19:36 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Jesse Gooch <lists@gooch.io> Cc: freebsd-hackers@freebsd.org Subject: Re: geli+trim support Message-ID: <60445.1404461976@critter.freebsd.dk> In-Reply-To: <53B6427D.1010403@gooch.io> References: <alpine.BSF.2.00.1407020036280.4507@wojtek.tensor.gdynia.pl> <7E2718485A3E405D89E5EAB331E9ED70@multiplay.co.uk> <53B6427D.1010403@gooch.io>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <53B6427D.1010403@gooch.io>, Jesse Gooch writes: >IIRC, TRIM is bad for encryption anyway. You want everything to be >random noise, even the empty sectors. TRIM defeats this. The problem is that there is nothing you can do. If you overwrite, your old sector is still unchanged somewhere in flash. If you TRIM, your old sector is still unchanged somewhere in flash, but if you're lucky for slightly less time. Doing both just means that you have both the original and the overwritten content lingering in flash. GBDEs scheme with per sector PRNG keys is marginally better than GELIs, in that the chances that both the sector and its key survives is only 3/4 of the chance that the sector survives. Without access to and control over the Flash Adaptation Layer, encrypting SSDs so they are safe against hardware access is impossible. For the paranoid: ... and a hostile FTL can make it much harder. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?60445.1404461976>