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 <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >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 >[EMAIL PROTECTED] ii, inc. > >http://www.interaction.net >- Specializing in Designing Interactive Websites - >- and Searchable Internet Databases - > > > > > Thanks! Bill Bill Stewart, [EMAIL PROTECTED] PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
