It's not there by default, and I can't find anything about it anywhere on the forum. Is there an equivalent I am not aware of?

The flash chip automatically does wear leveling, so the only way of shredding a file would be to fill the free space with zeroes (dd if=/dev/zero of=reallybigfile.file) and wait until dd exits with ENOSPC.

Expanding on this a little:
https://en.wikipedia.org/wiki/Shred_...29#Limitations

Be aware the flash memory has a unique failure mode where cells holding data may become "read-only", in that they still hold your data but no further writes to a cell are possible, meaning the data can never be deleted, save physical destruction of the memory chip.

General rule of thumb, encrypt any sensitive data that you plan on placing on any type of solid state storage.

Here is a very interesting article on the ATA SECURE ERASE command which doesn't really apply to your situation directly, but is still a very interesting read in pointing out how you can never really be certain data has been removed from an SSD.


http://cseweb.ucsd.edu/users/m3wei/a...safe-paper.pdf
http://cseweb.ucsd.edu/users/m3wei/a...1-Sanitize.pdf

Indeed interesting reading to get a better understanding of how this works on SSD vs HDD. I didn't know about the differences. Thanks!
I've been using gpg to encrypt individual files and my incorrect (or foolish if you will) use of gpg spurred this thread. This is what I did:
then, when done reading I removed sometextfile.txt. I guess the correct way is to remove sometextfile.txt.gpg and encrypt sometextfile.txt, that way no unencrypted file is removed and left for possible recovery.

Edit: The foolishness just goes on and on doesn't it? The above will still result in two files, the original and the new encrypted one. If you want to run
and display the output with the document viewer for example, can you? If I'm not wrong gpg isn't too fond of piping its output...

Am I actually starting to get off topic on a thread I myself started? Not bad...