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@mudpuddle.com> To: austin-pm@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@mudpuddle.com ii, inc.
http://www.interaction.net - Specializing in Designing Interactive Websites - - and Searchable Internet Databases -
Thanks! Bill Bill Stewart, bill.stewart@pobox.com PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639