On Mon, Dec 16, 2019 at 10:08 AM Jordan Glover <Golden_Miller83@xxxxxxxxxxxxx> wrote: > > On Sunday, December 15, 2019 8:49 PM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > > On Sun, Dec 15, 2019 at 10:51 AM Jordan Glover > > Golden_Miller83@xxxxxxxxxxxxx wrote: > > > > > I think encrypting previously unencrypted data on the same disk > > > doesn't guarantee that old data won't be recoverable especially > > > on ssd/nvme which are ubiquitous today. Officially supporting > > > such case on LUKS will give users false sense of security of > > > their data. > > > > This problem exists even in the backup and restore to LUKS encrypted > > volume case. In fact it's less reliable because there's no assurance > > with backup->restore method that all previously occupied LBAs are > > > > overwritten, whereas an inplace conversion can assure that all LBAs in > > the previous range are read and encrypted. It's a matter of > > implementation, there's the potential for false sense of security > > regardless. > > > > Chris Murphy > > AFAIK simply overwriting data isn't reliable method for cleaning ssd/nvme. > For those either ATA SECURE ERASE[1] or blkdiscard[2] should be used. > > Unless I'm mistaken, inplace conversion does neither while user can run > them manually during backup/restore. Without testing, which would be make/model/firmware specific, it's not certain what really happens on flash memory chips themselves. ATA Secure Erase is probably the better recommendation but as both ultimately depend on drive firmware to fulfill the operation, it's really a big *shrug* and therefore I reject the idea that there is a clear line in the sand. It should be true and probably is true that Secure Erase Enhanced or Sanitize are better than blkdiscard. But if it's uncertain, on what basis is a line drawn? Upstreams can state the facts including the unknowns, and help user and distros draw their own line. But consider that as a direct consequence of the burden to backup->luksFormat>restore, quite a lot of users opt out of encryption entirely. The point of in-place conversion isn't perfect security. It's to get more users to opt in, by reducing the penalty of opting in. False sense of security? We have this problem already with cryptsetup --allow-discards leaking fs specific locality in combination with fstrim. And fscrypt() leaks quite a lot of metadata. And the ATA spec allows reserve and overprovision areas to not be erased with Secure Erase, where either Secure Erase Enhanced and Sanitize should cover those areas. In place conversion can be better supported in more sophisticated environments. Linux installers are already overly complicated and soak limited resources maintaining them Opting into encryption right now essentially requires either installer support or the burden of backup restore. That's not great choices. And what installers provide an ATA Secure Erase or Sanitize option? I don't know of any. Conversely, Windows and macOS use comparatively brain dead installers (very simplistic UI, perhaps a few choices at most, pretty much amounting to point at a target and push a button). Easy to install. Easy to make the encryption decision later without the penalty of backup restore. Perfectly secure encryption? I don't know. But the barrier to entry is low. It is a very different problem where to find the resources to build in-place conversion. But I think it's unwittingly asking more users to forgo encryption at all to argue against it on the basis that it's somehow a significant security risk. How many hours, days or weeks of typical usage do you think takes before all cells have either been erased or overwritten by encrypted data? There is interim exposure, that some use case will care about, but some won't. And that might be more useful in assessing a personal line in the sand than categorically saying in-place conversion gives a false sense of security. -- Chris Murphy _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
