+ - Distinguishing encrypted data from random data 5
Submitted
by
gust5av
gust5av writes "I'm working on a little script to provide _very_ simple and easy to use steganography. I'm using bash together with cryptsetup (without LUKS) and the plausable deniability lies in writing to different parts of a container file. On decryption you specify the offset of the hidden data. Together with a dynamically expanding filesystem this makes it possible to have an arbitrary number of hidden volumes in a file. It is implausible to reveal the encrypted data without the password, but is it possible to prove there is encrypted data where you claim there's not?
If I give someone one file containing random data and another containing data encrypted with AES, will he be able to tell which is which?"
If I give someone one file containing random data and another containing data encrypted with AES, will he be able to tell which is which?"
How many random files do you have on your system? (Score:1)
When do you really have [pseudo] random files on your computer? I haven't done a block level examination of my current hard drive, but in the past it always seemed like there was some rhyme or reason to the data even in unallocated [deleted] blocks.
So, if the purpose is plausible deniablity -- why do you have the random files?
As a developer, I suppose I can claim that it's the source of "randomness" for the card game that I'm writing. I really want it to be 500GB of random data in order to provide a
Re: (Score:1)
So, if the purpose is plausible deniablity -- why do you have the random files?
Let me give an example:
I have one (1) 100M file that looks random (could just as well be a Truecrypt volume). When I open it with my program I say that my data starts 20M into the file, and enter my password. Then `dumpe2fs` says that the filesystem size is 30M. This means that my data is written between Mbytes 20-50. I can make the filesystem larger and add files if I wish to, but everytime I unmount the volume I use resize2fs to shrink the fs as much as possible.
I also have a "secret" volume between M
You missed the point. (Score:1)
I understood what you were saying regarding how your system operates. I'm asking "How do you have a random file that isn't suspicious?"
I haven't looked at compressed files (which also implies hidden data) but most binary files that I know of have tell tale signs that indicate what they are used for.
You're trying to not appear suspicious by being random versus encrypted -- but I'm wondering if random by itself appears suspicious.
Who are you trying to protect from? (Score:1)
Okay, now that I'm more awake and had a chance to think over night, who are you trying to protect against?
If it's a technically ignorant person (note, that does not mean stupid) then your plan will work. If you're trying to protect against someone who can confiscate your system and is technically savvy, your system won't work.
Specifically, you're extracting the hidden (and encrypted?) data to another file, allowing the user to work with it, putting it back into the "random" file, and deleting the unenc
Re: (Score:1)
My Idea is to make this system completely secure, no matter what resources are spent cracking it. At least in theory. ^^
Are you familiar with the cryptsetup program? When used (with or without LUKS) it doesn't copy anything and definitely doesn't write unencrypted data to the harddrive. Instead it creates a mapping, a new device in /dev/mapper/, which can be accessed to read and write to the file. This means that leaving traces of unencrypted data is not a problem.
Acually I did some more research. Check thi