Using [....RCM]ZIP-ALPHA

[Richard W Hunt]

I have a user who has a requirement to be able to encrypt and zip a file in a way that the user on the other end can unzip and decrypt. So part of the issue is commonality. We need to use something the other party in this operation also can use on a non-VMS box.

We don't have a commercial copy of PKZIP for Alpha or anything like that, but there is the copy of ZIP-ALPHA in the ...COMPAQ.SVCTOOLS... path. It says it supports a -e option that lets you specify a password for encryption.

When we try to run the ZIP operation, it asks for the password. That's not a surprise. What IS a surprise is that it won't let us put that whole procedure in a script. Even if you do various DEFINEs on SYS$INPUT, STDIN, TT, or just about anything else, it goes to the terminal for the password prompt. If you run it in batch, it bombs saying STDERR isn't a terminal. (Which, OK, it isn't.)

Ignoring the limited wisdom of including a password in a script, which I can address separately, has anyone ever used that utility to encrypt/zip a file from a command file or batch environment? What channel is it using to do the input?

[Hoff]

Current zip is on Freeware V8.0.

http://mvb.saic.com/freeware/freewarev80/

and the current released and upcoming beta versions are available at the canonical info-zip site:

http://www.info-zip.org/

zip 2.32 and unzip 5.52 are current.

The stderr channel is usually SYS$ERROR.

I've noticed that most versions of zip and unzip tools either distributed by or used by HP can be stale, and non-current versions have had security exposures. AFAIK what's on Freeware V8.0 is (still) current. While I'd trust the SVCTOOLS site, I'd verify the version.

Source of info-zip is available. Alter the code and make the tool do what you want here.

Do recognize that zip encryption is weak.

Here's how to recover the zip password:

http://www.woodmann.com/fravia/mike_zipattacks.htm
http://www.tech-faq.com/recover-zip-password.shtml

Per published materials, even one of the older attacks on zip encryption requires about two hours of processing on a Pentium-II 500 MHz box, and tools are readily available.

Regardless, do let IT management or security management or privacy office know the details implementation and of the embedded password here, too. Given the increasing frequency of data breaches, I'm expecting IT staff and corporations to soon be held more fully accountable for exposures; it is often best to kick this responsibility and this decision upstairs.

For a no-password security requirement, I'd likely look to digital certificates, or better. Not to a password.

And I might well look to GnuPG tools, and to higher-grade security in general.

Having had my own personal data exposed in two separate and unrelated cases over the last two weeks -- in the first case, reportedly by the security auditors themselves -- I not sympathetic around improvised and ad-hoc security, nor to "solutions" that are intended to sort-of comply with encryption requirements.

Do it right and do it to the best of your abilities. Or don't do it.

Stephen Hoffman
HoffmanLabs LLC

[Jess Goodman · Accepted solution]

This works fine for me (ZIP 2.31 and ZIP 2.32)

$ TYPE JUNK.COM
$ define/user sys$command sys$input:
$ zip -e junk.zip login.com
abcdef
abcdef
$ exit

$ @JUNK
Enter password:
Verify password:
adding: LOGIN.COM (deflated 55%)

[Steven Schweda]

Use the source, Luke. Or, as a newer Zip
says:

ALP $ zip3gl -h2
[...]
Encryption:
-e use standard (weak) PKZip 2.0 encryption, prompt for password
-P pswd use standard encryption, password is pswd
[...]


"-P" was left undocumented because of the
limited wisdom of including a password in a
script, but we finally got tired of fielding
questions about it.

If your Zip pre-dates version 2.32, I'd look
for that, or, better, the new pre-release
3.0g ("BETA") kit.

http://www.info-zip.org/
ftp://ftp.info-zip.org/pub/infozip/beta/

UnZip 5.52 or 6.00d ("BETA"), too.

[Robert Gezelter]

Richard,

Perhaps take a look at the GnuPG (the reference to the OpenVMS port is at http://h71000.www7.hp.com/opensource/opensource.html ), the full project www pages are at http://www.gnupg.org

While a quick pass on gnupg.org does not find an authoritative citation, my recollection is that the encryption process does a GZIP of the file prior to encryption.

I hope that this is helpful.

- Bob Gezelter, http://www.rlgsc.com

[Steven Schweda]

If I were serious about using encryption with
some the strength, I'd choose GnuPG over the
Zip ("traditional PKWARE") method, too. Of
course, I'd get it from me, not HP:

http://antinode.org/dec/sw/gnupg.html

Call me picky, but when someone breaks the
VAX build by adding IA64 support (badly) to
the (crude) builder, my expectation of
quality falls off.

You haven't described "the other end", but
as with most UNIXy freeware, if a program is
available for VMS, you should be able to find
it for practically anything else, so I'd
assume that GnuPG is available there, too.

[Richard W Hunt]

We are still researching what the other side of the pipe has. Were it left to me, I would have pushed for the SSL utility encryption and for that, PKI certificates would be very much a viable method. But as I said, part of the problem isn't what WE have, it is what the OTHER guys have - or don't have. Thanks for the pointers, guys. I'll see what I can make work here.

I'll also assign points in a second pass after this follow-up posting and after I've had a chance to try a couple of the options you've offered. Until I find a viable short-term workaround, I won't close the thread yet. My goal WILL be stronger encryption via certificates but I think we have to give the other guys time to do some research on what THEY can do programatticaly.