(Cryptography: encrypting files before storage in the cloud):
The project consists of a software implementation of a method to pre-process a file before storing it on a cloud storage server so that the server cannot read the file content but a desired peer can. More precisely, you need to build a triple of algorithms:
On input a key $k$, and a file $f1$ with filename $fn1$, returns a related file $f2$ with a related filename $fn2$.
On input a key $k$ and a filename $fn1$, returns a string $fk$ and a filename $fn3$.
On input a file $f2$ with filename $fn2$, and string $fk$, returns a file $f3$.
such that the following requirements hold:
For any file f with filename fn1, after randomly choosing key k, and obtaining fn2=PreProcess(k,f1,fn1), (fk,fn3)=Authorize(k,fn1), and f3=Recover(f2,fn2,fk), it holds that f3=f1 and fn3=fn2; and
Privacy against cloud storage server:
The pair $(f2,fn2)$ leaks no more information about $f1$ than the filename $fn1$ and the length of $f1$.
Integrity against cloud storage server:
Detection of file modification by the cloud storage server.
Note that defining your method so that $fn3=fn2=fn1$ will not violate the requirements, but you are encouraged to try more interesting approaches.
Rationale behind the design of the three algorithms PreProcess, Authorize and Recover goes as follows:
- With Preprocess, you (the file owner) want to encrypt the file before posting it on the storage server; encrypting the file and leaving the same name may not be a good idea (from a privacy point of view) since file names sometimes reveal the file content; accordingly, in Preprocess you have a chance to assign a new name $fn2$ to the encrypted file; moreover, encrypting all files with the same key is not a good idea as later you want to selectively authorize decryption of some but not all of the files; accordingly, you generate an encryption key $fk$ for each file as a function of the key $k$ and the original file name $fn1$.
- After Preprocess is run, you can post the encrypted file with the new name into the storage server (this part does not need to be implemented, but it would be nice to show it in your presentation).
- At this point, others could download or copy the encrypted file, but only those you choose can decrypt it; thus, you run Authorize to regenerate $fk$ from $k$ and $fn1$ just as done in Preprocess, and generate $fn3$ just as you generated $fn2$ in Preprocess (thus, $fn3=fn2$). Now you could send fk to your desired peer (this part does not need to be implemented).
- Your peer can use $fk$ received from you and the encrypted file downloaded from the storage server (even this part does not need to be implemented but it would be nice to show it in your presentation), to run Recover and successfully decrypt the file, after checking that it was not modified.
You have to implement the three algorithms PreProcess, Authorize and Recover using a suitable set of cryptographic primitives (e.g., block ciphers, block cipher modes of operation) and cryptographic schemes (i.e., symmetric encryption schemes, asymmetric encryption schemes, message authentication codes, signature schemes, etc.). The implementation has to be in C or C++; examples of usable programming environments include Visual Studio Express and Eclipse, which are freely available from the Internet. You will be allowed and encouraged to use software libraries from the Internet (e.g., Open SSL, Crypto++, etc.) whenever possible, and will have to produce a powerpoint presentation detailing implementation approach, software documentation, property satisfaction and execution demo. The project should be realized by single students or a team of 2 students, and comes with a minimal assignment; any additional work you perform will be considered extra credit work. Teams are supposed to split the amount of work more or less equally among the team members. If a team splits the work in a way that is too unbalanced, the score given to team members may be suitably unbalanced.
Your executable files PreProcess, Authorize and Recover should be able to run, for instance, with command line inputs as follow:
./preprocess key.txt file.txt filename.txt (returns 'efile.txt' and 'efilename.txt') ./authorize key.txt filename.txt (returns 'fkey.txt' and 'sfilename.txt') ./recover efile.txt efilename.txt fkey.txt (returns 'sfile.txt')