GnuPG and PGP are complimentary key systems - the key used for encryption is a different key than the key used for decryption. It might be possible for you to store the decryption key (the private key) somewhere pretty safe. GnuPG and PGP both store the private key encrypted with some good symmetric cipher like DES or Blowfish, so you need a passphrase to recover the private key for decryption/signing.
By the way, Tango does MD5. It's the action called "hash." This works perfectly. MD5 is a one-way operation - you can never recover the plaintext (we hope.) If I can have the soapbox for a moment... I know a tiny bit about data security and what I do know leads me to conclude these topics are well above my level of comprehension and that tiny subtleties of implementation can render a seemingly secure system completely unsecure. Also, recent virus/worm problems convince me that the greatest threat to security is from the operating system which is largely out of our control. Each developer is best able to assess the risks and benefits of each solution. I would be very reluctant to build a system where security is important because I doubt my ability to garantee it. Also, as a customer, I doubt I would be disturbed about being asked to re-enter my credit card number - I would prefer knowing that the number wasn't being stored (the same goes for my address, phone number, etc.) On Tue, 28 Jan 2003, Jason Pamental wrote: > I've started to look at the GnuPG package - it looks like there are > scriptable versions for Windows, Mac and Linux. If I can get a simple > example working, it should be workable to incorporate into a TCF/Custom > tag. The dilemma you still have with that though is key creation and > storage. To be really secure you need to not have the key available on > the same server, although putting the key in a run-only file outside > the web root is a start. > > Anyone have some ideas on that aspect? Perhaps only an SSL-encrypted > form to upload the key from your browser, save it to a user-scoped > array and never write it to disk on the server? That way the key would > never be stored on the server at all. > > Jason > > On Tuesday, January 28, 2003, at 10:37 PM, Fogelson, Steve wrote: > > > Well the comments posted to the list pretty much confirm what I had > > heard > > before, that the present encrypt/decrypt tags offered with Witango are > > either not tight enough or not practical in a production environment. > > > > I really am looking for tags using blowfish or MD5 technology. You can > > tell > > I am by no means an expert or novice in the encryption area, but these > > seem > > to be the buzz words at this time. > > > > Anyone doing this that might be interested in selling their custom > > tags and > > related code? > > > > It may help to know if there are others on the list that are > > interested in > > this option. > > > > Steve Fogelson > > Internet Commerce Solutions > > > > -----Original Message----- > > From: Eric Weidl [mailto:[EMAIL PROTECTED]] > > Sent: Monday, January 27, 2003 7:14 AM > > To: Multiple recipients of list witango-talk > > Subject: RE: Witango-Talk: Credit Card Security > > > > > > Hi, > > > > A couple of specific comments: > > > >> Unfortunately I have it on very good authority that the @CIPHER tag > >> does > >> not work as well as it should. Here is what Jess told me: > >> > >> "Unless somebody has changed something in the last > >> year, all of Tango's <@CIPHER> stuff (besides the > >> hash) is basically worthless for the purposes of > >> security. > > > > There may be some truth to that comment, but it is due to the nature > > of the > > problem and not necessarily the @CIPHER tag itself. Yes, the BitRoll, > > Caesar, and Rot13 types supported by @CIPHER are trivial encryption > > methods > > and don't have a place in a production system. > > > > > > > >> The one time pad actually isn't a one time pad at all, > >> it's a rotation cipher, and on top of that it doesn't > >> work properly... > > > > OneTimePad is by definition a rotation cipher. It even says so right > > in the > > manual. Criticizing it for being so is like complaining that a dog has > > fur. > > > > The power of the OneTimePad is based in the keys and their management, > > not > > the cipher algorithm itself. In a perfect world, OneTimePad is the most > > secure encryption mechanism available. Why? Because, in a perfect > > world, > > the keys are *NEVER* reused and never stored after use. > > > > Obviously not storing keys is difficult in the real world, so in > > practice, > > the OneTimePad falls far short of its theoretical performance. > > > > As to your comment that it doesn't work properly, I've never heard or > > experienced any issues with it. > > > > > > Eric > > > > _______________________________________________________________________ > > _ > > TO UNSUBSCRIBE: send a plain text/US ASCII email to > > [EMAIL PROTECTED] > > with unsubscribe witango-talk in the message body > > _______________________________________________________________________ > > _ > > TO UNSUBSCRIBE: send a plain text/US ASCII email to > > [EMAIL PROTECTED] > > with unsubscribe witango-talk in the message body > > > > > -- > ____________________________________________________________________ > > Jason Pamental, President > [EMAIL PROTECTED] > > Bathysphere Digital Media Services, Inc. > http://bathyspheredms.com > ____________________________________________________________________ > > Tel: 401.490.6830 Fax: 401.490.6831 > ________________________________________ > > > A North American Distributor for Witango (http://www.witango.us) > > Rapid Web Application Development - XML Execution Engine > > > ________________________________________________________________________ > TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] > with unsubscribe witango-talk in the message body > ________________________________________________________________________ TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] with unsubscribe witango-talk in the message body
