batch encrypting customer orders on remote secure server?

[Leigh S. Jones]

> Actually, they were the ones who asked _me_ whether they would
> need to install anything as 'root'.  That's why I wanted to know
> if GPG could be installed by me in my own little section of the
> server to work.  My other concern is being able to use the
> capabilities of dev/random.

Yes, you will need to use /dev/random.  That would be critical.  My
application is automatically signing.  For that, entropy isn't
required
but the secret key password is.  But you have it easy -- you're
installing on a Linux machine and, I assume, Apache.  Should have
the flexibility to do everything you want.  It may take some
configuration tweaks, though, before they figure out how your
browsers can automatically execute the encryption script file.

> Also, do I need to compile GPG on the remote Linux machine or
> can I compile it on a local Linux machine and just upload the
> necessary files to the remote one?

If your Linux implementation is really similar to theirs then you will
probably have no trouble compiling on yours and simply copying
the executable gpg to the server.  For instance, if you both run
Red Hat Linux 7.2, then no problem.

But, if the implementations of Linux are different, such as
Mandrake and Red Hat, they might use different run-time
libraries and different locations for files.  The gnu make
program, the configure scripts, etc., work these things out for
you when the gpg program is built on your machine, but might
come to different conclusions about which will work for you
vs. what will work for your web provider.

Once gpg is built, it will execute from any directory that your
web provider wants you to put it in.  The gpgv program will not
be needed for your application, as I understand your application.

And, I think that in gpg 1.0.7 the keyserver access portion of the
program has been spun off into one or two external executables.
If the "make install" portion of the gpg INSTALL instructions is
executed, I'd assume that these external executables would be
placed into the appropriate directories.  Unless you figure out
where these belong and get your web service provider to drop
them there, then gpg would lose keyserver access capability.
As I understand your application, this would not be a problem.
You would need keyserver access only to check for updates
to keys, and you could easily encrypt to a public key without
checking for updates.

> I am looking through the archives as well.  But it seems that there
> have been significant changes in GPG and I wanted to be sure I could
> do what I want with the latest version (1.0.7).

I haven't tested it yet.  I don't know for sure that the MingW32
compiler uses the same "OSF file handles" that it used at the time
that the program code that I put into the archives was tested,
i.e., when gpg.exe1.0.6-2/MingW32 was compiled.  It probably
does still work.  That program was written for Borland C, but
I checked and the Microsoft Visual C 6 compiler has the OSF
file handles functions available.  I'd guess that they work the
same.  These issues jump out at me, because lately I've been
programming extensively using National Instruments CVI
compiler that lacks both the OSF file handle functions and any
"pipe" functions.  Those pipe functions really come in handy
when you are trying to integrate gpg and other programs.

But, as long as you are willing to either:

1) enter the password once when each credit card number
file is decrypted

or

2) only do bulk decryption on a physically secure machine
with secret keys encrypted to a blank password

or

3) use gpg agent

of come up with some other method for avoiding the entry
of passwords multiple times when decrypting, then you will
be able to comfortably perform the decryptions without
anything like my program in the archives.  Of course, there
are a lot of other options.  For instance, PGP can be told
to cache the password for a few minutes, and WinPT has
multiple decryption capability.  I could go on.  Don't make
me.  This is boring enough for the rest of the list already.