I am wondering if the scenario below has a name or it is something in use?
The point of it is to keep data encrypted at cloud storage which is big storage therefore cheaper, but then do not allow for the hosting provider to read the data.
Also, the point is to not allow for keys compromise so this way the key would not be stored on the desktops. The desktops would receive the encrypted data over SSL when requested.
Now technically there would have to set of Cloud Storage APIs, so I am not asking for any product but if anything like that was ever made?
So for example, Decryptor would have to use the Cloud API to read, write, seek files (cloud API allows for e.g. reading for reading and writing to / from certain offsets).
Then on the Client API, I would need to have similar API, however I am not sure what encryption method would be the best? I think I should maybe go as with the LUKS? This is because if I want to append to file or change something in the middle I would need to download e.g. 16kb block and overwrite it.
I think for the password part I can use standard asymetric encryption mechanism so this way the keys are never revealed to the client and I think the RSA keys would be good for many reasons like prevent brute-forcing and don't lock clients upon unsuccessful attempts, it would be wrapped in the SDK anyway.
The fail would be if the encryption keys are stolen or the decryption service gets compromised.
Another point is to allow typical cloud API where clients can perform regular operations on the files, e.g. normally upload, update files so standard applications can use it.
This is designed to support cloud when highly sensitive data is used and cloud cannot be used. So this would be the step to actually make migration to Cloud Storage possible. With this it's much easier to write applications and control security of it.
Example usage scenario would be like this: web cam streaming video in single MP4 file, it connects to the Encryptor on-site, the encryptor in real-time writes the data to the cloud as it goes. At the end, the streaming application needs to over-write the header of the MP4 file. The streaming app does not handle any keys which could be used to decrypt the archive. The streaming happens in real-time, but if there are glitches the Encryptor machine can buffer it for a while.
The streaming app does not need to have anything specialized except for being able to use Cloud Storage API. It may still be required to use the user cert or user / password to upload the files and it is also using SSL to do it. The files can then be viewed by VLC by just pointing to the URL on Encryptor and entering username / password, so the video can be played in real time. VLC then can seek to the point in time without need to download and decrypt the file. The whole video can be in one file so it can be edited in video editor after downloading and then can be re-uploaded.
