Hi ho! I had a little idea today and I wonder whether there is any existing application for this. I thought of hiding data using a innocent file and a bitmap. The concept is: You take 2 files, a source file and a destination file (that you want to hide). These files are "layed on top of each other". You then create a bitmap file. For every bit where the source and destination match, the bitmap gets a 0, for every bit where the source and dest don't match you get a 1. You can then remove the destination. The original file can be recovered by laying the bitmap on top of the source file. Everywhere the bitmap has a 0 you take the bit from the source, otherwise you take the opposite of the source. Because only you know which file is the source file, you're the only one that can recover the data using the bitmap. I came with the idea because of certain governments are trying to make encryption illegal or forcing you to tell them your encryption keys. This is an alternative that, although you end up with 2 times the disk usage, is just as safe. So is there an app like this? Otherwise I'm going to write one in the future. Possible vulnerabilities 1. File size of bitmap The bitmap file is the same size as the destination file, so you know that the destination has the same size of the bitmap. Possible solution: The bitmap can be made larger, padded with random bytes. You must than either remember the exact size of the destination so you can cut the randomness back of, or you can use the first part of the file to store the length. The first bytes of the source file overlayed with the length will than give you the bitmapped size of the dest file. This is likely to be be implemented. File size of source file The source file must be at least as large as the destination file. Possible solution: Restart from the beginning of the source again. -> new possible vulnerability: you repeat parts of the source so it may be possible to find some kind of pattern. Implemented if found safe -> requires intensive research I guess? Common file types If someone knows the type of the sourcefile you used they know what the header of the source looks like and actually have part of the beginning of the source. The attacker can use that to retrieve the first bytes of the destination and get to know what type the dest is. Possible solution: Don't use the first part of the source file. Start at an offset behind where you know the headers of the most common file types end and where you know the data is pretty random/not derivable from the file type. Alternative An alternative to this whole concept could be to use xdelta. We must then remove all info xdelta knows about the source file (xdelta stores some info to check you really picked the correct source, this is a weakness in our case). These data must then be reinserted before patching, based on the source you picked. The disadvantage is that xdelta is also partly vulnerable to 1 (xdelta will never be larger than source) and 3. It is also likely that the delta file contains 1 to 1 portions of the destination -> BAD, VERY BAD! Apparently this is just XOR and should be fairly safe if the key (source) is not smaller than the dest.
But by bitmap I don't mean an image, I literally mean a map of bits like 1011110010. Edit: @urie what is the exact name for this? I can't seem to find an app that does this.
OH! Then I am not sure, lol well make it regardless. I am always more likely to use MDL user apps than others
Example: Some file:_01110101 Secret file: 10110010 Bitmap:___11000111 So the bitmap indicates which bits of some file you want to keep or flip over to get your desired file. It's very easy to make actually. So then you have somefile, which is innocent, just a movie or a song perhaps. Then your bitmap which is just a bunch of randomness. But when the bitmap is combined with the innocent file then you magically get the secret file. I'll also use this app to get into windows universal apps and XAML UI stuff, so it might take a while.
I like that, almost delta diff'ish like. You been thinking today ? Give it a run, I am interested. Especially with todays DMCA stuff, I can make entire websites that have DL's without even having actual links to the files haha
I also thought about using xdelta for it but it has a weakness: xdalte first checks if the source file is the right one, so it must contain a checksum of the source. You can extract that checksum from the patch file and google it. If your innocent file happens to be an Ubuntu iso for example it's instantly cracked. This limits you to using file that don't have their checksum in public. The only weakness with the bitmap is that your bitmap always needs to be at least the size of your secret file. I wonder if there's anything we can do about that.
The NSA also has "major" problems with Truecrypt, a program for encrypting files on computers. ... The NSA also has "major" problems with Truecrypt, a program for encrypting files on computers. Truecrypt's developers stopped their work on the program last May, prompting speculation about pressures from government agencies. A protocol called Off-the-Record (OTR) for encrypting instant messaging in an end-to-end encryption process also seems to cause the NSA major problems. Both are programs whose source code can be viewed, modified, shared and used by anyone. Experts agree it is far more difficult for intelligence agencies to manipulate open source software programs than many of the closed systems developed by companies like Apple and Microsoft. Since anyone can view free and open source software, it becomes difficult to insert secret back doors without it being noticed. Snowden recommend use Truecrypt! ... Snowden docs show Tor, TrueCrypt, Tails topped NSA's 'most wanted' list in '12.
That's all true, but does it matter? It's more about the police being allowed to "force" you to tell them your encryption key. I was trying to find a an alternative way to hide data and came up with this idea that of course already exists. So whether truecrypt works or not is irrelevant here.
Of course you're right master your decision is very WISE, hide more reliable than the use AES/Twofish/Serpent. There is another solution (philosophy) - not to be interesting for them When you are not interesting for them, they will not come to visit you and there is no need to hide
In 199x I use Mac and on mac was good app "StuffIt Deluxe", for example we can archive folder to 10 parts, but first part is general. Parts 2-9 you send over some network (without first part is "white noise"). First part you give someone (in 199x we use 3.5" floppy) or you can use paper and "Uuencoding"(uuencode) But now 2015y, this technique very very old!
I'm NOT telling that they are bad, I'm using AES myself too and I trust it (at least the algorithm, not necessarily the particular implementation)... I was only thinking about an alternative way and I'm now looking to implement it. I never, not a single second, believed this is technically better than true encryption (though it technically is a very weak encryption cipher), nor was I trying to make it appear that way. The idea only came because governments don't like encryption and I was searching for an alternative. It's true that you don't have to reinvent the wheel, but does that make it stupid to search for other round things that could replace it? Maybe one day, for no particular reason, ordinary wheels stop working, and you'll be glad someone found something else.
StuffIt DeLuxe is still around (for Windows too!) and it has some advantage. It's version 16.x now (I believe) while I use version 14 from 2010 sometimes, special when it came to compress high resolution photos.
1. formulation of the problem 2. finding possible solutions 3. choice of solutions what is the problem? what goal you want to achieve? possibly: a) When you upload a file for example MSDN iso on: Spoiler rapidshare, depositfiles, turboBit, etc sha1 is original then owners of these services blocking or delete this files (cause "DMCA") b) Really top secret data? like Snowden (Aldrich Ames)? anyway "they find you" and "the police being allowed to "force" you to tell them your encryption key." even if you use do not use the Internet, only paper and attache case (like Aldrich Ames) if "a)" you can use "mixing bytes" without using png (also not encrypted) # dd if=/dev/urandom of=random.dat bs=1M count=1 bs=BYTES read and write up to BYTES bytes at a time count=N copy only N input blocks random.dat(random count) + any.iso + random.dat(random count) = new sha1 yes, even a weak crypto dangerous, suspicious. such a scenario: png + weak crypto (rc4, xor etc) + png If I would be a criminologist and analyzed the hard drive (withdrawn from the data center), I would have found this PNG file. usually the maximum size of PNG files no more 10-40mb. If larger than 40MB, for example about 700MB, 1-2gb, it is suspicious. large file size + weak crypto = unknown content, unknown type of crypto? Calling FBI. 1 idea 2 implementation Idea is primary, anyway thank you for your interesting idea.
for a long time I do not use the Mac, if we compare StuffIt DeLuxe, WinRar and 7-zip. StuffIt compression is better? (if we compress high resolution photos)
I actually did not intent to really "hide" it, it's obvious that the large bitmap file (encrypted file) is suspicious. The thing I want to do is basically just encryption, but by using a file as key (a really long key) we can use a very simple cipher like xor, cause you don't need to take care of the things were xor is unsafe with small keys. That's basically what AES and more sophisticated encryption is all about, enabling you to use a small key without having the vulnerabilities that xor is known to have with smaller keys. But because we use a very large key here there's no need to do all those sophisticated magic and we can use a simple cipher.