Hiding and Recovering Data on Linux 151
neuroticia writes "linuxsecurity.com has an interesting article on data hiding and recovery:
"On a 4GB Linux partition, the block size is typically 4K (chosen automatically when the mke2fs utility is run to create a filesystem). Thus one can reliably hide up to 4KB of data per file if using a small file. The data will be invulnerable to disk usage, invisible from the filesystem, and, which is more exciting for some people, undetectable by file integrity checkers using file checksumming algorithms and MAC times. Ext2 floppy (with a block size of 1KB) allows hiding data as well, albeit in smaller chunks.""
Some questions... (Score:3, Insightful)
- what are the potential uses for such a thing?
- a hacker could hide some information somewhere, but what to hide?
- Is there any legitimate use for that?
- Does moving the file to another location suffices to prevent any use of such a thing? (after all, if the file is moved, the block is free for reuse).
Just my 0.01 worth questions...
Re:Some questions... (Score:4, Insightful)
If you think that "if you are innocent, you have nothing to hide", then certainly, this has no uses. Otherwise, it has lots of uses
Hiding dirty pictures of you and your SO from parents perheaps?
No, just _moving_ it does not free the block. You must either move it to another disk, or copy it and remove all had links to it.
Re:Some questions... (Score:1)
Let's assume that if you want to hide something, you'll be clever enough to at least encrypt it before storing it (or even ROT13 it). How can one determine the different between that and random bits left over from old programs, pictures?
Re:Some questions... (Score:2)
your programs won't leave random bits behind, they leave program-droppings - maybe pointers, strings of data, etc. as with hiding data in image files, you have to be careful that the signature of your hidden data matches what one would expect in that area.
do a google search for steganography to learn more about it, like into Neil Provos's stegdetect work at citi.umich.edu.
Re:Some questions... (Score:1)
Thanks for your advice on steganography, I bookmarked it for later reading.
Re:Some questions... (Score:3, Interesting)
It depends on what kind of data you are hiding, and how that data compares to the data already there.
the 3996 bytes left over will have a very discernable pattern: it will be machine code of the program, NOT random bytes.
the 100 bytes encrypted file you create will be random data and will (most likely) look very different from the machine code.
It would be like reading this message and finding a bunch of random numbers in the middle of it - you've got to ask yourself why the pattern was broken.
A better option would be to make your encrypted data look like bytecode and not like random data, kind of like how uuencode makes binary data into ascii characters - that way it won't stand out against the other non-data in the file.
Re:Some questions... (Score:2, Insightful)
Well, That's another way of hiding data, the possibilities are endless
Re:Some questions... (Score:2, Insightful)
I haven't used this, but it seems to do the trick.
mp3stego [cam.ac.uk], (Windows command line app, with source)
something.wav + secret.data + password = something_secret.mp3
Re:Some questions... (Score:2)
Fun mostly! But really, it's useful for anyone who wants to hide information from governme^wuntrustworthy people.
- Is there any legitimate use for that?
See above.
- Does moving the file to another location suffices to prevent any use of such a thing?
AFAIK, no. Not with ext2 at least if you're moving the file from one place on a filesystem to another on the same filesystem. The data doesn't actually get moved. All that changes is the link to the inode. (can somebody correct me / elaborate)
Re:Some questions... (Score:1)
Indeed, the empty space is a nice place to hide things, but just one among very many, and obviously not specific to Linux.
There is a wide variety of unused space on file systems in general, and media files for music, images and the like make a perfect hiding spot. Or am I missing something here about the importance of this issue?
Alex
Re:Some questions... (Score:2, Interesting)
It would take more than one of such blank spaces left on the disk, which would make it very difficult to recover as I'd need to start mapping the different blocks. I think hiding data in images, movies or (way better) music would be better than putting files there or am I missing something (too)?
Re:Some questions... (Score:1)
I'm guessing you're French?
Re:Some questions... (Score:1)
good place to hide a rootkit
dave
Re:Some questions... (Score:1)
Here's a legitimate use. (Score:1)
Re:Here's a legitimate use. (Score:1)
because on your other filesystem, you'd have to store the full address of the chunks where you write, which would actually be equivalent to making the normal file system not use 4K blocks in the first place.
Besides, maintaining consistency would be a mess, what if you delete a block on the "normal" partition and overwrite the whole block with content?
A driver that syncs your normal cluster space with your wasted cluster space would again be identical to not using block on the first FS.
At least that's what I think and I'll continue to think it until someone shows me my beliefs are wrong (it's the same for all of my beliefs actually ;-) )
Nonsense (Score:4, Informative)
Sorry, I fail to see how this is news (block sizes and slack space have been well known for years) or a useful technique - you'd need to have a large number of known unchanging files to store any sensible quantity of data. The obvious source would be binary executables. If you are able to store data in the slack space of binary executables, you're presumably root, in which case why not secure your data in a more sensible way.
Re:Nonsense (Score:3, Interesting)
not necessarily root, but you have root access, like in the case of a compromised system.
until detection utilities become widespread, this would be a great place to hide your 1337 +001z like DDoS utils, portscanners, passwd crackers, lists of cc's passwds etc etc. set up a redundant distributed system across all your hacked boxen to hide files in executables and the sysadmin will not even realise what his system is housing.
Re:Nonsense (Score:1)
Personally, I think strong custom encryption and a compact flash disk makes more sense for very sensitive info.
Virus/Trojan! (Score:1)
virus/tronjan!
perfect way to hide backdoor
RootKit have another cool hack to exploit...
my 2 cent
Re:Nonsense (Score:4, Insightful)
If you are able to store data in the slack space of binary executables, you're presumably root, in which case why not secure your data in a more sensible way.
Unless, of course, you're just "borrowing" root access from the chappie who actually owns the box.
A skilled attacker will hide as many signs of his intrusion as possible. This is one more method he may use, to avoid file integrity checkers like Tripwire, AIDE, and FCheck.
As for what he's hiding? Let's say he puts a trojan sshd in place to grab passwords - those passwords could be conveniently hidden until Bad Guy can come around and collect them.
Re:Nonsense (Score:4, Insightful)
Remove yourself from that high equine animal you are saddled upon. Yes, to many of us here, the idea of storing data in unused sections of a drive is old hat, and many of us have even used such a technique before for various purposes such as for copy protection flags, or for hiding information where people wouldn't think to look, etc. (which are examples of where it would be useful) The "news" in this post is not that you can hide data in the unused portions of blocks, but that a new article overviewing this technique was recently posted, so that those who are not familiar with the concept can go read it and learn about it. These are important concepts that system administrators should know about, so that they know when they can and cannot trust what the tools at their disposal (such as ls, for example) tell them about the contents of their system.
By itself, hiding something in a system doesn't provide a very good amount of security, but in combination with other things, it can be the best form of security possible. Never underestimate the value of other people not even knowing there is a secret they need to look for.
Re:Nonsense (Score:2)
Re:Nonsense (Score:1)
This isn't a computer course though. How useful do you think an article in a driving instructors magazine would be telling you where the steering wheel was?
More useful if filesystem copied whole Blocks (Score:4, Informative)
for example data hidden in the tail portion of 512 bytes on a mac will be copied from one floppy to another on the Mac OS for the last 18 years.
Using modern network protocols or file compression will lose these tail end bytes.
A way of hiding data in a Mc file that survives network and file compression is to store data in the 12 byte undefined section of a resource fork header.
Some people write 12 byte hole scanners to search for passwords and credit card numbers and somwtimes find them according to legend.
But the mac has a concept of a physical file length and a logical file length, and the two values do not have to equal each other, and the physical file length has to be modulo 512 minimum.
But hiding data can get easily lost, its better to hide such data in node cluster control areas rather than file tail ends.
Hide data in 1.44Mb blocks (Score:4, Funny)
Personally, my data is about as interesting as a box of dry Jacob's cream crackers, so I ain't about to go hiding it, either in my slack space *or* my window box!!!
Uses? (Score:5, Funny)
Re:Uses? (Score:4, Funny)
Re:Hey! (Score:1)
It's pr0n you dumbass..
Re:Hey! (Score:2)
...unless it's pr0n made of ASCII text characters, in which case it's...you guessed it...asciipr0n.
Click the link, genius.
Re:Uses? (Score:1)
shred (Score:4, Interesting)
shred -u [filename]
Re:shred (Score:1)
No.
Re:shred (Score:3, Informative)
No, it wont. Unlexx you are writing the zero's to a file which is already larger than 2 gigs. If you write on the device (/dev/hda1 etc) you are not accessing a file or a filesystem, therefor no limitation.
Besides, the 2 GB limitation is not valid any more, unless you use an old kernel. I made a 2.5 GB ascii file last night, and it worked fine
Re:shred (Score:2)
Re:shred (Score:1)
Re:shred (Score:3, Informative)
Really?
Mentioned, and also reasons given why it may not be as good as you think.
No. 2Gb is the maximum filesize on 32bit architectures - nothing to do with ext2. This limit can be got around anyway I believe. Besides, in this case you could just keep creating files until the partition was filled.
Re:shred (Score:1)
The important fact to note is that when empty space is wiped, slack space for all files remains intact. If file is wiped (at least using current version of GNU shred), the associated slack space is NOT wiped with it!
So maybe we should fix shred, then.
Re:shred (Score:4, Informative)
Hrm... may not work with a lot of setups. From "shred --help":
CAUTION: Note that shred relies on a very important assumption: that the filesystem overwrites data in place. This is the traditional way to do things, but many modern filesystem designs do not satisfy this assumption. The following are examples of filesystems on which shred is not effective:
* log-structured or journaled filesystems, such as those supplied with AIX and Solaris (and JFS, ReiserFS, XFS, etc.)
* filesystems that write redundant data and carry on even if some writes fail, such as RAID-based filesystems
* filesystems that make snapshots, such as Network Appliance's NFS server
* filesystems that cache in temporary locations, such as NFS version 3 clients
* compressed filesystems
Note as well that, unless you specify the -x option, it *will* attempt to shred the final block completely, beyond the end of the file (thus killing the hidden data).
I'll go back to lurking now.
What's wrong with using removable media? (Score:3, Insightful)
Yes, it's not a perfect solution but it works 99 per cent of the time. And, if you're paranoid, you can always encrypt the files on your CDR/floppy/zip/Compact Flash card/USB key chain drive for further security.
Sometimes the simplest solutions are the best.
Re:What's wrong with using removable media? (Score:2, Insightful)
Guido's fist is a rather simple solution and will come in quite handy retrieving any files he lost on my zip disk (after he's pulverized my face and stolen everything i own). i hope i was paranoid and encrypted them...
i prefer storing everything on my servers b/c i never know what's going to happen to that removable media. I've never had anything stolen of of me but have had to chase down people who've tried to steal my shit and have known plenty of people who have had their phyiscal stuff stolen from them (pickpocketing, muggings, etc) and plenty more people who are very forgetful and lose zips/cds/etc everywhere.
I find some interesting data around town from people who thought storing on removable media suited them! As long as you *can* keep it safe on you, that's fine.
Good or Evil? (Score:2, Insightful)
Regarding slack space, yes, it works as described, you can use slack space to write your data, and hope that it doesn't get overwritten when the file grows.
Using encription and spanning multiple slack zones, namely on binary files, you can, for instance, write a tool that encrypts a file, writes it on a number of slack zones for the files in /usr/bin (since these won't grow much over time, will they?), and then is able to recover the file.
You can even write the tool so that it creates two pipes, one to read, another to write.
But in the end, is this good or bad? Like it is said in the article, it can as easily be used to hide evidence as it can be to plant evidence.
What should we do? Write tools to use this to our advantage, or write tools to automatically wipe clean the slack area and render this inoperant?
Or should we do both?
FBI caught a traitor who did this on a floppy (Score:2, Interesting)
This exact trick (hidden portions on tail ends of files) was cited in one news article.
He got caught. Why? Because the forensic tools are designed to work on DELETED files adn totally IGNORE THE FILE STRUCTURES ON MEDIA.
The many commercial forensic tools work on entire blocks of data and ignore the lengths of files when foing a default scan of a hard drive or floppy.
So this type of hiding is silly, even if encrypted.
The FBIs tools they purchase will find it.
Re:FBI caught a traitor who did this on a floppy (Score:1)
Re:FBI caught a traitor who did this on a floppy (Score:1)
Well, I don't know. You might have a reason to hide the fact that you have encrypted data at all. Although this doesn't probably work quite as well unless a lot of people with "nothing to hide" start to format their disks so that unused areas have random data...
Anyway, with a good encryption scheme it's even theoretically impossible to distinguish encrypted data from random data.
Too fragile for many uses (Score:3, Informative)
You could rename the file or link to it without losing data. You could rename a parent directory successfully. If you tried to copy the directory, however, you'd lose the data. In short, if you do anything that changes the file's location on the disk, the secret data is lost, or at least disassociated with the original file name and vulnerable to overwriting.
Re:Too fragile for many uses (Score:2)
Systems have thousands of files each with it's own slack space. Just use redundancy. It doesn't matter if half your data gets overwritten if it's stored 10 times.
-
but a more practical use? (Score:3, Interesting)
Or perhaps some sort of piggyback filesystem that uses the slack space but would be mounted as a separate partition?
I'd imagine this would introduce lots of external fragmentation on anything stored there, but as a separate filesystem, you could suffer those pains and move your "current, but not often accessed" files there, where you really don't care if you suffer a bit of a performance hit because it's still a whole lot better than reading it from backups.
-transiit
Re:but a more practical use? (Score:1)
Re:but a more practical use? (Score:3, Informative)
This was actually quite a leap at the time, since blocks were typically only 512b or 1K then. The 4K made it fast, the 1K tail merging made it less wasteful of expensive disk space.
Re:but a more practical use? (Score:2)
In other words...you'd have to implement a filesystem again, using smaller blocks, and gain nothing. Worse than nothing, since the "first" filesystem will be keeping track of its own data in the first part of each block, the "second" filesystem will have to cope with variable-sized blocks, which means more overhead.
If you want to waste less space on your drive (silly, considering the cost per gig these days) just use smaller blocks. And suffer a performance hit, of course, and reduce the upper limit on the size of your drive, and...
Novel Netware 5.x (Score:1)
Why hide the data when you can use that area and reclaim space. On a big drive it can add up pretty quickly. But still is no massive sum.
Defragmentation (Score:1)
Make sure you have the right FS (Score:4, Informative)
Re:Make sure you have the right FS (Score:2)
Does not work with ReiserFS (Score:5, Informative)
I did not see it mentioned that ReiserFS is able to "pack tails", which means that the ending parts of files that do not fill an entire disk block (typically 4KB) are not stored in their own block. Thereby, it does not waste (on average) 2KB per file.
Actually using the disk blocks seems, to me, more appropriate than hiding stuff in them. There is even work in progress of an ext2 version [linux.org] of this technique.
Nothing new here... move along. (Score:4, Informative)
Won't hide from raw access (Score:5, Interesting)
One of the first things a forensic analyst will do, mostly in search of deleted blocks is `strings /dev/hda1`. More likely off a ro image, but out everything ASCII will pop.
Have a look at The Coroner's Toolkit [porcupine.org]
Re:Won't hide from raw access (Score:2, Informative)
As for searching slack, there are plenty of Perl scripts to cull for interesting data such as IP's, credit card numbers, and other patterned text.
Re:Won't hide from raw access (Score:1)
*BSD has the -P flag for `rm`, but I don't know if it wipes full blocks, or just the listed filelength.
Re:Won't hide from raw access (Score:4, Interesting)
So, encrypt it before you hide it in the tail. Make sure the encryption format doesn't have a recognizable header. If you don't want to bother with real encryption, exclusive-OR with 0xAA, and it will look like random leftover binary data, just what would be expected to be left in the slack space. Just don't write how and where you hid it on a sticky note...
Re:Won't hide from raw access (Score:1)
Re:Won't hide from raw access (Score:1)
Thanks for the coroner's handbook link - I hadn't come across this one before, and it's quite good... :-)
someone mod this poster up +n informative...
Mounted dirs (Score:1)
I used to be paranoid.. (Score:5, Interesting)
Then..
I had to stop and wonder why I was doing it. No one was writing e-mail to my using my PGP. Even though I made it available on my web site, and sent as attachments to people could e-mail me back using it. No one did.
I bought secure removable media. A chain to keep it on me. And had it encrypted. Now i just keep it in a bag with my laptop and never bother to use it.
My palm pilot has encrypted media.
No ones ever touched it... I just keep it on my desk hooked up to my Linux box for easy syncing...
What's my point.. Do I have one? MAYBE.
I stopped because I was lazy. I didn't have anything to hide, nothing I do is that important that I have to encrypt it. My code is opensource, and my bank info and passwords, etc are kept on my linux laptop, not on a server.
I guess, I'd like to know Who is using constant encryption and why?
For me, Encryption needs to be strong, standard, and integrated, otherwise it's just a pain.
This of this as an e-mail client. Kinda like PGP but easier.
I write an e-mail. I click "send". My e-mail client checks the "encryption" server. It finds a match for the e-mail recipient I'm sending to and downloads the PGP file and encrypts the e-mail to the recipients specifications. I did not have to do anything. If no PGP key is found then it will be sent unencrypted and let you know that it is doing so.
Re:I used to be paranoid.. (Score:3, Insightful)
This is the essential problem. Crypto needs to be easy enough to use, that people who are lazy and have nothing to hide, will still do it anyway by default.
Re:I used to be paranoid.. (Score:2)
It's very easy. If you want to login you just put your finger on the scanner and the computer does the rest. If you like having muliple accounts, no problem. Use one finger for your superuser account, and another finger for your main account.
Unless you belong to a circus, I imagine that you could have 10 accounts per person.
Another feature it has is the ability to encrypt individual files. As far as I can tell, it acts like winzip.
So why don't I have one?
They're still a little pricey. about $70.00
It's a "gee whiz" coolness factor now, but until they drop down to about $30.00 and offer linux support, I won't bother.
Re:I used to be paranoid.. (Score:1)
I used to work for a company that created an email app that worked exactly as you describe here (except with a proprietary encryption alg instead of PGP). It worked as a proxy instead of a client so that you could plug it in to pretty much any mail client you wanted (Netscape messenger, Pegasus, Eudora, Outlook, etc). It was a pretty neat product, and extremely easy to use, but it did have a couple of major disadvantages:
- Central server. If the certificate server was down, no one could send encrypted mail.
- Related to the above, having one central server wouldn't scale very well. If millions of people had started using our product, our poor little key server would have been overloaded.
In the end, the product failed miserably. The crypto community (rightly) scorned us for using a proprietary, closed source algorithm. However, the idea itself was pretty cool, and certainly much easier to use than any existing email encryption system.Re:I used to be paranoid.. (Score:1)
For me, Encryption needs to be strong, standard, and integrated, otherwise it's just a pain.
ssh, https://, /etc/shadow are quite common and good uses.
dvds and 802.11b incorporate broken encryption schemes but are quite common.
these meet your criteria (strong, standard, integrated) and as you pointed out, that's why they are constantly used.
the other less common steganographic and encryption techniques will be used by people who are fascinate by them, need to use them, or feel they need to use them. and eventually the better techniques will become easier to use, more integrated, stronger, and will become more widespread, e.g. more companies are using vpn's and ipsec, OpenBSD has encrypted swap space, etc.
Re:I used to be paranoid.. (Score:2)
Re:Hushmail doesn't work with Linux/Mozilla (Score:2)
Re:I used to be paranoid.. (Score:2)
I use constant encryption (Score:1)
Another way to hide some files (Score:1)
Linux, at least temporary...
cp file_to_hide
mount
ls
{stuff from hda4}
Almost the same level of protection as in that article...
Re:Another way to hide some files (Score:2)
Thus, the article's example is a little bit better.
The only use for this... (Score:1)
Great....
I haven't seen anyone mention this... (Score:5, Insightful)
First: defragmenting. If you run any utility to defragment your drive, the data will (probably) be lost.
Second: Don't move that file! If you don't know what file space your "secret" data is stored in, then moving, adding, deleting, copying or otherwise altering (editing) any file may destroy some part of your hidden information. Remember that you only have 4k to work with at any given time. This isn't a huge amount of space. You start hiding data all over the place and you quickly start running into this risk.
Third: The govm't and spies aren't stupid. They will have thought of this possibility. In order to implement such file-hiding techniques you would almost certainly need to implement some type of disk partition and format management system on top of the existing one in order to avoid the problems mentioned above. It isn't very hard to search for direct-to-disk calls, and checking the kernel source for partion management against current versions to see if it has been altered is easy too. Unless you hide the source code for your (ext3.01?) filesystem somewhere else or in your hidden system area (pretty hard to do) then the person searching for your data has some pretty clear evidence of where to look for your stuff and how to get at it.
Re:I haven't seen anyone mention this... (Score:3, Insightful)
I wouldn't be too sure about that. I suspect that most defraggers (well, at least a cheesy DOS FAT one that I wrote in the 80s ;-) always move entire blocks, so the data would be preserved. i.e. if a 4k clustersize (DOS terminology) and a 5k file, my defragger would move two 4k clusters instead of having extra code that knows that on second block, only 1k needs to be read and written. I just looked at what clusters were allocated to a file, not what the actual filesize was, in the dirctory.
(I wholeheartedly agree with your other points.)
Re:I haven't seen anyone mention this... (Score:1, Redundant)
before:
[A][B][A-extra][B]
after:
[A][A-extra][B][B]
[A-extra] is the block of data with the additional information hidden.
However, this obviously doesn't hold between partitions or other file systems, e.g. copying a file from ext2f to ntfs.
About the defrag. (Score:1)
[A][B][Afrag-secretstuff][Bfrag-secretstuff]
A
[A][Afrag-gargage][Bbfrag-garbage]
either because the defragmenter read only
[Afrag] or [Bfrag] or wrote only [Afrag] or [Bfrag] to the disk.
Now obviously, a defragger which copies only blocks (like the old Win stuff) would not do this.
Use ReiserFS (Score:1)
And "Hiding" is an interesting term here. It's not hidden, if it's not encrypted; and if it's encrypted, why bother with such nonsense...
Re:Use ReiserFS (Score:1)
Well, suppose you live in a remote tyranny where you land in jail for only, say, 15 years for using encryption instead of being executed when caught with the message.
In that case a good encryption is a bliss and a way to hide the encryption a huge convenience in any case. :)
Rubberhose (Score:1)
Decss (Score:1)
Hmm. (Score:2)
This would not work in ReiserFS. ReiserFS uses that slack space for storing small files.
(I think...)
Steganography (Score:1, Informative)
A better way to hide data on a hard disk would be to use steganography, where the data is encrypted using a data-whitening algorithm and files that aren't standard. Anything you hide on a hard disk, even in the slack area, can be read by manually reading every byte of data on the disk, regardless of the OS or the file utilities used. As a note, the CIA knows this, and they grind up the hard drives they use for secret data. (and even then they don't just throw it away)
A thought (Score:2)
Re:A thought (Score:2)
Seriously, it's way too much overhead for most use, disk is usually cheap enough to go with simpler systems that permit much faster I/O if at the expense of a bit of "wasted" space.
OTOH, the approach can have its uses. Years ago I had an account on a CDC Cyber NOS system with a "disk quota" based on the number of files, not the total size. I just implemented a simple version of "ar" and kept things in archive files except while I was actually using them.
This sounds familiar... (Score:1)
Oh, and to whoever was asking about the uses for this: data can be hidden with system files, where the information will not be moved. It can be used to conceal anything that needs concealing, preferably in conjuction with encryption. This provides both the benefit of additional security for the data, as well as making it less likely for someone to stumble upon the data and say, "hey, this is valid data!" Encryption is good for that sort of thing sometimes. So if Dear Old Bush's Bastards Enforcing the Right (D.O.B.B.E.R.) come after your essays concerning the effects that Bush's policies are having on our already horrid relationship with the rest of the world, those bungling bumpkins from the Three-Letter-Agencies will hopefully not be able to discover "Anti-American" things. Or you might not want your girlfriend to discover your dirty, dirty porn collection. Or you just might be one paranoid kinda guy. There's a lot of uses, really.
Not always the case... (Score:2, Funny)
It's about what already *is* lurking on your HDD (Score:2)
--
HEX (Score:1)
How to do this correctly (Score:2, Informative)
The disadvantage: because there is no way to tell whether there might be other data on the drive, if you don't have all of the passwords and write to the drive, you may overwrite data encrypted with another password (when data is written, it is scattered on the drive). But it's still a lot better than trying to hide data in the extra room of a block.
According to their website, this is used by civil rights activists who are in hostile nations (where "subpoena" is spelled t-o-r-t-u-r-e).
Could you stitch this into a file system? (Score:2, Interesting)
The chief objection is that the data may go missing if it is defragged or modified. The solution may be a simple as looking at last modification dates. Many of the system files on both Unix and Windows machines (/usr/bin, c:\Windows\System32) are quite small and are very rarely modified. There could be enough space spread among these files to stitch together into space for several dozen KB of compressed information. Plus, good compression should yield data blocks that look quite a bit like noise.
The other problem is hiding the program to run the file system. But that itself could be hidden in the file system if a small enough bootstrap could be written. Alternately, it could live on a floppy, providing a key, of sorts.
Re:Well... (Score:1)
Re:Well... (Score:1)
I have maybe two or three files I would prefer not to show to anyone else, and I keep those on a cdrom, locked in a closet.
Or are you afraid anyone is going to see your huge collection of porn?
Re:Well... (Score:2)
for their beliefs, or for their plans to stop the
killing.
Re:just to make sure.. (Score:4, Interesting)
Re:Interesting. Very interesting. (Score:2)
And even if the paranoid people who think that government agencies have advanced encryption breaking hardware are correct, I still think that locating the hidden chunks in the manner I suggested would be trivial compared to cracking MD5 hases.
Re:I don't see why not! (Score:1)