APM: GnuPG and Perl GnuPG Interface for (En/De)cryption Question (fwd)

[Bill Stewart]

Isn't this really equivalent to using Conventional-only encryption
instead of public-key encryption?  Or is there some reason you want
to keep a public key in the process?  As with any customer-chosen
passphrase, there's the wimpy-passphrase problem, but you could
do something with salt to help strengthen it.
And avoiding public key should speed up your protocol a good bit,
though you've still got a public-key phase in your SSL.

At 05:15 PM 1/24/01 -0600, Jim Choate Forwarded:

>---------- Forwarded message ----------
>Date: Wed, 24 Jan 2001 16:56:02 -0600
>From: David Bluestein II <dbii at mudpuddle.com>
>To: austin-pm at pm.org
>Subject: APM: GnuPG and Perl GnuPG Interface for (En/De)cryption Question
>
>I have a question. I want to use GnuPG (or any suitable open source
>alternative) to encrypt a credit card to store in a database. The client
>wants to decrypt them on the server and view them over an SSL connection. I
>can encrypt without a problem, but to decrypt I know I at least need the
>passphrase, but then that makes me leave the private key on the server
>(bad!). Is there a way to send both the passphrase and private key to the
>Perl GnuPG interface and have it decrypted in memory to send via SSL?
>
>We're trying to avoid having the client install the decryption software on
>their desktop (client's being such as they are) and just provide either the
>private key or the passphrase/Private key.
>
>Thanks-
>
>David
>
>----------
>David H. Bluestein II                         President & Lead Developer
>dbii at mudpuddle.com                         ii, inc.
>
>http://www.interaction.net
>-        Specializing in Designing Interactive Websites        -
>-              and Searchable Internet Databases                   -
>
>
>
>
>
				Thanks! 
					Bill
Bill Stewart, bill.stewart at pobox.com
PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639