Integrated End-to-End Encryption
1st, a comment - this program is awesome! Well deserved kudos. Of course, in production (with openssh), it surely has to be combined with chroot (I had good luck with this: <invalid hyperlink removed by admin>).
For a feature request, consider the following:
1-SSH + SFTP provide a secure password exchange (asymmetric), and an encrypted stream (symmetric) to transfer the files. In the normal case, a user would transfer a file to the server, where (on the server) it is finally stored in a home directory or someplace, just as the user sent it.
2-When providing a service for secure 3rd party file transfer, it is HIGHLY desirable to store the files encrypted on the server itself, so that even physical access to the server does not compromise security of the transferred file.
3-Right now, it is VERY HARD to implement such a system in an easily managable way. You can have various client software or drivers doing the encryption (try managing it or getting different clients to agree on what end-point solutions they will use), or you can try to use EFS on the server (complicated and also hard to manage)...but imagine if WINSCP could handle the asymmetric (RSA) encryption when storing the file, using a 2nd public key (initated on the client end), and simply encrypt the files at the same time it drops them on the server!
Believe me, it would solve a million problems for me and many others I suspect. A single client software product, implementing reasonably easy to manage end-to-end secure file transfer AND encryption. Of course, it implies the use of a (2nd) key [pair].
e.g. for each profile, there would be a private key file (as now) for the ssh connection, and an option for the 2nd key pair - public key file used for outgoing encryption, and/or the matching private key, as needed for incoming decryption.
It would work for all scenarios, but imagine a scenario where files need to go from A->B->C, where B is the server admin, and A and C want to feel secure about their files.
A server admin hands out a private key (for ssh) and a public key (PBK, encryption key) to A. A posts their files securely, encrypting them with the PBK. The server admin delivers the matching decryption key to C.
A simple mechanism that winscp could look for (like a .htaccess file) could be used to 'enforce' (loosely) the use of encryption/decription based upon a setting of the remote dir (winscp would look for a .winscp file, check if 'encrypt=yes', and show a warning/err if the current profile has no key(s). [a unix admin would mark the .winscp file owned by root}.
...of course, Winscp could also deploy symmetric stream or block algorithms for the same purpose...
Ahhh....anyway, just dreaming for now!
For a feature request, consider the following:
1-SSH + SFTP provide a secure password exchange (asymmetric), and an encrypted stream (symmetric) to transfer the files. In the normal case, a user would transfer a file to the server, where (on the server) it is finally stored in a home directory or someplace, just as the user sent it.
2-When providing a service for secure 3rd party file transfer, it is HIGHLY desirable to store the files encrypted on the server itself, so that even physical access to the server does not compromise security of the transferred file.
3-Right now, it is VERY HARD to implement such a system in an easily managable way. You can have various client software or drivers doing the encryption (try managing it or getting different clients to agree on what end-point solutions they will use), or you can try to use EFS on the server (complicated and also hard to manage)...but imagine if WINSCP could handle the asymmetric (RSA) encryption when storing the file, using a 2nd public key (initated on the client end), and simply encrypt the files at the same time it drops them on the server!
Believe me, it would solve a million problems for me and many others I suspect. A single client software product, implementing reasonably easy to manage end-to-end secure file transfer AND encryption. Of course, it implies the use of a (2nd) key [pair].
e.g. for each profile, there would be a private key file (as now) for the ssh connection, and an option for the 2nd key pair - public key file used for outgoing encryption, and/or the matching private key, as needed for incoming decryption.
It would work for all scenarios, but imagine a scenario where files need to go from A->B->C, where B is the server admin, and A and C want to feel secure about their files.
A server admin hands out a private key (for ssh) and a public key (PBK, encryption key) to A. A posts their files securely, encrypting them with the PBK. The server admin delivers the matching decryption key to C.
A simple mechanism that winscp could look for (like a .htaccess file) could be used to 'enforce' (loosely) the use of encryption/decription based upon a setting of the remote dir (winscp would look for a .winscp file, check if 'encrypt=yes', and show a warning/err if the current profile has no key(s). [a unix admin would mark the .winscp file owned by root}.
...of course, Winscp could also deploy symmetric stream or block algorithms for the same purpose...
Ahhh....anyway, just dreaming for now!
