Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options

public key encryption

by perrin (Chancellor)
on May 28, 2004 at 21:28 UTC ( #357378=perlquestion: print w/replies, xml ) Need Help??
perrin has asked for the wisdom of the Perl Monks concerning the following question:

Does anyone have recommendations for the best perl interfaces to public key encryption? I see tons of them on CPAN, from SSLeay to OpenPGP to GPG to RSA. Before I dig through them all, I'd appreciate any advice about which ones are best. My needs are fairly basic: encrypt chunks of text of varying length using a public key and decrypt them later on a different machine.

Replies are listed 'Best First'.
Re: public key encryption
by tilly (Archbishop) on May 29, 2004 at 01:45 UTC
    I had to do something like this where I have to encrypt data on a public server, and very rarely have to decrypt a batch of encrypted entries in a one-off job.

    After some time and thinking I found it easiest to use gpg. For encrypting I ran it with IPC::Run and the command-line that I used for encryption was:

    gpg -a --no-secmem-warning --always-trust -r username -e
    The always-trust is because I didn't want to worry about setting up the trust relationship so that it would accept the public key as valid - it is a public key, it isn't secret.

    The private decryption I do by hand using gpg's decrypt-files to do a bunch at a time. Another co-worker is also able to decrypt the files, and the necessary key and instructions is also on a floppy in case the first two of us die.

    This solution would not be acceptable if I needed to decrypt data more often.

      Thanks, this is what I ended up with too, since the only GPG module that will pass its tests on Fedora 1 and Perl 5.8.3 is GnuPG::Interface and it relies on questionable IPC::Open3 stuff.
Re: public key encryption
by hv (Parson) on May 28, 2004 at 23:43 UTC

    I've done some work recently with Crypt::OpenPGP. The interface seemed intuitive enough, but I found it challenging to work with - in part, I suspect, because I usually find it easier to understand code than docs, and tracing the code through the maze of packages was somewhat challenging.

    The biggest problem I had was a hash-order dependency bug, which caused random results with recent perls. I offered the author a workaround for the particular case that bit me, but fixing it properly will need a bit of reworking of the internals.

    It also didn't do everything I needed (to encrypt an arbitrary message given an arbitrary public key block) - see Crypt::OpenPGP - finding and using preferred SK algorithm for the extension I needed to achieve that.

    Once I'd worked through those two problems I was able to put it into production, and have had no problems since then.


Re: public key encryption
by derby (Abbot) on May 29, 2004 at 02:14 UTC
Re: public key encryption
by Anonymous Monk on May 28, 2004 at 22:18 UTC
    I recently went through all of them for something very similar and found that I like use Crypt::Blowfish_PP; the best. It seemed to have fewer limitations and it compiled and installed nicely.
      Thanks, but Blowfish is not a public key encryption algorithm, it's a shared-secret algorithm.
Re: public key encryption
by esskar (Deacon) on Jun 01, 2004 at 00:27 UTC
    i prefer SSLeay over *PG; the interface is probably much harder but it'a trust thing, you know! :)
      How do you use SSLeay? I couldn't find any perl module more recent than 1998, and the current crop (Net::SSLeay and Crypt::SSLeay) do not appear to provide access to any of the public key encryption routines. It seems that the OpenSSL project took over from SSLeay and there is no equivalent perl API for it.
Re: public key encryption
by MidLifeXis (Monsignor) on Jun 01, 2004 at 17:01 UTC

    First I would find which PK method(s) meet(s) your needs. Then, and only then, would I look at which API feels the best.

    The order you seem to be doing this in is akin to deciding to use a shovel, sledge hammer, or hoe based on how the handle feels in your grasp.

    Just my $0.02.


      Are you saying that you don't believe public key encryption is a well-understood problem at this point? It was my impression that it makes very little difference which method one uses. All of the ones I've seen seem to support what I want do, i.e. encrypt with a public key and decrypt with a private key later on a separate machine.

        No, but if you have requirements that you need to meet as well (customer only uses MS products, legal will not allow anything with GNU in it, key size limitations, implementation limitations (netscape and poor initial seed selection, anyone?), strength of cipher used, and so on), then those should be evaluated first, or at least balanced with the desire to use the XYZ API.

        A problem being well understood does not preclude a solution from having flaws in either design or implementation, nor does it preclude other requirements from limiting your solution set. If you have no requirements other than that0 you can transform it into and out of a secure1 form, then ignore my post.

        That is all that I am saying.


        1 - any definition of "secure" brings along with it other baggage, which I would also consider as requrements.


        (minor) 0 - Added missing word.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://357378]
Approved by Belgarion
Front-paged by stvn
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (7)
As of 2017-03-23 23:23 GMT
Find Nodes?
    Voting Booth?
    Should Pluto Get Its Planethood Back?

    Results (294 votes). Check out past polls.