Someone should write a disk formatting utility that randomizes the bits on your drive.

Now you can claim that any encrypted drive (which just looks like pure noise if done correctly) is a drive that was just formatted.

This is what GNU shred does. It has a high speed PRNG meant to avoid performance issues from directly using /dev/[u]random. Point it at your preferred block device or partition and let it fill your drive with entropy. With modern flash devices there is still the issue of hidden reserved space for block replacement but you will cover most of the drive. Reduce iterations to 1 since the default is meant for legacy hard drives and will needlessly add erase cycles to flash.

Be careful in countries like UK which have laws requiring the decryption of any data they find. There are people sitting in jail because they couldn't decrypt the "random noise" on their computers.

This is exactly the point. If storing random data was the norm (formatting utilities would offer it) then it would be hard to make a case against it.

And it actually _does_ make sense for formatting utilities to offer it, as this is a good way to ensure that data is really gone after formatting (writing all 0s or all 1s could leave information at the physical layer; and any intermediate layer could not compress random data much so the data must be overwritten).

Fair warning; any links to specific cases (not the law itself)?

> There are people sitting in jail because they couldn't decrypt the "random noise" on their computers.

No, there isn't.

There literally are not. Anyone competent enough to be an expert witness will be able to plainly explain to everyone else how statistical analysis obviously delinates the difference between truly random noise and an encrypted volume.

If there's a difference visible, that's a weakness in the encryption algorithm.

Encrypted data should be statistically indistinct from random noise.

It's an information theory thing. Everything in the ciphertext should be sitting at maximum entropy.

Try it for yourself brother, there is a plainly obvious difference between the random noise of writing garbage compared to a properly encrypted binary.

There are even statistically measurable differences in the garbage written across versions of a tool or OS, which, unlike the invented scenario above, has been successfully used to place a time window on when exactly someone destroyed evidence.

Loll, you have a lot of faith in the legal system that I do not. Expert witnesses are commonly full of shit.

I didn't say all expert witnesses are good nor did I claim they are all used in good faith.

Merely that, unlike in the invented scenario above, statistical differences in the random garbage that gets written to a disk across different tool or OS versions has been successfully used to place a time window on when exactly someone destroyed evidence.

I heard one argue that "zooming" on an image by adding pixels with an algorithm is normal, and he's had such "evidence" used in court before. I was a little horrified as someone who has worked on digital forensic software at a former employer. Adding pixels to an image is not evidence, you're fabricating something out of thin air, especially if its drastically smaller, its even more likely to be BS.

Are you saying any photos I take with phone that had digital zoom is automatically I admissible? Or if not, isn't that consistent with what they said?

but... how _else_ would you Enhance the image?

Even if that is true, I have better things to do with my time and money than pay a expert witness to explain: see, I wasn't breaking the law, I just wanted the cops to think I did. That just seems like a really bad idea.

> the difference between truly random noise and an encrypted volume

A LUKS volume with a detached header is indistinguishable from random data.

Have you actually compared the random data that various tools write to a disk to encrypted files? Load up binwalk and give it a rip, you will be surprised by how distinct the entropy graph is between the two

Sounds a lot like stenography.

https://github.com/dishather/steganodisk

The security track record of steganography is not great.

Isn't the same true of consumer grade encryption? In a perfect world, they should be used together.

Depends on what you mean, but my subtext was that a lot of steganographic designs have turned out to be detectable; it's a design-level concern, where most consumer encryption problems are implementation issues.

That would just be dd if=/dev/urandom of=/dev/path/to/device