Slashdot Mirror
Seeking Current Info on Linux Encrypted FS?
slick_rick asks: "I'm looking for info on encrypted file systems under Linux to help my employers company move away from Microsoft centric solutions. However the latest HOWTO is two years old, the latest kernel patch dates back to April (and 2.4.3) and even the Sourceforge project has nearly zero documentation and appears to be very dead. Are slashdotters using encrypted file systems? If so, what are your experiences?" We last talked about this topic, just
over a year ago, in this article.
I tried to use win2k's efs, and it ruined me.
Tell them that!
Get your Unix fortune now!
It's been a long time since I set it up under FreeBSD...but, as I recall, it had a very easy-to-setup system for creating an encrypted filesystem. I just 'cattach' it when I boot the machine...and I'm the only user than can look at the contents. It's really quite nifty. And I've never been able to find a good Linux equivalent.
Have you tried the loop-AES patch? It isn't exactly an encrypted FS, but you can create encrypted virtual drives with it.
It's a fairly decent encrypted filesystem implementation. I'm certain is has it downsides, but besides being non-free, I haven't found any others.
BC allows you to create encrypted volumes up to the max size of your harddrive, and encrypts anything therein with your choice of encryption schemas. It also comes with a 'Wipe' command that will allow you to delete a file or clean a drive with a 7-stage delete process.
The next Slashdot story will be ready soon, but subscribers can beat the rush and slashdot the links early!
Right click on the folder, click properties, click "Encrypt this folder." Any other way is a waste of time.
Use BestCrypt from Jetico. It works on Windows OSes as well.
If you can wait until September 2002, ReiserFS v4 will have an encryption plugin builtin.
ÖcéqêK8N& #9561;fö,á>c GîIkU 96;:á9fYé7$¼F~ ÿeCCLìM& #9616;ÿ4- ;êå0#0_R'λ 3;lf'\@& #9524;te1q :Æ¥ôä&# 9580;Eüb#
;Æ>ÿ"w╚ ;å+íÅ ï8XRO"# )Wÿ'fò^òY╣ ;Kñ2">[.0	 786;0Z
/ñlöúi;`ν 1;r÷\^"Ç SHNHÄN$RiDeb"&# 9492;3@É-'ϗ 5;úïfM¼fzϒ 8;
÷¥ä=jN¥ká╟
.¥c◘
ÿ!(VIi±(Av#;d}x övëëúóî|KÖ9&# 9792;9Jq]@2Oü-ö @[WcáÅU3 j
http://www.thehungersite.com
Note that this filesystem based encryption, not user based. I.e. you must enter a password to mount the filesystem, but after that it acts as a normal filesystem (but slower due to the aforementioned encryption).
The way that SuSE do it is to have an encrypted block device, so that you can throw anything you want on top of it. Typically this would be a filesytem ;-)
From the SuSE webpage:
SuSE 7.2 and 7.3 has support for a twofish encrypted fs. You can even set it up in the graphical installer during installation. Works great!
... take a look at "man losetup", which has a good example of setting up an XOR encrypted loopback filesystem. XOR is pretty crappy encryption however.
- Have a picture
on SuSE crypto FS is an option during installation, so you might want to check this it is writen for suse but there is some usefull info in there for all distros.
42
Encrypted filesystems are useless without deniability. Rubberhose gives you that: http://www.rubberhose.org
"The invisible and the non-existent look very much alike." -- Delos B. McKown
...and at least 10 ways to encrypt your data:
http://koeln.ccc.de/~drt/crypto/linux-disk.html
gives them.
I have to second the suggestion of loop-AES. It's really easy to install and use, and works great. I've got both encrypted FS and encrypted swap going using it.
Cryptfs is fully functional, though it was indented mostly as a proof of concept. The point is that such file systems are not hard to build, should someone want to maintain one. Here's an undergraduate programming assignment in which the students build a fully-functional cryptographic file system as an NFS loopback server.
ftp://ftp.kernel.org/pub/linux/kernel/people/hvr
:)
Try that
By far the best fs-encryption I've encountered for Linux so far is ppdd. You can encrypt everything. It's a kernel patch that uses the loopback devices.
http://linux01.gwdg.de/~alatham/ppdd.html
The kernel patch you refer to is not outdated. There just is no reason to release new versions. Here's how you patch your kernel with the international patch.
/usr/src), do...
/usr/src/linux/Makefile.rej. It shows you what lines failed. You can easily fix this by adding (under the DRIVERS line)
:) Also, make sure you build the loopback device as a module, and then add crypto support. I assume you know how to load modules
/dev/loop0 /dev/hda3
/dev/loop0 with your favorite file system (I prefer ReierFS because I've had trouble with ext2 fscking of encrypted file systems -- data loss most notably whenever I mistyped my passphrase). Do something like
/dev/loop0
/dev/loop0
/etc/fstab
/mountpoint reiserfs defaults,loop,auto,encryption=serpent 0 0
/. question. But that's just my opinion.
One level up from your Linux source tree (typically
zcat ~/patch-int-2.4.3.1.gz | patch -p0 -E
You'll notice a chunk fails. The ONLY problem here is patching the root Makefile. Look at the file
CRYPTO = crypto/crypto.o
And changing the line
SUBDIRS = kernel drivers mm fs net ipc lib
to...
SUBDIRS = kernel drivers mm fs net ipc lib crypto
Now your kernel should be properly patched. Make it mrproper, then configure as needed. Add the proper cyphers (I'm sure you can figure this out). Typically, serpent and blowfish are the best choices. Also, build them as modules so you can harvest a little extra entropy.
Now for the easy part. Once you have the kernel modules built and loaded, make sure you have the latest mount tools (including losetup). Pick the device file you want to use as an encrypted file system. For this example, I'm going to use hda3 with 256 bit serpent encryption for shits & giggles.
losetup --keybits 256 --encryption serpent
It will prompt you for a pass phrase. Use a PHRASE and REMEMBER this. You cannot change the passphrase of an encrypted fs after you set it. Get it right. Next, format the device
mkreiserfs
Now, destroy the loopback device...
losetup -d
And add the following line to your
/dev/hda3
Now, every time you boot or mount that file system, it will ask you for the key length and the pass phrase. And there you go. Encrypted file system. Yea.
You can see how trivially easy that was and if you had put about half an hour's thought into it, you could have realized that the "outdated" howto hasn't been updated because the process is pretty much unchanged and you would not have wasted our time with yet another linux newbie Ask
Why bother.
Like I said, it's not a filesystem, but it might get you by. I personally don't care if /etc is encrypted or not. But I might care if /home was encrypted. It's easy enough to mount a BestCrypt container file at /home, so that might be enough.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
But, as it turns out it was a troll since we're all responding to it. Or maybe it was the original moderation of "Troll" that was the real troll?
Apart from that I never had any problem with it, but I admit that I never did much testing.
It works well. I'm no security expert buy I can see a couple of problems with it. Firstly it uses triple-DES. Probably secure enough, but not so fast. There are certainly more suitable ciphers out there.
The key comes from a pass phrase. cfs forces you to have a pass-phrase with at least enough bits to fill the DES keys, but obviously unless you like memorizing long strings of random charcters there will be far less entropy than required in the key.
Secondly meta-data is not encrypted. So, although Eve can't tell what is in a particular file, she can see the directory structure (but not filenames) and when a file was created/modified/accesses.
Apart from these criticisms it seems quite good. Users can create/attach/detach encrypted filesystems without special priveledges. You can specify a timeout on a file store so it is dettached after a certain period.
Maybe you need deniability, but out here in the real world a lot of people should be using encrypted file systems just to ensure that sensitive or confidential information is not exposed to others if the disk is stolen, the cleaning people are bored, etc.
Personally, I don't want my doctor to have deniability about his records regarding me. Or my lawyer. Or my accountant. And most especially not my banker, financial adviser, etc.
In fact, for these people deniability makes a solution look much less attractive. People get *really* nervous when their accountant or lawyer has strong deniability about what the advice they gave you, about where your money went, etc.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
Ehrmm.. Cliff, why do you think this specific feature might help moving people away from MS-centric thinking? I'ld say most people who know about cryptography know about non-MS systems, the others might not be terribly interested. Please explain.
The install for SUSE version 7.2 professional had it built into the install. Select expert partitioning and it was a check box selection in the mount-point, file system type dialog box. You could edit the boot sequence to remove the prompt to mount the file system and then mount it only when you wanted it mounted. Once mounted it was visible in unencrypted form but you could un-mount anytime. Reading and writing is done via a loop back that decrypts /encrypts during read/write. It is visible as a standard file system once mounted to all programs by all users.
SUSE 7.3 has this to say http://www.suse.com/us/products/suse_linux/i386/se curity.html
Watch the space in security, comment dialog box is too small to fit url without it injecting a space.
You should really take a look at CFS. With a little patching it will compile under the various RH distros. Go here for patches: CFS patches
i rock.
www.gnupg.org
The Rubberhose encrypted filesystem might be more suitable for individuals.
Read about it at www.rubberhose.org. It's primary feature is deniability, (from their web page)
Rubberhose is a computer program which both transparently encrypts data on a storage device, such as a hard drive, and allows you to hide that encrypted data. Unlike conventional disk encryption systems, Rubberhose is the first successful, freely available, practical program of deniable cryptography in the world. It was released in an earlier form in 1997, but has undergone significant changes since that time. The design goal has been to make Rubberhose the most efficient conventional disk encryption system, while also offering the new feature of information hiding.
Rubberhose is a type of deniable cryptography package. Deniable cryptography gives a person not wanting to disclose the plaintext data corresponding to their encrypted material the ability to show that there is more than one interpretation of the encrypted data. What deniable crypto means in the Rubberhose context is this: if someone grabs your Rubberhose-encrypted hard drive, he or she will know there is encrypted material on it, but not how much -- thus allowing you to hide the existence of some of your data.-- Too lazy to get a lower UID.
Do a search on google for CryptoAPI. That's the new encrypted filesystem interface for linux. The pathes for 2.4.3 are old. I have an encrypted file system working with 2.4.16 patched with GRSecurity. You no longer need to patch the kernel with CryptoAPI, it just creates kernel modules that you install. It's pretty easy to do.
Why use XOR when you can just use ROT26 =)
It's easy to implement a crypto filesystem, but hard to do it *right*.
Some quick examples:
1) Is a standard cipher used? (easy, now that libraries are widely available)
2) Is a standard cipher used *correctly*? (e.g., no ECB mode!)
3) Does the same data in two blocks encrypt to the same ciphertext? If not, how are you randomizing them? What happens if you copy an encrypted FS from one media to another, e.g., via backups?
4) How do you detect an incorrect encryption key?
There's then the whole issue of key management, the truly hard part. How do you generate the key from the password? How do you support multiple users on the encrypted file system? (N.B., this is cryptospeek for "how do you prevent disgruntled employees from encrypting your data then walking away?" This usually means secondary and even tertiary keys automatically inserted by the system.) How do you handle system reboots?
Finally there's the mundane. Top of that list - how do you handle backups? Can you back up the encrypted data? Can you deny backups of the unencrypted data?
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
For the past two years, I've been using it in several distributions, manually applying the kernel patches and compiling the necessary programs (utils). But with SuSE (>7.2), kernel encryption is built in which has saved me a load of time compiling it into the kernel.
SuSE uses twofish as the encryption algorithm which is good enough for me. I would prefer to use serpent, but not enough to recompile everything. Both twofish and serpent were finalists in the U.S. Federal AES competition, both losing to rijndeal. Of course, W2K/XP use weak 56-bit DES in their EFS and have administrator back doors, so it barely qualifies as encryption.
If you want fast, reliable, and easy to use enrypted file systems, choose SuSE!
Well mine is bigger! Er, I mean smaller. Right. No, not that, I mean ... oh nevermind
This sig has been temporarily disconnected or is no longer in service
For the truly paranoid, or as used to be my case, for laptops that travel a lot and hence are very prone to theft, the cool thing to do is to encrypt your (almost) entire disk, with your root filesystem on an encrypted loopback device, and no swap at all (because swap can't efficiently be encrypted, and RAM is so cheap anyway nowadays). Of course you still need to keep a small unencrypted boot partition to host your kernel, and an initrd image. The initial ramdisk must have a script that will setup the loop device -- prompting you for your passphrase -- before proceeding with system boot.
For additional protection, you might be tempted to keep this boot partition on a business-card size CD-R, thus making sure that nobody can insert code to steal your passphrase, but if they have access to your system for long enough, they could install a hardware keylogger and you're screwed anyway ^_^... Still, might be worth it to put some tamper detection right after the root fs is mounted (i.e. an md5sum check of your entire boot partition)
In any case, I've used such a laptop on a day-to-day basis for over a year and it worked great -- but do expect a huge performance loss on disk access.
On a related note, there is a warning on http://www.kernel.org/pub/linux/kernel/crypto/v2.4 /README.WARNING to the effect that encryption might be a bit broken in 2.4 kernels. I guess you better stick with 2.2 for now if you really need loopback crypto filesystems...
"Words have meaning, and names have power." -- Lorien
Sorry to everyone who was offended by my last comment in this post. I did in fact mean to help, but I just though that the original submitter of this Ask /. question could have done a little more work figuring this out. Hell, even I managed to get my file systems encrypted with that outdated HOWTO.
Nonetheless, I'm sorry for spoiling something informative with some elitist babble. It's just a knee-jerk reaction from time to time.
Why bother.
How does CFS compare to Rubberhose? I know the Rubberhose FreeBSD port is out of sync, but has CFS been updated.. or is that more outdated than the Rubberhose port?
- dforce
SELECT * FROM USERS WHERE A_WINNER = "YUO";
Comment removed based on user account deletion
When you are at the partitioning stage there is a box you can check that allows encrypted filesystems.
Yeah, right, you just want to hide your pr0n from your wife!
--tim
Move away from Microsoft centric software, and move to Linux centric software? GAY
Why not just use OpenBSD, which has filesystem encryption by default.
I can't understand why people want to use Linux for everything.
Use OpenBSD or Solaris.
Something needs to be done about the block size problem - the solution from cryptoapi doesn't seem "the right way"
The best things about kerneli are the possibility to choose between different encryption algorithms and that it's not filesystem dependent. Though I miss the oppertunity to use the encryption algorithms in userspace programs. (Same thing about the digest algorithms, do thay have any function except for enlarging the kernel size?)
I'm currently testing a pam module that mounts kerneli encrypted home directories, release scheduled a few weeks into the future.
I by myself were getting the international kernel patch up to date for some kernel versions up to 2.4.13. You can get those versions at ftp://office.altkom.com.pl/pub/linux/patch-int/.
I'm not a kernel hacker, though... I just applied them and resolved rejects by hand. They _do_ seem to work on kernel 2.4.13, I tested that with serpent encryption of a filesystem on a loopback device.
Prove that it wasn't......
Use cryptoapi instead. It's almost like kerneli (but only compiles as modules) and they have a fix (though maybe not the best).
According to an article in the UK Magazine Linux Format (http://www.linuxformat.co.uk) some similar kernel patches are available from your local kernel.org mirror in /pub/linux/kernel/crypto/
They also recommend the cryptoapi modules (http://cryptoapi.sf.net) as an alternative, with an in-depth guide.
It's in Issue 21, if you can get hold of their back issues department.
Personally, I've hacked around a little bit but a hand edit of a kernel makefile is not exactly beginner's stuff.
See my journal, I write things there
normal:
cryptoloop (cryptoapi), loop-aes, cryptfs, bestcrypt, crypto-patch (up to ~2.4.12, you have to change the Makefile -> better use cvs-cryptoapi)
steg:
stegfs, vs3fs
network:
cfs, tcfs, sfs, vpn solutions
Here is an explanation of how to setup a crypto-loopback as root device. Its not trivial, but for notebooks its a nice thing. Worked nice for me, also the after-installation method.
Great.
http://segfault.net/~gamma/gammas-notebook-high
I thought OpenBSD had successfully implemented encrypted swap capabilities into there operating system.
The person asking the actual question mentions the international crypto patch available from the kernel.org ftp-sites and that the patch is for kernel 2.4.3.
/usr/src/linux (or where-ever that is pointing) needs amending. Look in Makefile.rej for the lines (two of them) with a + prepended and you see which ones they are. I add them manually since it is very little to type.
/dev/loop? file, then mke2fs on the loop device twice(!) as it doesn't seem to take the first time. Mount the loop device as normal.
Well, I am running kernel 2.4.13-ac5 with LVM and the above mentioned patch and it is working quite well for me. There is one snag with it and that is that when applying the patch, the main Makefile in
Once kernel is patched, enable loop crypto and the various ciphers you want to use, build, install and boot kernel. Follow instructions in the crypto directory in the patched kernel tree for how to make the crypto aware mount, umount and losetup binaries. Replace the originals when they are built. Now, create a file, 64 MB in size, use losetup to attach to a
There is some details in the fstab man-page for how to set up an fstab entry for an encrypted e2fs. You can not (although the man-page says so) give the key-size in the fstab entry. (At least I can not do that.)
Happy hacking....
Swedish, but resident in the UK since 1996.
Someone help me, I read the great 12-page introduction to Rubberhose, but I cannot figure out how to reconcile ''An aspect doesn't know about the other aspects'' (paraphrasing) and the way blocks are spread over the disk, with no collisions(? or collisions that are resolved) between aspects (that is, only one aspect may own a block).
Or restated; if the aspects doesn't know about each other, then how can they avoid interfering with each other?
One dosage of Enlightenment requested.
I'm not following the lists at the moment, but I'd hazard a guess that cryptapi is the replacement for kerneli, which has been in a coma for ages.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
This is the correct suse.com link listed above
Bzztt... wrong...
Turns out that NTFS cannot be used on removable disks, even though the NTFS semantics are better suited (think what happens when a disk is unmounted unexpectedly.
The main reason I use an encrypted disk is that I have a lot of client sensitive info on my machine, including high level strategic plans for a Nasdaq 100 company.
Encrypted disks should be used as a matter of course on machines used by lawyers, doctors, accountants, anyone with a professional confidentiality duty. Laptops get stolen, machines get sold with confidential information still on the drives.
I am more skeptical about the need for encrypting file systems for geeks, after all most sysops would do better to keep less secrets rather than more.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
thanks
--MB
Yup. The last I read, there was only a slight performance hit, and very acceptable for the truly paranoid.
I had very good results on FreeBSD with CFS, but I was very aware of the vulnerabilities of running NFS, and made certain to modify my firewall appropriately.
.bash_profile I added some lines to cattach the encrypted directory and then switch me over to the encrypted one. Things like .qmail and .ssh had to go in the unencrypted directory however.
I created an encrypted home directory that was bootstrapped by an almost empty normal home directory. In the last lines of
Have Fun! Rob.
This is quite different to quite a lot of other methods. It allows to backup encrypted files to e.g. CDROM and still have them mountable from there. Works quite well.
By setting just one sysctl (vm.swapencrypt.enable=1)OpenBSD encrypt its swap using AES.
You just have to uncomment one line in /etc/sysctl.conf to activate it permanently.
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
Fighting for Peace, is like Fucking for Virginity.
http://www.kernel.org/pub/linux/kernel/crypto/v2.5 /README<BR><BR>
States:<BR>
see ftp://ftp.kernel.org/pub/linux/kernel/people/hvr for the meantime
Under UK law, everyone has a legal right to view all information held on them by anyone (except MI5), with a full explanation of the meaning and implications of any data. America's the "land of the free", which seems to mean that people are free to screw other people over...
HVR posted about this on the linux-crypto list a few days ago.
:-/
"Alexander Kjeldaas was the billing contact [for kerneli.org] and seems to have vanished... something serious must have been happend, as he seems to have disappeared suddenly from earth
He go's on to say:
"I don't dare yet to put anything official out, [at ftp.kernel.org/pub/linux/crypto/v2.4] unless I know what's happened with alex..."
Does anyone have any information on Alex's whereabouts?
I use the CVS version of cryptoapi which works fine for the latest kernels. ftp.kernel.org/pub/linux/kernel/people/hvr has recent kernel patches.
Tim
I was looking through the readme.warning on the kernel.org ftp site, and it points you to:
http://cryptoapi.sourceforge.net/
Last update August 12, 2001
It has the code for it, but it isn't enabled by default.
Enabling swap encryption is easiest, you just modify you /etc/sysctl.conf (it's labelled well in that file) and/or use the sysctl command.
i use swap encryption on my 1.2 athlon, but not on my 486's running openbsd.
Enabling filesystem encryption requires a kernel build (you need to add "option TCFS" to your config) and some commands to be compiled and run. i found this article to be helpful.
i just did this to see what it'd be like. the documentation is rather minimal but it is workable. You have the option of using 3DES, RC5 and Blowfish. Check out that link for more info.
-f
www.blackant.net
I use loopAES:
http://loop-aes.sourceforge.net/
It works wonderfully, and has worked on every kernel I've tried it on. It doesn't patch the kernel and require a rebuild (except that it requires you do not use the kernel's standard loop device).
It requires a little bit of extra work in that you need to patch util-linux. I used to use cfsd, but I've not been able to get it to work on recent kernels, so I've moved my encrypted volumes to loopAES. I've had no problems at all with it.
Jason.
From the README.WARNING in the crypto/ directory on kernel.org:
"(please see also ftp://ftp.kernel.org/pub/linux/kernel/people/hvr for more recent patches or http://cryptoapi.sourceforge.net/"
If you read the whole thing you can see there are updated patches to the crypto API, but they are works in progress. I'm using the patch for 2.4.15 and I haven't seen any major problems (yet?).
--Kylus
Idiot-proof something, and Life will build a better Idiot.
I use sorcerer linux with an encrypted FS on my laptop ... and on the webpage it has a nice How-to on how to make it work for you . Here is the link here That should help you out some ... i know that in sorcerer that it works with the 2.4.14 kernel.
Don't forget that if you put your laptop to sleep and it's stolen in that state that your encrypted filesystem may be left wide open.
:)
Unmount encrypted filesystems before you sleep the laptop and put a password on your screensaver in case you get lazy. (don't count on a password-protected screensaver to protect you though -- maybe someone will create a screensaver that unmounts any encrypted fs and prompts for the access password...
Thanks. I seem to remember reading something like that in the guide, but it didn't stand out. Basically the "real" password is the _collection_ of aspect passwords.
Now I feel stupid for not figuring it out. Should have known there wasn't a way around that little problem. Ah, well.
Very cool thing. Were I the least bit paranoid I'd be installing it right this minute, but I find that my laziness-to-paranoia ratio is too high at the moment.
Hopefully! this is my data, not my lottery ticket! i need a bit more reliability than a "hopefully".
i haven't used StegFS, though, so perhaps this hopefully works out to be more theoretical than it sounds, but i'd still like a guarantee that my data will be there unless i choose to delete it. Yeah i know that's tough given the whole deniability thing, but still, i'd like that guarantee.
-f
www.blackant.net
I am using Mandrake 8.1 on a laptop (IBM T20 - PIII 700), and a desktop (Athlon 1GHZ), and BestCrypt-0.8-9 works well.
.src.rpm, and did a rpm --rebuild to get a i686 rpm.
...."
I downloaded the
I then just installed the newly created rpm with "rpm -ivh
I started poking around, and at http://www.kernel.org/pub/linux/kernel/crypto/v2.4 /README.WARNING there was a url listed for "more recent patches. Going there revealed stuff for 2.4.6, 2.4.8, 2.4.10. 2.4.15, and 2.5.0... I plan to check it out myself when I get some free time.
"The urge to save humanity is almost always a false front for the urge to rule." --H.L. Mencken
You may be able to circumvent a keylogger using the system you outline by having the key burned to the same business card sized CD. I would personally encrypt that key so that BOTH a password, and possession of the CD are needed to boot. You could also tie this to one of those tiny USB devices (DiskOnKey, PenDrive, etc.). Of course, this still would not give you complete protection.
You don't need to even install NFS to get it working, just go to their web page. Make sure you set the loopback in your kernel compilation to N (do not use 'Y' or 'M' on the option!). Then all you need to do is patch util-linux to create the new versions of losetup, mount and umount and you're ready to go!
Fialar
I haven't read all replies so I don't know if someone already mentioned this:
the cryptoapi/cryptoloop package provides strong encryption systems without the need to patch the kernel anymore.
however, the use of the strong encryption is not allowed in the US.
you can find some more informations at these URLs:
encryptionhowto.sourceforge.net
cryptoapi.sourceforge.net
www.kerneli.org
i am using a twofish encrypted partition on an AMD K6 400 and 512 MB RAM with no time loss (okay, there may be a time loss but i dont see it)
NTFS is a great big ol' step up from FAT, but it still sucks a fattie.
Say you took some nudie pics of your girlfriend and you want to keep them safe. What do you do? You encrypt the file, then set NTFS permissions so that only you can access it, then make sure your nosy roommate doesn't have admin rights to the box.
Secure? Maybe a little. But he can just grab your HD, put it in his box, boot off of HIS W2k/XP install where he has admin privileges, take ownership of the file, clear the encryption bit, change the NTFS permissions, and start a-whackin'.
Sounds difficult, but if you're familiar with NTFS permissions, it only takes 15 seconds, plus the time to plug in the HD. The only thing that prevents him from doing so is that when he puts the NTFS permissions back the way they were, he will still be listed as the owner of the file, so you'd know that somebody was playing with the file, if you ever bothered to check.
Synergy is your friend
when was the last windows EFS release that was not just a vulnerability patch?
by the way, when was the last vulnerability patch?
?WTF?
NTFS 5.0 (and probably in WinXP) can be set to NOT save Administrator escrow keys, and a user has a main encryption key which is a function of their SID and their password which is used to encrypt the keys for individual files, so unless you had a known Administrator password to get at the escrow keys, your friend would need to know your password as well, which implies he could simply log on as you and access your files anyway. I was actually quite pleased to learn that Win2000 didn't just store encrypted files with "obscured" security.
Technically you don't have any guarantees that your RAM is totally wiped when powered off. It's volatile and corrupts when powered off, but fragments of data may be left and recoverable. I don't know any way around that, though.
I have been using this for a year. It works on windows and linux, ok its not free, well infact the source code for the linux one is available for all. It works as a loop back fs, so the "containers" (fikes) for the encrypted data can be copied between machines easily. What filesystem is on the container is up to you, ext2, reiserfs or even msdos. It works on the lastest kernel versions, and has very active support, from jetico and the community. It works using kernel modules so no patching of the kernel is required, having the data in regular files, means its easy to get rid of too. Anyway give it a try http://www.jetico.com
James
I've been working on a project that would be able to do this (one day - hopefully) on Windows, Linux, Solaris, and Mac OS X (Those being the platforms that I have.)
I'm not a crypto whiz and am having serious trouble finding enough information about how filesystems work in order to implement all of the required interfaces. Does anybody know where this information is, or should I look through Linux/BSD sources - and hope that BSD is applicable to OS X?
My current version is pretty much a library that allows you to like apps against it, but doesn't support native operation. The next release will add networking support, but I really need to go native to make it useful to people.
Also, can anybody help decrease the usefulness of the algorithm for decryption so that I can GPL the thing? You can see what I've done from here.
- Malcolm
"The simple-XOR algorithm is really an embarrassment; it's nothing more than a Vigenere polyalphabetic cipher. It's here only because of it's prevalence in commercial software packages, at least those in MS-DOS and Macintosh Worlds [1502.1387]. Unfortunetely, if a software security program proclaims that it has a "proprietary" encryption algorithm-significantly faster than DES-the odd are that it is some variant of this (XOR)".
War crimes, torture, lies, illegal spying... Would someone give Bush a blowjob, already, so he can be impeached?
It has been down for months. I have been unable to talk to anyone who was working on it.
Does anyone know what happened to it?
Encrypted block device? cool!
That could become a major hit in corporate environments, especially ones that use VPNs.
That concept should be included in the Linux kernel...maybe use a public key system like GPG.
Probably best implemented as a type of loopback device. Call it an "encryptback" device. That would also let anyone with proper permissions encrypt his files without additional software, at kernel-level timesharing priority.
Though that may not be a good idea, 'cause a disgruntled employee with system priviledges could just link two encryptback devices together and--whoops...locked the system.
Score one for Linux! (Well, SuSE, for now.)
What's this Submit thingy do?
But it's the only solution that works independently of kernel versions and patches. It's annoying to depend on specific kernel versions, or operating systems for that matter, to access your encrypted data. CFS sucks though because it tends to give you some errors with newer nfs packages, and because you JUST CANT compile the official cfs sources.. they wont compile on any decent Linux. The BSD port works though. So, here is my quasi-port that will compile on newer linux systems that I made.
Pity. I would really have been interested in this link.
Having worked as a tester in the past for one of the major backup software companies and tested the backup-ability of the NTFS5 filesystem, I have got to know all the internals of the NTFS5 filesystem and I think it rocks.
I like the idea of having multiple streams in a file or support for sparse files, or files that are stored in remote storage which are browsable, but only when they are accessed are they restored from tape or whatever.
I personally work with linux a lot and I actually did some research of my own about encrypted filesystems. I found only old projects.
What I like about NTFS5 is the transparency of the filesystem for not only encrypted, but also of compressed files (available since NTFS4).
By the way, the key used to encrypt the files does not have to be stored on the disk - this is only one option. Plugins allow you to have this maybe on a smart card reader or something.
Is anything planned in the way of linux filesystems that allows files and directories to be encrypted as transparently as under NTFS5?
Cryptonomicon comes to mind indeed when reading your laptop description and your hardware keylogger concerns. BTW that book gives many good insights on data security often overlooked by people applying with "brute-force" encryption techs w/o considering well what happens with the data between you and the encrypted channel entrance...
VKh
Tons of good information on this thread! I've got enough bed time reading now to last throughout 2002. But where are the experts? Surely some Slashdot'r is a guru in crypto filesystems who has experience with the packages mentioned in this thread. Can someone here objectively compare and contrast them on features, reliability, performance, security, maintainability, etc, etc?
I have an old program from the DOS days of programming. It's called KOH (potassium hydroxide ) virus. It resides in your boot sector and encrypts partitions, data, and everything else. Well, I was thinking if you used some sort of dos loopback of Linux ( so that DOS is resident), everything could be encrypted. Perhaps CYGWIN is a good IDEA :-) The encryption used was IDEA (fyi).
Please, I welcome all criticisms...
Brilliant!
This is not about Steganography! Your statement about Steganography is right of course, but this is different.
1) Each of the to partitions ("aspects") in the 1GB space ("extent") is actually 1GB big. It is just that the data in all aspects together cannot exceed 1GB.
2) You could actually have 5 aspects (1 for letters to you mum, 2 for emails, 3 for xxx-pics, 4 for faked ultrasecret data and 5 for real ultrasecret data). You could give the court passwords for 1-4 and there will be no way to prove that there is a 5th aspect. That is the deniability.
The court could suspect it because data in partitions 1-4 only accounts for 850MB of one 1 Gb. But there is no way for them to know for sure.
Neighter can you prove that there is no other aspect, neighter can they that there is.
3) All the aspects _are_ writable. Each one on is own as well as any combination of them. The problem is, when writing to any subset you will of course destroy those not in the particular subset.
4) In other words, when you "forget" a password for any of the aspects, the effects are the same as if this aspect never was there. (If the underlieing cryptosystem is secure.)
Edgar
Just a few weeks ago i started my own project for this purpose: vncrypt. It's patched vn(4) driver for FreeBSD-stable that allow transparent encryption. Now it's in beta, encrypting data but with minimalistic and not very secure user level tools.
CFS by Matt Blaze is a good solution, but I don't like NFS idea and directory structure, file sizes, etc are still visible with it.
...it is an over-simplification. If used with a One-Time Pad (emphasis on _ONE_), the Vigenere cipher is one of the few ciphers out there that is literally uncrackable.
CryptFS homepage
CryptFS uses the VFS (Vnode Filesystem) to implement an encrypted filesystem. I've used it on and off over the last several years. In Kernel 2.2.x it needs the FIST kernel patch to work. FIST has been included in the 2.4.x kernel tree, so now all you need is cryptfs.
Brian
Remember Lexington Green!
Here you are :-)
What about compressed (encrypted) filesystems for Linux? I know that e2compr existed/exists for 2.2 but there hasn't been anything going on over there...
Quisque verborum suorum optimus interpres...