Rijndael is also widely recommended as an accepted standard. I think it's aka is AES, for Advanced Encryption Standard.

#!/usr/bin/perl
use warnings;
use strict;
use Crypt::CBC;
use MIME::Base64;

my $KEY = 'secret_foo';
my $string = 'yadda yadda yadda yadda';
print "input: $string\n";

my $enc = encryptString( $string );
print "encrypted binary: $enc\n";

my $mime = encode_base64($enc);
print "MIME: $mime\n";

my $mime_decode = decode_base64($mime);
print "MIME_decode: $mime_decode\n";

my $dec = decryptString( $enc );
print "decrypted: $dec\n";

my $mime_dec = decryptString( decode_base64($mime) );
print "decrypted_mime: $mime_dec\n";

############################################################
sub encryptString {
   my $string = shift;
  
   my $cipher = Crypt::CBC->new(
      -key        => $KEY,
      -cipher     => 'Blowfish',
      -padding  => 'space',
      -add_header => 1
   );

   my $enc = $cipher->encrypt( $string  );
   return $enc; 
}

###################################################################

sub decryptString {
   my $string = shift;
   
   my $cipher = Crypt::CBC->new(
      -key        => $KEY,
      -cipher     => 'Blowfish',
      -padding  => 'space',
      -add_header => 1
   );

   my $dec = $cipher->decrypt( $string  );
   return $dec; 
}

#############################################################3
[download]

Thanks, but it seems to me Crypt::CBC does not count as a module for 'Asymmetric Cryptography'?

Ooops... there is a good article at Perl Crypto which mentions Crypt::DSA and Crypt::DH.

Wasn't there news recently that RSA is flawed? I have some code at Re: Roll your DSA signatures which may get you started.

---

I'm not really a human, but I play one on earth.
Old Perl Programmer Haiku ................... flash japh

It would surprise me immensely that you could possibly “benchmark” the encryption of such a minuscule string of data.   I would suggest that you simply choose, and use, an off-the-shelf crypto library that you know will be readily available in your environment.   You won’t go wrong with OpenSSL.   Is there a compelling reason for you to look farther afield?   If so, tell us – what is that reason?   (This will help us to provide you with a more targeted answer to your real use-case.)

It would surprise me immensely that you could possibly “benchmark” the encryption of such a minuscule string of data.

--- I am not sure either, but I cannot draw conclusion before trying it. For transactions in million level, probably it might matter.

I would suggest that you simply choose, and use, an off-the-shelf crypto library that you know will be readily available in your environment. You won’t go wrong with OpenSSL. Is there a compelling reason for you to look farther afield?

--- Currently we are using Crypt::RSA, since we are working on this part of the code, we just want to explore whether there is a 'better' solution. It seems Crypt::OpenSSL::RSA is another one. It never hurts to ask Monks for more, then we can compare and choose a better one.

If so, tell us – what is that reason? (This will help us to provide you with a more targeted answer to your real use-case.)

--- I really don't have any convincing reasons to make change, but it won't hurt if there are indeed some better modules to do the job. The user case is, I need to process patient information and need to encrypt/descypt some sensitive patient data. Thanks.

Thank you for this!   Now, let me try to respond (given that all of this is IMHO ...)

Well, lessee:   Although the first response that you proferred refers to “transactions in the million level,” strongly implying that “transactions per second” is key, your second response reveals that you are dealing with “sensitive patient data.”   And this revelatiion, I must say, entirely trumps the first.   At the end of the day, no one will sue you, under US Federal Laws such as HIPAA, for any sort of deficiency in your algorithm’s performance.   They might, however, sue you for shortcomings in your protection of the resulting data.

Therefore, I suggest that you should engage in an online search of “HIPAA Best Practices”, treating all of them (of course!) as the greatest of Gospel.

At the end of the day, and if worst should come to worst, no one will actually care whether you encrypted your data “efficiently” or not.   They will only care whether or not an intruder could have managed to break it.   If you can demonstrate that your solution, first, “was based upon an already-accepted library, such as OpenSSL,” and that it employed such library “in the strongest possible way,” and that the holistic key-management practices of the surrounding business organization also were Best Practices,™ then you (maybe ...) have a fighting chance.

“Performance” is the least of your worries . . .