Slashdot Mirror

Well, that is until some idiot judge rules that it's you who has to prove there are no encrypted files on your disk.

Try working on This if you could port it to FUSE.

I'd be willing to pay 50$ for a working beta.

The solution is actually simple. It's just a matter of people deciding to code it. And I don't think the will is currently there, but where theres a will theres a way.

Steganographic file system

StegFS

The first step would be finishing up the development of StegFS, porting it to the newest Linux Kernel and all the distributions. And let the SERIOUS users have privacy.

I am personally interested in the LK 2.2 implementation found here.

I would love if this was brought current to FUSE on 2.6 , as I have many ideas on creating stegfs files via ftpfs and googlemailfs.

Steged cd's would also be intersting... What IS this jibberish ;)

StegFS http://www.mcdonald.org.uk/StegFS/ might be what you want, don't know if/how well it works though.

Why do I call this BS? Encryption is legit and can be proved. Thats a good. And it's open source. Thats good.

They claim to have "hidden" containers. That's false if they guarantee data retention. Why?

If you have a container X big, one can have smaller containers inside that. The key opens the outer container, but exposes the inside (to use their language). Even if these hidden volumes dont have publically readable containers, one can still see them and delete them.

How I would attack this stego: I would obtain a sector-logger via ICE or somesuch driver first. Then I would mount the container and proceed to do a "DOD 7 times rewrite" via eraser or somesuch tool. I then would watch what sectors arent affected. Those would be the hidden ones. Essentially I would show hidden places by what isnt touched.

If truecrypt prevents me from writing on "stego"'ed places, we also have a easy find. No more plausible... Instead, we MUST, at all costs, allow any user to write over the hidden portions to demonstrate that it's just entropy: nothing. To do this, we must be readily able to sacrifice data to prevent capture.

StegFS does this, however it only works for 2.2 kernels. Too bad it's not being worked on, as this project, along with loopback crypto had real promise for very secure stations (thinking laptops and such with super-sensitive data).

Are you looking for a steganographic file system?

http://www.mcdonald.org.uk/StegFS/

At all times, it's deniable that the files exists, even deniable that there are files.

At most, an investigator could determine that you have the stegfs software, but that's all really.

C//

A number of encryption methods implement this. A quick search found StegFS and TrueCrypt. The idea is to simply hide an encrypted filesystem within another encrypted FS. With StegFS it is, as far as I understand it, cryptographically unfeasible to prove the existance of a hidden encrypted filesystem.

Hmmm... wouldn't it be better to use a steganographic file system like StegFS? In the case of encrypted data, authorities may have the legal power to force you to surrender your decryption keys to the encrypted data. Now, if had used a steganographic file system, they wouldn't even know that your data is there on your disk!

I propose an easy solution... encrypt the whole drive with AES256 or stronger, dm-crypt, stegfs or similar mechanisms, or better yet.. a combination of all of the above.

Its not their data, they have no business poking around in it, "different file structure" or not. Keep them out with strong encryption. You have nothing to hide, and they have no business looking.

Have the judge ask the perp what the password is and if he refuses send him to jail for contempt of court?

Try StegFS - http://www.mcdonald.org.uk/StegFS

From the FAQ:

Why should I use StegFS?

StegFS encrypts files stored in its hidden levels. In this it performs the same purpose as a cryptographic file system such as CFS, TCFS, etc. However, StegFS also offers steganography. Allows you to use several levels of hidden files. If someone demands that you give them your keys, you can reveal the contents of some levels whilst plausibly denying that any further levels are used. An attacker cannot identify the existence of any further levels, even if they look at the disk directly.

It's kernel 2.0 or 2.2 only if I remember...

[from the original website]

Although a number of people have shown some interest in recent times in doing work on StegFS or developments of the idea (e.g. http://stegfs.sourceforge.net/), no-one seems to have had enough energy to actually do anything.

Anyway, this is (was) mentioned on ./ a couple of times before.

The advantage of steganography is that if done right, it can give you plausible deniability. For a really interesting read, check out the papers describing StegFS ,a steganographic file system for Linux.

MODs: Its not funny !
Its called steganography.
this project seems to be dead, but the docs are cool : http://www.mcdonald.org.uk/StegFS/

...is if it included an actually USEFUL form of steganography, like the steganographic/encrypted filesystem Rubberhose, which is related in spirit to good old stegfs.

Unfortunately both of these are too old and crufty to have support beyond linux 2.2... implementing 2.6 support or freebsd or openbsd support might be interesting.

Lots of operating systems have had disk-at-a-time encryption. You can already get it for Windows, but that was apparently not good enough to have that PPT junkie use it either.

Disk-at-a-time (or file-system-at-a-time) encryption just doesn't seem to be convenient enough. Most files simply do not need to be encrypted, and the risk of losing an entire disk due to bugs or losing the pass phrase is just too high, as is the computational cost. People need to be able to decide on a per-file basis what gets encrypted and pick different pass phrases for different files.

In fact, file-at-a-time encryption shouldn't be in the kernel, it is implementable in user code if you have the right hooks. You can build that on top of Plan 9's file system hooks or on top of the CODA hooks in the Linux kernel. Something like the Plastic file system for Linux also would work. But it can also be done at the kernel level; ReiserFS may get file-at-a-time encryption soon.

By the way, if you do want disk-at-a-time encryption, StegFS strikes me as a better choice.

Yes, but there is a realistic solution. While StegFS only works on the Linux 2.2 series (officially), someone could port it to newer kernel versions.

Please re-read the passage you quoted. The security device utilizes encryption. To simplify, encryption means it is mixing all your data up into an unintelligible mess. The index that makes sense of this mess is your key. As you have surmised, if the key were in bios and you were to discard the key by flashing the BIOS or removing the battery, you have just destroyed the only index to the spaghetti of 1's and 0's. For this product, the key is actually stored on a USB storage device. Any authority could demand the USB key by force, though, and there goes your security. You need to have one of those paper shredders nearby which also shreds USB dongles.

While I think this is a valuable development, I'd prefer to see StegFS get updated. With that, your disk could have all sorts of crazy stuff on it, but to an intruder, it would look like it's just pictures of Barney.

Unless there is some kind of processor on the end of that USB cord, it is pointless to send all the data up and down the USB cord. What's it going to do when it gets to the end? I am betting the USB connection is for storing a private key.

I applaud ABIT for doing this. We've been in need of a good encrypted filesystem for a while. In fact, I was disappointed to find out the StegFS isn't compatible with any type of linux beyond 2.4.x kernel. The thing is, I'm not sure that this ABIT motherboard scheme will work with linux, either.

In situations like that, encryption is worse than useless without deniability.

Then use StegFS which gives you an arbitrary number encrypted layers. One the one hand you can give away a certain number of passwords, then insist there are no more. On the other hand, the bad guys don't know when it's OK to stop torturing you...

Rubberhose is non-free. If you want an alpha-quality steganographic filesystem that also doesn't work on 2.4 kernels, check out StegFS

A cool thing is a steganographic file system
Unfortunately it's not working in modern Linux kernels - solution: install old Linux distributive for sensitive data
and that patch...

instead of drivecrypt I suggest you have a look at StegFS which does the same but is GPL'd

Better yet, how about combining the "slack space" concept with that of a steganographic filesystem? In fact, the two concepts fit together very well...

What about StegFS is a steganographic filesystem for linux. It encrypts the data and hides it. Although it does not work with 2.4.x kernels, a decently patched 2.2.20 kernel should do well enough. If that's not you particular cup of tea there is always cfs tcfs.

Fighting for Peace, is Like Fucking for Virginity

StegFS (Linux only) is another steganographic filesystem. It's licensed under the GNU GPL, unlike Rubberhose.

http://www.mcdonald.org.uk/StegFS/

May ask for a moment of silence for the CPU? First IDE, now CPU heavy filesystems?

I have recently built a firewall server with 2 ATA33 drives mirroring each other via md raid1 (all reiser except /boot) at boot. Getting it to work (chicken + eggery abounding :p) was a challenge, but be that as it may, I'm so far pretty happy with it. I have used linuxrouter in the past and I gotta admit, I like having all my utils on the fw box. It only runs opensshv2, syslog client and kernel stuff, so hopefully it will be relatively hard to r00t.

This firewall box has 256MB PC133 RAM and a Duron 750. This is probably about 4x more RAM and 6x more CPU than necessary.

For server situations, CPU is so cheap that I believe you should pile on as many options as possible, as long as they're optional. modular plugin filesystem functionality is really really cool, and if I can plugin a steganographic encryption system (or choose to build it in statically as long as its presence is 'masked' somehow ;) that would IMHO be very very rock.

Your Working Boy,
- Otis (GAIM: OtisWild)

no. i mean steganographic.

stenography is writing in shorthand.
steganography is hiding information in such a way that people cannot tell you are hiding a message.

outguess hides data in image (pnm and jpg) files in such a way that you cannot tell the image is also storing data. There is also StegFS, the steganographic file system, in which other people cannot discern information about the file system, like how much space is being used, how many files there are, filenames, etc.

The whole point is that if no one even knows you are hiding something, then they won't know to look. With information which is just encrypted, then people can see that there is something for them to attempt to decipher. But this means that steganography is security through obscurity, so you'd want to couple it with some strong encryption too.

-f