in reply to RFC Data::Encrypted

In order for the module to be able to get the encrypted data back, either
1) the RSA key must not have a password, or
2) the script must have the RSA key's password built into it, or
3) the script will have to prompt the user for a password
Numbers 1 and 2 are insecure. Number 3 is hassle.

Why do you use public-key cryptography for this? It seems like conventional cryptography would work just as well. Better, in fact. Since other people have access to my public key, they could use it to encode some malicious perl code, and Data::Encrypted will happily feed it to eval.

Replies are listed 'Best First'.
Re: Re: RFC Data::Encrypted
by Anonymous Monk on Jul 11, 2001 at 01:13 UTC

    Thanks for your comments.

    First off, to answer your second concern, I'm now using Storable's freeze/thaw so I'm no longer eval-ing code directly.

    Secondly, you should never execute code that someone else has sent you; see mjd's Memoize Makefile.PL for example. I never said that Data::Encrypted would make that safe.

    Now, to your first point (about security vs. hassle). You are absolutely correct: #1 is the way I currently use it, which means that it is as secure as my unix filesystem is secure (i.e. if my private key can be obtained, then it's no longer secure). I don't want to do #2 because it defeats the whole purpose of not storing sensitive info in plaintext.

    #3 is not really quite so bad: I could detect that a passphrase is required to unlock the stored data: you would only be prompted for it once, and it would be the same passphrase you always use. (As opposed to that pesky database login/password that you only use once a month to generate the new sales report, and have to always lookup (or store in the script in plaintext)).

    Of course you're right, if #3 becomes the "norm", then conventional cryptography would work just as well (you're passphrase is then the "salt", etc). My entire reason for using the public key RSA system was to take advantage of a system that was already in place (and could personalize/lock the script into being usable only by myself, without also knowing the right sensitive information stored within).

    Thanks again for your comments!

    -Aaron

[reply]
      Fair enough. I think it would be a good idea to put some of your explanation in the module documentation. If someone grabs your module off the shelf, they shouldn't have to work out the security implications for themselves.

      Getting rid of eval is good. Even if I'm being careful not to execute bad code, the old system gave it an easy place to hide where I might not notice it.

      Adding built-in support for #3 and using different crypto algorithms would be good ideas for future enhancements.

[reply]

In Section Seekers of Perl Wisdom