1

So the shred utility supposedly allows one to "securely" delete a file, by repeatedly overwriting it with random data.

Obviously on copy-on-write filesystems it is nearly impossible to completely erase data that was once written on it.

However, I've read that journaled filesystems like EXT3/4 and XFS also render shred ineffective.

Suppose I wanted a filesystem where a major priority was the ability to delete files as securely as possible. What filesystems would be best for this purpose?

I'm aware of drive encryption, but when you decrypt a drive, my understanding is that you can then do file recovery on the drive as though it was unencrypted. I want the ability to have protection for sensitive deleted files even if an attacker manages to get past drive encryption.

6
  • With journaling it'd depend on if file data is also journaled, and not just the fs metadata. I think the default with ext4 is to not journal file data (but you may want to check). The underlying storage is another question, SSDs will do copy-on-write behind your back which might leak information if someone gets to read the raw data off the hardware. Commented Aug 23, 2024 at 16:21
  • Have you considered using tmpfs and turning off swap entirely? Commented Aug 23, 2024 at 19:44
  • @Wildcard The problem with that is that I do want persistent storage, I just want the ability to delete a file completely if I decide that, or to at least leave as little of a trace of the file as possible while not interfering with other files (ie not overwriting my whole disk) Commented Aug 23, 2024 at 19:49
  • @waltinator Afaik Tails doesn't do anything particularly special in regards to the OP, as in the Tails persistent storage is just an encrypted partition, not sure what filesystem it uses but if it uses a filesystem that leaves traces/metadata of deleted files then that doesn't help Commented Aug 23, 2024 at 19:51
  • @waltinator and if the Tails persistent storage uses a different filesystem that doesn't leave behind metadata or anything like that when you delete a file from its persistent storage, surely I can use that filesystem on any other drive without using Tails OS Commented Aug 23, 2024 at 19:51

1 Answer 1

1

shred is not made for modern HDDs, or SSDs. It's design is based on a paper from times long long past, when hard drives didn't contain their own controllers. Whether or not the design ideas underlying shred hence still apply to modern hard drives or not is subject to ongoing debate. I'll go with "personally, I don't think so".

Anyways, your best bet is cryptography on an SSD, and using your file system's discard ability together with regular re-encryption.

At first, using an SSD seems counter-intuitive: SSDs are by nature "copy on write" under the hood: the memory blocks presented to you are mapped to arbitrarily ordered blocks on the physical flash memory. When you want to modify a byte on a block, you need to erase the whole block (i.e., set it to 0 completely) and then only flip the right bits. This erasing is a process that wears out the flash cells, so instead of erasing the same physical blocks over and over, every time you modify a block, its modified contents are written to a different, already erased, block, and the old block is enqueued for erasing. The SSD does this all internally, the host doesn't notice anything about it.

Now, there's one way to interact with that: you can TRIM / discard a logical block, and that will simply mark the underlying physical block as unused and enqueue it for erasing; the logical block gets marked as backed by "nulls", and will only get assigned to an erased block once it's getting written to (usually).

Now, LUKS / dm-crypt on Linux is clever. When your file system on an encrypted volume knows a logical block as "no longer used by a file", it hands down a "discard this block" down to the block device – the encrypted device itself then can hand this info one further down to the SSD.

So, you have a mechanism for this that makes it trivial for the encryption layer to quickly re-encrypt only the used parts of the block device (and not the full disk including the data belonging to blocks of deleted files).

Neat. So you delete files, that discards the blocks these use, the ciphertext of which then becomes impossible to read for anyone, but to make things even more secure, you afterwards tell luks to re-encrypt the whole disk, which gives you a new key, with which the old data in the "technically still potentially somewhere inside the SSD, but inaccessible from the computer" can't be decrypted as the key does no longer exist, and in the absence of a key, properly encrypted data is equally likely every possible unencrypted data. So, even when your luks encryption passphrase gets cracked at some point and the then-current (very long) master encryption key recovered, that wouldn't help an attacker recover that data.

1
  • Thank you, very well explained and helpful! Commented Aug 24, 2024 at 15:25

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.