in reply to [OT] E-mail security

Encrypt the mail. I would recommend GnuPG, since it is strong, standard-conforming and GPLed (i.e. free).

I am not sure I agree with other respondents that suggested encryption may not be appropriate, or that you may gain something by double-encrypting through using an encrypted channel. Encryption can be made as strong as needed by the right choice of key length; if you need absolute security of the data for 10 years, I would recommend 2048 bit keys. And any issues with technical learning curve for dealing with encrypted mail for the customer should be mitigated by automatically decrypting and storing the data at the customer site. You really want to avoid spreading the security of your solution between multiple implementations/aspects, since you would have to make sure all are equally hardened.

There are multiple GPG modules available on CPAN to help you out with the implementation.

Replies are listed 'Best First'.
Re^2: [OT] E-mail security
by hbo (Monk) on Aug 16, 2004 at 02:42 UTC
    Arguing implementation details is fruitless without knowing the particular requirements in great detail. However, I don't believe I "suggested encryption may not be appropriate." I only meant that the 128-bit SSL provided by the web server might be enough, as long as the data were not too sensitive, and if some other factor didn't mandate that the transmission from the web server over email was necessary .

    I agree that "automatically decrypting and storing the data" would be useful in overcoming difficulty with personnel training. But I think that this adds complexity, and could only be justified if the sensitivity of the application were such that 128bit SSL was inadequate to protect the data.

    As to 2048bit keys and ten years of protection, I'd be wary of that. The number suggests you are referring to public key cryptography. Such systems are probably vulnerable to breakthroughs in quantum cryptography. Whether such a breakthrough is likely to occur in the next ten years is debatable, but a symmetric system is more likely to have a good shelf life nowadays. Second, it is very, very rare that data need protection over a term of ten years, If the data is that sensitive, using the Internet at all needs to be seriously questioned.

    But hey, Perl can handle it regardless. 8)

    "Even if you are on the right track, you'll get run over if you just sit there." - Will Rogers

      I'm thinking more and more of just encrypting and storing the input from the user as you discuss in your 2nd paragraph. Later individual therapists can log on with username and password to see input destined for them.

      Question: can you, or anyone, recommend a Perl module for encrypting the user input (I've been using Crypt::CRC for passwords and I suppose could continue with this one). Thanks!


      —Brad
      "Don't ever take a fence down until you know the reason it was put up." G. K. Chesterton