I am looking for ideas today.
The problem: Sensitive files are sent via REST (over SSL, of course) to a third-party server. I cannot touch them programmatically until they arrive at the server. Those files are stored there until users download them via SFTP and delete them from the server. Each file will reside for about a week on this server.
The goal: Secure the files at every step until they are on the users' machines.
My plan: Because I cannot encrypt the files until they arrive at the third-party server, my only hope for security is a SSL connection. I would like to ensure only my files are saved on the server, so I am thinking I should send a password along with the files. What is better than a static password? I would like to use unique passwords, but I'm not sure where to start.
As a file is downloaded onto the server, I will copy the stream into temporary memory and encrypt the data with RSA. I can keep the private key on the users' machines and store only the public key on the server. (Note the server has no hardware encryption.) When a user connects via SFTP, he can download the encrypted file and only decrypt it on his own machine once he is offline. Is there a better way to keep files until a user can access them?
Any other suggestions would be greatly appreciated!
Update After tinkering and reflecting, I have found this solution to be the most fitting given my limited control over the starting server: https://stackoverflow.com/a/19758235/1008395
In summary, send the files from A to B via SSL. Use AES-256 encryption with a randomly generated key when the file arrives at B. Encrypt that random key with RSA 2048 (the public key). Save everything on the server until it can be downloaded. Once the files are on the users' machine, decrypt the random key with RSA's private key (stored only offline) and then use that key to decrypt the AES encryption on the file. The reason for the hybrid Symmetric/Asymmetric encryption is because I want the public-private key format but RSA limits the size of the data to 256 bits (for 2048; it is only 128 bits for 1024). So we encrypt the data and key separately then send both. Yes, this results in 3 keys: One randomly generated each time, one public key, and one private key (which never sees the light of the internet).
Nihvel nailed this with even more security by encrypting the file before sending and saving the encrypted random key on Server A. Thus the two were never on the same server. Thanks for all your help!