Doing it every time would be silly, but sometimes you definitely want to do it. Linked below is the utility I use. f3probe is fast because it only tries to write to the end of the disk, but to work best it is destructive, so not suitable for automatic use every time something is attached.
I’m not in the habit of buying “too good to be true” drives, so I mostly use it to validate if flash storage is still good or has failed. I use f3write and f3read to simultaneously wipe and test flash devices. It writes out deterministic uncompressible data, so then can test that it reads back the correct data. I’ve found various USB drives and flash cards that have gone bad.
Wiping flash cards and USB memory sticks is more difficult than SSD drives, because they rarely have trim or secure erase features. f3write is an excellent way to guarantee no old files can be recovered from a USB memory stick or flash card.
Yes, by far the best way to protect data from future recovery is to encrypt it before writing it.
I know that a lot of (but not all) SSDs come with a secure delete option that is designed to reflash the entire drive to delete everything. Mine didn’t, but that was listed as more expensive ones have.
Encryption is great for this purpose, but also means that getting data off the drive if your computer dies or you need to replace certain parts becomes much more difficult. You’d better have backups. And note the S at the end of that word.
They were the customary 512 bytes most of the time. Although there was a special case where I presented a 520 byte block, for an AS/400. That had a ton of interesting issues to deal with.
Everyone’s always aghast when they learn that, but really, we’ve had hundreds of years to get used to it. Because that’s how return addresses on physical mail work, too.
Strictly speaking, isn’t that an oxymoron? Though of course, using cryptography, it’d be easy enough to come up with something that, while it could be compressed, doing so without the proper key would take æons.
I don’t really think so. Pseudorandom data with a known seed is reproducible, but not compressible[1] by anything that is typically meant when talking about a compression algorithm (DEFLATE, zstd, etc.). I guess one could say the datastream could be “compressed” into the seed and pseudorandom algorithm, but unless you’re smart enough to figure those things out from the datastream itself, I don’t think it counts.
For a tool like f3write, it doesn’t have to be cryptographically secure, just sufficiently random to subvert filesystem (or hardware) level compression, and predictable enough to verify if the underlying storage preserves fidelity.
as long as the repeat cycle of the pseudorandom algorithm exceeds the duplicate block size search of the compression algorithm ↩︎
The interesting thing is that the mean time between a) implementation of a technology and b)widespread implementation of that technology for fraud has steadily decreased to the point where now, the fraudulent use is often the first common use.
Who knew universal anonymous communication would bring out the worst aspects of human nature? Even more so when law enforcement is largely national / subnational while the communication is explicitly borderless.