in reply to Customer data encryption

As your item 4. (and mentioned already), if you only need encrypted transmission, but are not worried about file storage at each end, just use scp or sftp, which most people should have anyway.
Also, I prob wouldn't worry about asymmetric performance from your descriptions.
As mentioned above, the "slow" bit can be the key creation, but that's a one off cost anyway, unless you intend to use a new one for each file (unlikely).

Replies are listed 'Best First'.
Re^2: Customer data encryption
by 0xbeef (Hermit) on Feb 26, 2007 at 08:46 UTC
    I feel that the customer is responsible for the collected data at his end, and should protect the output file with appropriate permissions. The original O/S config+log files are not encrypted (unless the administrator uses an encrypted filesystem scheme), but rather by default O/S permissions.

    But it is my responsibility to (at all cost) protect the customer's system info on my side, so ikegami's comment on securing the storage is important in my view. Being overly cautious is fine... and the suggestion about an alternative like a SSL webserver for uploads sounds good too.

    When I get a bit of extra time, I'll do some tests to compare the straightforward RSA file encryption against the hybrid method, and post the results. I have a hunch that the time differences will be significant if the keys are generated upfront.

    Niel

[reply]
      SFTP is actually a full featured remote file system protocol. Using it, it would be posible to process the data without downloading it first to the local harddisk. You could even write the output file directly on the remote host so sensible data never gets stored on your system.

      Net::SFTP or Net::SFTP::Foreign would allow you to do so.

      For maximun security, ssh keys should be protected by a keyphrase, but that would require to launch the process manually.

[reply]
        Regarding SFTP, I would not like to make to make many assumptions about the customer. Consider the network policies of the institution. At most banks where I provide support, almost every outgoing protocol (FTP/SSH/SFTP) is blocked. Some organisations ONLY allow HTTP/HTTPS, so I would then have to set up a SSH tunnel over HTTP, which adds additional complexity and assumptions into the mix.

        In other words, if I do provide an SSH/SFTP mechanism, I would consider it a secondary method.

        Niel

[reply]

In Section Seekers of Perl Wisdom