Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

If so, it's a recipe for disaster.

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"



Deleting probably wouldn't be the best approach, because (a) the drive could just be duplicated before-hand, (b) they'd know you'd done it.

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.


> (b) they'd know you'd done it.

That depends entirely on how exactly you do it. And knowing something and being able to prove it are two very different things.


It's fine, just have the legislature pass a Bill of Attainder that declares the thing you know is a proven fact, and you're peachy. It worked great in the Trial of Thomas Wentworth.


> 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.

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.


An unreasonable adversary, such as a terrorist group or something, could plausibly do that. But the legal system has things like the "beyond reasonable doubt" standard of guilt. If the court finds encryption headers on your disk, they've got evidence beyond reasonable doubt that there's encrypted data on it. If there's only noise, it's totally plausible that it's just a spare usb stick, especially if you consistently wipe your unused disks and don't just have one conspicuous disk full of noise.


>If the court finds encryption headers on your disk

Encryption with plausible deniability will not have readable headers. It will appear to be completely random data.


Yeah, that's my point. A proper plausibly-deniable system will be indistinguishable from a disk which has been wiped, to the point that no court can reasonably accuse you of hiding files on it.


Eventually it will become illigal to have randomly generated data stored somewhere.


>you can plausibly deny that they contain any sensitive files.

"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.


"Yeah, when I'm done with a USB stick I wipe it with random noise, so that I know that the data I'm finished with is properly deleted."

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.


>Usually when you encrypt a drive there's a telltale header

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”).


Huh — I was unaware that TrueCrypt has plausible deniability by default. I know it's possible to set up plausible deniability, but with LUKS that takes extra steps, and I assumed the same was true of other disk encryption schemes.


> Easy enough to booby trap discreetly to delete things if not accessed the 'correct' way.

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.


How exactly would you create this booby trap? I'm not aware of anything that could do that, apart from VeraCrypt hidden volumes maybe.


Both iOS and Android have a setting to wipe the device after N unsuccessful attempts to enter passcode.


Can you elaborate how you would do that on a mobile device, laptop/pc? Would you run different partitions?

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.


The easiest solution I see is to write a custom screen-lock for Linux. That could be defeated by a simple reboot, but the hapless roommate in this scenario wouldn't know 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


Not quite the same but a hidden veracrypt volume [0] would easily circumvent this law.

[0] https://veracrypt.eu/en/docs/hidden-volume/


Look into PAM configuration. In particular I think you'd probably want some combination of pam_faillock and pam_exec. pam_exec can be used to call some arbitrary script to wipe your disks and possibly be extra evil and call flashrom to even wipe the firmware beforehand.


> wipe your disks

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.


By "wipe your disks" I meant issue a secure erase assuming you have a SSD like Intel's where it would overwrite an encryption key and be done in short order.

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: