Better just to buy a bunch of USB sticks, wipe 'em all with random noise, use a couple for mundane files, and use a couple for sensitive files — deniably encrypted so as to look like random noise. Then, you can plausibly deny that they contain any sensitive files.
The real issue here is that we shouldn't need to use these sorts of measures. No one will do this unless they're a software professional with something to hide, and "having nothing to hide" doesn't mean you're not still entitled to privacy.
That depends entirely on how exactly you do it. And knowing something and being able to prove it are two very different things.
You're creating a situation where you have a set of encrypted and non-encrypted devices that are indistinguishable, and expecting the police to let you off. But there's nothing stopping someone with only encrypted devices to claim the same thing. I'd be worried that approach would fail either by 1) the police calling your bluff, or 2) indefinitely holding you in jail for contempt of court until you decrypt a drive that has un-decryptable random data.
Encryption with plausible deniability will not have readable headers. It will appear to be completely random data.
"Don't worry about my large collection of seemingly encrypted USB sticks officer, it's actually just random noise I filled them with for the lulz! No sensitive files here."
I see no flaws with this plan.
Usually when you encrypt a drive there's a telltale header, so the disks wouldn't be "seemingly encrypted" at all — and wiping disks clean with noise isn't especially uncommon. It's as plausibly-deniable as it gets, and it'd certainly fly in court.
Not necessarily.
https://www.truecrypt71a.com/documentation/plausible-deniabi...
2. Until decrypted, a TrueCrypt partition/device appears to consist of nothing more than random data (it does not contain any kind of “signature”).
Exactly! If I had anything to hide, I'd make sure to give them the 'correct" password that will wipe out selected data from the device.
Can it be done by giving them one wrong password which will trigger a disc erasure?
Serious question, as I wouldn't know how to do that.
For example, insert your filesystem-nuke (perhaps with an attempts counter) around line 78 of main.rs here https://github.com/akermu/rlock
Actually wiping the disk would take way too long. Assuming that you're running Linux and that all connected drives are fully encrypted: overwrite all keyfiles in a secure manner (ie flushing all caches and etc), write random garbage to the entirety of RAM, and trigger the equivalent of `halt -ff` (note the double --force).
Potentially of interest: `__noreturn machine_real_restart` in reboot.c (https://github.com/torvalds/linux/blob/5bfc75d92efd494db37f5...)
Bonus points for additionally finding a way to trigger the "secure erase" firmware feature of all attached devices as part of the above sequence. That's likely to prove a bit tricky though since that feature is generally locked out (for obvious reasons) once you leave the bootloader.
The contents of RAM in this scenario shouldn't be particularly vulnerable. If they're trying random passwords on the actual machine without any attempt to preserve the disks beforehand there's zero chance they're about to take the machine apart and extract what's left in RAM before it's gone.
>Potentially of interest: `__noreturn machine_real_restart` in reboot.c
Just write "b" to /proc/sysrq-trigger, it'll immediately trigger an ungraceful reboot without trying to unmount filesystems or flush the cache.
Easy enough to booby trap discreetly to delete things if not accessed the 'correct' way.
Maybe this is to show that this approach is so crazy that it could never work (hence the written reports to gather data), and that they do actually need <insert some crazy power> here in order to do it properly because "we tried to do it the nice way and it didnt work"