On Tue, Feb 13, 2024 at 01:03:44PM -0800, David Christensen wrote: > On 2/13/24 09:40, debian-u...@howorth.org.uk wrote: > > Greg Wooledge <g...@wooledge.org> wrote: > > > > > Shred will determine the size of the file, then write data to the > > > file, rewind, write data again, etc. On a traditional hard drive, > > > that will overwrite the original private information. On modern > > > devices, it may not. > > > > Thanks for the excellent explanation :) > > > > One nitpick. You say "On a traditional hard drive, that will overwrite > > the original private information" but that's not quite true. It also > > needs to be a "traditional" file system! That is, not journalled or COW. > > > > So nowadays I would expect shred not to work unless you got very > > lucky, or planned carefully. > > > Perhaps zerofree(8)?
On a SATA, it won't get at (some) of the spare blocks, since it doesn't know that they are there. If your data is so sensitive that you don't want it to escape, your best bet seems to plan ahead and not let it hit your media unencrypted. Use LUKS. And oh, use argon2id as key derivation function [1] these days. Cheers [1] https://mjg59.dreamwidth.org/66429.html -- t
signature.asc
Description: PGP signature
