Re^2: any alternative modules for asymmetric encryption besides Crypt::RSA?

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.

Comment on Re^2: any alternative modules for asymmetric encryption besides Crypt::RSA?

Replies are listed 'Best First'.
Re^3: any alternative modules for asymmetric encryption besides Crypt::RSA? by locked_user sundialsvc4 (Abbot) on Jul 14, 2014 at 21:33 UTC
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 . . .

Replies are listed 'Best First'.

Re^3: any alternative modules for asymmetric encryption besides Crypt::RSA?
by locked_user sundialsvc4 (Abbot) on Jul 14, 2014 at 21:33 UTC

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 . . .