This project is read-only.

Transmitting CryptoStream directly via FTP Stream?

Jul 28, 2013 at 9:34 PM
Edited Jul 28, 2013 at 11:04 PM

This picture should say it all:

1# is the way I know it works. Simply encrypting the file first and then transmitting it. The downside of this method is that for temporary moments the File that shall land encrypted on the server needs double disk space, because of the encrypted file. After successful transmission the encrypted file will be deleted or the unencrypted file will be deleted (configuration).

The question now is, if 2# is possible. Directly transmitting the encrypted bytes to the FTP server that would result in lower resource utilisation. The reverse way is important, too.

Finally, an unencrypted file would be transmitted in a secure way with TLS/SSL and would be stored securely thanks to AES encryption. That means a very high degree of data security. On top the local user can use his local files in the familiar unencrypted way (or could use local encryption if he needs to)

Best regards
Jul 29, 2013 at 12:37 AM
I've never used CryptoStream personally, that said I don't see why you need to write a second file as opposed to just doing method #2. If CryptoStream can write back to a Stream object then you should be fine. The only problem you would run into is if
the stream needs to be seek-able in which case sockets and thus streams around them are not seek-able.
Jul 29, 2013 at 12:41 AM
The best advice I can give you is just try it. Use CryptoStream to write to the stream object returned from FtpClient.OpenRead() and see how things go. The stream is just a wrapper around NetworkStream and SslStream. It starts out as NetworkStream and switches to SslStream when appropriate. The method calls and properties make calls to one of those 2 objects accordingly.