Slashdot Mirror

Yoda2 writes "A new snapshot of the Cryptix Java Cryptography Extensions (JCE) API was released on the Cryptix.org site yesterday. You can download the file here. Among other things, this finally allows for PGP encryption/decryption of files from the Java JDK 1.4 when used in conjunction with Cryptix OpenPGP."

Yoda2 writes "A new snapshot of the Cryptix Java Cryptography Extensions (JCE) API was released on the Cryptix.org site yesterday. You can download the file here. Among other things, this finally allows for PGP encryption/decryption of files from the Java JDK 1.4 when used in conjunction with Cryptix OpenPGP."

Yoda2 writes "A new snapshot of the Cryptix Java Cryptography Extensions (JCE) API was released on the Cryptix.org site yesterday. You can download the file here. Among other things, this finally allows for PGP encryption/decryption of files from the Java JDK 1.4 when used in conjunction with Cryptix OpenPGP."

Suffering Sekret Keys asks: "When I first started working for the company I'm with now, back in 1996, I was charged with finding a way to keep our customer credit card info secure in our database. Now that I'm smart enough to realize the flaws in this system, I am wondering how you avoid the catch-22 of needing to be able to encrypt/decrypt the data on the same machine that houses it, without exposing a secret key that could make that data more vulnerable in the event of an intrusion?" This question has been submitted a few times, recently, but this was the best one out of the lot. It seems many of you are wisely concerned about private data stored on your company's net, and the risks involved if it gets stolen. Well, now is your chance to discuss various solutions. How would you securely store your customer's private information, especially when it comes to critical pieces like credit card numbers?

"I chose 1024-bit PGP encryption with a long passphrase. I use the Cryptix java package to handle the encryption from a Perl script (the reasons for this are legacy related, but I'm in the position where I can start clean if need be -- a Perl-only solution would be great).

The thing that makes me nervous is the secret key being stored on the machine that houses the database. The reason for this is so that our billing staff can handle the recurring billing. (They have a web interface where they must enter the passphrase to gain access to the credit card information.)

I have realized for a long time now that if someone gained full access to this machine, they could fairly easily run a brute-force attack on the encrypted data, if they found our secret key on that machine. But when we recently worked on our privacy policy, this potential problem became more important.

What changes could we make to our setup so that we can encrypt/decrypt the credit card information on the same machine that houses the data, while making it as hard as possible to decrypt the credit card data assuming the entire machine was stolen (or cracked)?

We are a very small company. How do "the big boys" handle these things? What is the best book on this particular subject?"

While this setup may work well for credit card numbers, what about setups that will protect other personal information like a customer's address and phone number? Would such information be practical to obfuscate in such a manner?