Yes you probably need public/private key encryption. Pretty Good Privacy (PGP) uses this, has been ported to Perl, and is available in modular form. See this thread Favorite PGP module for web-to-email forms? for discussion and links to the module and sample code.

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

You might be able to use a one-way function.

For example, the traditional unix password mechanism takes your password and runs it through the crypt() function (with a little salt) to get an output string which is stored in the /etc/passwd file.

What it *doesn't* do when you try to log in is decrypt the stored password and compare it to what you just typed. Instead, it passes what you just typed through the same one-way function (with the same salt) and compares the outputs.

The theory is that it is computationally expensive to recover the input to the one-way function. In practice, the traditional unix scheme using the crypt() function can be brute-forced fairly easily these days (for example by trying all possible or all likely combinations of inputs), but other hash functions (for example MD5) exist and are good for todays use. (A relevant perl module here is Digest::MD5).

If you really need to recover the data (rather than compare it to some other data) then you can't do this, but obviously any program you write which is able to recover the encrypted data can be used by anyone else who acquires the privilege to execute it (or read its data files containing the key information).

As I'm sure you are aware, the whole area of encryption etc is fraught with seemingly-good ideas which don't help at all or are actually counter-productive, so it is difficult to offer detailed helpful advice.

Good luck.

Assymetric crypto (public/private key crypto) is useful when you, and only you, have access to your private key. It works well in scenarios like sending data from one party to another (eg. through email), because the sender can encrypt using the public key, and the recipient decrypts using the private key.

But I'm not sure if that really applies to what you are doing.

For example, if you're building a system that interfaces with this database, then you are going to have to both encrypt and decrypt the data therein. So your decryption key is going to be just as exposed as your encryption key--in which case it doesn't buy you a whole lot to have two different keys.

I think that you need to determine the scenario of when you are going to be encrypting data, and when you will be decrypting it. This will give you some hints as to use one symmetric key or a public-private key pair. If it is still unclear, describe these scenarios in more detail.

BTW: if you do end up wanting assymetric crypto (which I'm not absolutely sure that you need), you could check out Crypt::OpenPGP or Crypt::RSA.

If you go the symmetric crypto route, Rijndael (Crypt::Rijndael) is a very good cipher.

Don't encrypt arbitrary strings, mmmmkay?

If these strings are sent in by users (or can be eavesdropped on by a Bad Person), you open yourself up to a known-plaintext-ciphertext attack. If you have taken precautions to foil Eve and generate the strings themselves, ignore this post.