in reply to Compressing and Encrypting files on Windows

I suggest you look at using some of the Pure Perl crypt modules. This way you will not have to fork or pipe to an external program. I have successfully used the pure perl Crypt::OpenPGP with POE on windows. If you use this module, it will handle the compression of your plaintext before encryption as well.

If you like rolling your own, like we all do, here are some quick links to cpan. You may have a little work to do finding these when it comes time to install on windows, due to ActiveState's selective ppm distributions and encryption export regulations, but if you're this far along then you already know that :-) HTH
  • Comment on Re: Compressing and Encrypting files on Windows

Replies are listed 'Best First'.
Re^2: Compressing and Encrypting files on Windows
by hawtin (Prior) on Nov 02, 2004 at 08:46 UTC

    Thanks for the input.

    I am afraid you use of the phrase "Pure Perl" is confusing me. Normally I would take this to mean a module that is implemented purely in Perl (without any calls to C etc), but that is not the way you are using it (since at least the CPAN implementations of Blowfish and Rijndael I am using have binary elements).

    I guess when you say "Pure Perl" you are focusing on the fact that these can be obtained from CPAN (and / or ActiveState) rather than the other challange of implementing modules on OSs that provide an inadequate set of tools for developers (where if perl is available but there is no good freely available C compiler a Pure Perl module will always work).

[reply]
      Please don't take this as sarcasm, but the very first line in the POD for the modules says:

      Blowfish encryption algorithm implemented purely in Perl.

      There are no calls to C and these can be used in place of the existing modules.

      My suggestion had nothing to do with OS of choice. The PP modules will allow you to run the encryption code inline with your existing Perl and no forking or external process calls will be needed. Depending on how many calls you're making, this may be faster since you can avoid the context switch and overhead of starting an extproc.

      This is why I referenced my POE example. POE doesn't like external programs because of it's own internal event loop signal handling. Using the PP modules allows me to avoid this.

      Glad you got your code working. I'd be interested in what kind of performance you get, as I've been thinking about implementing something similar.
[reply]

        There are two different implementations of Blowfish in CPAN. As I said "the CPAN implementations of Blowfish and Rijndael I am using have binary elements" (note my wording). I know that there are Pure Perl implementations of Blowfish, and obviously you are using one of them. That was not the point of my question to you.

        From your posting (and your follow-up) you seem to be under the impression that using non-PurPerl modules requires forking or external process calls. Whereas I am using the faster XS implementation of Blowfish (which links against a dll) this also allows me to run the encryption code inline with my existing Perl.

        The benefit of Pure Perl modules comes at installation time (when you don't need a compiler), at run time I think the interface for the two implementations of Crypt::Blowfish are exactly the same. The XS version has the same interface and is faster so, as far as I can see the selection of a Pure Perl solution only makes sense in relation to your, as you put it OS of choice.

        So far the performance of my solution has turned out to be "good enough" (that is there are plenty of other places in the code that need attention before I will worry about it)

[reply]

In Section Seekers of Perl Wisdom