Hacker News new | past | comments | ask | show | jobs | submit login

It would be nice if the default filesystem on an unsuspicious and relatively popular operating system (Linux?) normally overwrote erased data with random data, and worked to maintain a large contiguous area at one "end" of the drive. You would need to be careful not to fill up your drive to the point that it overwrote part of your hidden volume, of course.

I think this would allow for true deniability.




You might find this a worthhile read about such an approach to filesystems at the filesystem level https://www.usenix.org/legacy/events/sec2001/full_papers/bau...

Though shred and other tools to delete via random overright do exist, but as you imply a low level approach would be much more secure.

Another consideration is the type of storage, then there are backups which will still have deleted data. Let alone SSD's which are a whole different breed and can transparantly make a block as dead and realocate some of the reserved data storage without you knowing and with that leave the existing data permently inplace for forensics. With that having an excrypted file system would certainly help cover such issues, though encryption within encryption could be the extra layer of plausable denability you require.


Worse, overwriting SSD's with random data would halve their lifespan, and some SSD's don't even allow you to control where exactly you are writing to. Better to just never write unencrypted data to the drive at all.


Doesn’t FAT do that? Although maybe a Linux user choosing to use FAT for some other reason isn’t that plausible in itself…


Don't be so quick to judge, I've got a small FAT partition on my boot drive right now for the EFI system partition. That partition also doesn't frequently have data written to it, you could in theory hide a small encrypted volume in the free space and so long as Grub wasn't updated nothing would touch that free space.


I don't think FAT even bothers to zero the data when it's allocated, so you might be able to see what was previously stored in a block by reading it straight after allocation.

OTOH this might be driver dependent.




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

Search: