|
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). |
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] |
|
|
| [reply] |
|
