Encryption on the cheap

Last Updated on April 17, 2017 by Dave Farquhar

Disspam cruises along. It’s not often that I gush about a program, let alone a 4.5K Perl script, but Disspam continues to make my life easier. Granted, it simply takes advantage of existing network resources, but they’re resources that were previously (to my knowledge) limited to the mail administrator. Literally half my e-mail at home today was spam. Disspam caught every last piece.
A little scripting of my own. I’ve got a client at work who wants absolute privacy guaranteed. He and his assistant have some files they don’t want anyone else to be able to read, period. Well, there’s no way to guarantee that under NT, Unix, or VMS. Under NT, we can take away anyone else’s rights to read the file, but an administrator can give himself rights to read the file once again. We can make it set off all kinds of sirens if he does it, but that security isn’t good enough.

Well, the only way we can guarantee what they want is with encryption. But we’re nervous about making files that one and only one person can read, because last year, one of our executives went on vacation in Florida, fell ill, and died. We don’t want to be in a situation where critical information that a successor would need can’t be unlocked under any circumstance. So we need to encrypt in such a fashion that two people can unlock it, but only two. So the client’s backup is his assistant, and the assistant’s backup is the client. That way, if something ever happens to one of them, the other can unlock the files.

Password-protected Zip files are inadequate, because any computer manufactured within the past couple of years is more than fast enough to break the password through brute force in minutes, if not seconds. The same goes for password-protected Word and Excel documents. Windows 2000’s encryption makes it painfully easy to lock yourself out of your own files.

So I spent some time this afternoon trying to perfect a batch file that’ll take a directory, Zip it up with Info-Zip, then encrypt it with GnuPG. I chose those two programs because they’re platform-independent and open source, so there’s likely to always be some kind of support available for them, and this way we’re not subject to the whims of companies like NAI and PKWare. We’d be willing to pay for this capability, but this combination plus a little skullwork on my part is a better solution. For one, the results are compressed and encrypted, which commercial solutions usually aren’t. Since they may sometimes transfer the encrypted package over a dialup connection, the compression is important.

Plus, it’s really nice to not have to bother with procurement and license tracking. If 40 people decide they want this, we can just give it to them.

The biggest problem I ran into was that not all of the tools I had to use interpreted long filenames properly. Life would have been much easier if Windows 2000 had move and deltree commands as well. Essentially, here’s the algorithm I came up with:

Encrypt:
Zip up Private Documents subdirectory on user’s desktop
Encrypt resulting Zip file, dump file into My Documents
Back up My Documents to a network share

Decrypt and Restore:
Decrypt Zip file
Unzip file to C:Temp (I couldn’t get Unzip to go to %temp% properly)
Move files into Restored subdirectory on user’s desktop

I don’t present the batch files here yet because I’m not completely certain they work the right way every time yet.

They don’t quite have absolute security with this setup, but that’s where NTFS encryption comes in. If these guys are going to run this script every night to back the documents up, it’s no problem if they accidentally lock themselves out of those files. If their laptops get stolen, all local copies of the documents are encrypted so the thief won’t be able to read them. And the other user will be able to decrypt the copy stored on the server or on a backup tape. Or, I can be really slick and copy their GPG keys up onto the same network drive.

This job would be much easier with Linux and shell scripts–the language is far less clunky, and file naming is far less kludgy–but I have to make do. I guess in a pinch I could install the NT version of bash and the GNU utilities to give myself a Unixish environment to run the job, but that’s a lot more junk to install for a single purpose. That goes against my anti-bloat philosophy. I don’t believe in planning obsolescence. Besides, doing that would severely limit who could support this, and I don’t have to try to plant job security. I always get suspicious when people do things like that.

If you found this post informative or helpful, please share it!

2 thoughts on “Encryption on the cheap

  • March 5, 2002 at 3:19 am
    Permalink

    Disspam is indeed an idea whose time has come. I had perl already installed but also had to install the modules noted in the readme. Other than that no problems installing with my Red Hat 7.2.

    It did a pretty good job in the one trial I’ve had time to give it so far. It did let some spam through and my first thought was "where’s the INCLUDE section?". But that gets you back to having to manually configure just like adding rules to send mail from certain sources to the trash. I only know a little perl, but I’m interested in digging into the code to see if Disspam relies solely on lists from the sources in the [RBL] section of the .conf file.

    In Windows 2000 the way I read Microsoft article Q255026, the first local admin logged onto a computer will be the recovery agent, able to decrypt any files encrypted on that computer. Any domain admin will be a local admin also. Probably any other domain admin could add himself as a recovery agent, though. So I’m thinking that the only way to really lock all others out with just NTFS is with a standalone PC where these 2 are the only admins.

    You can export the recovery certificate, but I’m not sure about installing it on another machine and using it to read files from the first machine, as I take it that the files are to be readable on both users machines.

    I hadn’t tried deltree and move in Windows 2k, but just did. Move works from a command line on my Windows 2000 Pro machine on an NTFS drive, but I only tried moving one file (not a long filename) from one directory to another. Deltree is apparently gone. You might be able to do more with Linux using Samba but I don’t think anyone has a very workable way for Linux to reliably read Windows 2000 NTFS. Anything I’ve heard of so far seems to involve bleeding edge kernel hacking.

    I’ll be interested to see how well your method works out.

  • March 5, 2002 at 4:24 pm
    Permalink

    I checked, and move is present on W2K. Not sure what I was thinking, maybe it was missing in NT4. I learned how to make it live without both of them.

    Linux reads NTFS just fine (and has for a while) but it won’t write to it reliably.

    Here are the batch files, newly simplified and cleaned up, and presented with absolutely no assurance they do anything useful whatsoever:

    rem encrypt.bat
    zip -9 -r %temp%private.zip "%userprofile%desktopprivate documents*.*"
    gpg -e -r user1@e-mail.com -r user2@e-mail.com %temp%private.zip
    copy %temp%private.gpg "%userprofile%my documents"
    del %temp%private.gpg
    del %temp%private.zip
    xcopy "%userprofile%my documents*.*" "N:my documents" /e /h /k /x /y

    rem decrypt.bat
    copy "N:my documentsprivate.gpg" "%temp%"
    gpg "%temp%private.gpg"
    md "%userprofile%desktopRestored"
    unzip -o "%temp%private" -d "%userprofile%desktopRestored"
    del "%temp%private"

Comments are closed.