Per-File Encryption Support in NT4? 17
tesserae asks: "I'm a consultant in the aerospace industry, and some of my clients have indicated that they'd like to see me encrypt any data I have on their projects. Because I have to maintain file format compatibility with them, I run NT4 (since the use of M$ Office is nearly universal in this industry). I do have a box running Windows 2000 Pro, which supports transparent per-file encryption, but I don't want to switch to W2k on all my machines. How might I go about hacking a per-file encryption capability into NTFS under NT4? A friend suggested a 'loopback filesystem with a ramdisk with PGP over the whole thing,' but was unable to tell me how to do it. (His friends did it under Linux which is not an option with me, unfortunately)."
"Is there another dependable approach? (Something like installing Service Pack 6, then converting the data disk to NTFS5... but somehow I doubt that NT4 has the capability of managing per-file encryption, even if it reads/writes NTFS5 with the proper SP.)
The reason I'm interested in transparent per-file encryption is that I use many documents (and apps) simultaneously, and don't need to be slowed down with encrypting/decrypting individual files or directories -- and it would help if the .tmp files M$ apps create were also encrypted, for additional security."
try E4M (Score:1)
NTFS is a piece of shit. (Score:1)
Quit wasting your time and get a real filesystem.
--
* CmdrTaco is an idiot.
Commercial Version of PGP (Score:2)
E4M (Score:2)
Pretty good, mounts the encrypted volume as a Windows drive and uses industrial strength algorithms (I am partial to Twofish). If you go for it, also look for SecureTrayUtil, which will let you do all the E4M-related grunt work through the Windows Tray.
I am paranoid about losing my laptop with customer information myself...
Re:NTFS is a piece of shit. (Score:2)
Install in a smaller partition, then use Partition Magic to enlarge it. That's what I ended up doing.
Re:E4M (Score:2)
However, both of these options are per-virtual-disk, not per-file - I am not sure if this is what you want (there is no option to move a single file while still encrypted, you need to unlock the volume and copy the file (unprotected, or via PGP) to it's new home.
--
offtopic... but oh well (Score:1)
kudos to you for following the agreement
Re:PGP (Score:1)
-Josh
PGP (Score:2)
PGP Product Info [pgp.com]
-Josh
Re:PGP (Score:1)
If I can't find a better approach, I'll probably take this one; the downside is that I'd have to significantly rearrange my document-management system (it's a little... eccentric?). I really could use transparent per-file encryption.
---
Re:Sure there's a patch for NT4 per-file encryptio (Score:2)
[Sigh] That's what I was trying to avoid -- not only would it cost me the upgrade license for each of the boxen 'round here (hey, it wouldn't be right to just buy one and do a multiple install, would it? ;-) ), but I'd have to do some serious hardware upgrading to run it, and then I'd have to go through the learning curve (which I don't have the time for, right now).
The cost is high to go W2K -- not necessarily unbearable, but high -- and if I can avoid it for the time being, I'd like to. That's why I'm searching for an alternative.
---
My solution (as requested by Josh) (Score:2)
PGP and E4M both have the same general problem: they store files within container files which are encrypted, but to move or work on a file it must come out of the container and is no longer encrypted. The same goes for the suggestion to use Samba and share the stored, encrypted files out to NT4 while working on them.
What makes this bad?
First, I work both at my home office and on the road, so the files go back and forth between my main machine and my notebook (not to mention my backups, which are pretty critical here -- and I'm not using tape for backups, but instead a disk farm of cheap drives on another box... much faster than tape, but it means the files don't inherently get stored in encrypted form). This has workarounds, especially for the backups -- just make the target of the file transfer another encrypted container file (which only means I have to change my whole filing system) -- except for the second problem.
Second, while I'm working on a file, many of the apps I use create *.tmp files as part of their autorecovery process; these files are not encrypted, and unless they're reliably destroyed after the work session is finished, they tend to linger on the drive in accessable and plaintext form (and reliably destroying them is a painstaking task). But if the file is initially encrypted via W2K's EFS, the temp file is also encrypted and therefore safe.
*Sigh*... The only solution I can find that meets both requirements is to switch to W2K on all boxen which might host the file in any form -- precisely the solution I didn't want to use, because I avoid M$ solutions where I can (one man's small stroke for freedom, huh?). It's either that, or piss off my customers... who basically don't see why I don't just switch OSes like they did. (Does anyone else see this as one of the reasons it's so hard to unseat Microsoft?)
Thanks, everyone, for responding. I know it's a tough problem, and I appreciate the variety of solutions which were proposed.
---
Re:NTFS is a piece of shit. (Score:2)
Install under FAT16 and convert to NTFS. easy.
Well... (Score:1)
The main problem with this approach would be that the data travelling over the network would not be encrypted unless you enabled IPsec.
Sure there's a patch for NT4 per-file encryption (Score:2)
There were just too many changes to make to NT to warrant another service pack. It's time to move on from NT4, just as we did from NT 3.51 four years ago.
Win2K has EFS (Score:1)
The downside of that approach is that it uses a "protective key store" to store keys per-user, rather than asking for a separate encryption pass phrase. It also encrypts using a second "recovery agent" key, so that you can have a central administrator able to access all encrypted data. That's a selling point in a large corporation (so if a worker quits or dies, you can still access their work), but it may be a disadvantage for your situation.
Actually, this approach makes it so you could configure your system to use keys that live on your customer's servers, so that you could only access the data relating to their project while connected to their network. It might be a pain for you, but I'm sure your customers would love it.
---------------
Ummmm....this is easy (Score:4)
--