# cs161-proj2

This is a repo for `$GOPATH/src/cs161\_proj2`.

DO NOT put documents or binary here. Use git submodule wisely.

## Proposed Design Doc (Subject to change)

> CS161 Project2 Design Doc  ----Yinuo Zhang

- Section 1: Implementation

Storing client info: Each client structure contains all the keys and a filetable(explained later) for the client, and it is encrypted on the DS, this is our TCB if this is compromised, then we lost all the security. 

To encrypt the client struct, we use Authenticated Encryption, first generate a symmetric key and a sign key based on the user password, which is high in entropy (as said in the document), this is done using HKFD. Then we encrypt the struct, which has been turned into byte array via json, and sign on the encryption using the sign key via HMAC function, this is believed to be secure as long as the underline hash function is secure. This way we both achieve confidentiality and integrity of our basic client info. 

Storing client file: We do not rely on the username, for each file, we build a file structure list, each structure contains the UUID of the current piece of file(each piece receives its own random UUID) the symmetric key and signkey that is used specifically to encrypt and sign this piece of file, and the filename. 

To encrypt each piece of file, we first we generate a UUID which is completely random using new_UUID function, then generate its symmetric and signkey using random generator, and then using Authenticated Encryption to encrypt this piece of file data, and store the resulting signature and encrypted data inside another shell structure in the DS, with the entry of its UUID. This ensures both confidentiality and integrity, and this also achieves IND-CPA since each piece is encrypted using its own random IV and own random keys, this also ensures forward-secrecy since when we rewrite any piece of the file, or even reload it, the keys and IVs are completely different and independent of previous ones.

To maintain the file info, we build a filetable in each user struct, which is a map between file name and the file structure list, this grants owner all info to decrypt, since we can rely on the security of user struct, the security of each file necessarily follows. 

To append is easy, we encrypt this piece of file and get back its file structure, and we can just append it to the file structure list. The decryption for any file is just the combined data collected from each file structure in the list corresponds to that file name.

Sharing the file takes two steps, first build a file-transfer structure, which contains all UUIDS, all symmetric keys and sign keys from all file structures in the list corresponds to the file name, then randomly generate another symmetric key and sign key to encrypt this file-transfer structure using Authenticated Encryption just as above to ensure confidentiality and Integrity, then randomly generate a UUID to store this file-transfer structure in the DS in that entry, finally append the symmetric key, sign key and UUID altogether into a data array, encrypt this array using public key encryption (recipient’s PubKey) and DIgital signature (sender’s signKey) this again ensures confidentiality and integrity. Finally turn the encrypted data and signature into a string, which is our magic_string. Upon reception, the recipient can decrypt and check for integrity on the message, then use the decrypted data (which includes symmetric key, sign key, UUID) to do another symmetric key decryption and also checks for integrity for the file-transfer struct stored in the DS, then it just copies the value pairs this structure and add them to his own file structure list under the name of filename (invented by him/her self) The recipient never knows the filename of senders since we never encrypt or send this info. 

To revoke, the user simply first loads the file data, then traverse the file structure list under that filename and delete every entry given by every UUID in every file structure, this will remove the encrypted data of every single piece of file entirely. Then to recreate it, just call StoreFile again with the previous loaded data, since each Storing will create completely new and independent random keys and UUIDs, this again ensures forward secrecy and makes our scheme IND_CPA. For the users previously shared with this file, since all entries are deleted, they cannot load any piece of file using their previous UUID, even in the worst case where the same content is again inserted into the same entry (with negligible probability) the user still cannot read that file since the keys to decrypt that file is also re-picked from random)

- Section 2: Attack Models

Attack on client info: since the client info is stored in DS, we cannot rely on obscurity by hiding the UUID of our client, since the attacker can always do a brute force search on the DS and check for every UUIDs, therefore, we encrypt and authenticate the client info so that the attacker cannot break the scheme even though the UUID is known to the attacker. 

Attack on file info: again, we cannot use filename to generate UUIDs and keys, since filename is often low in entropy, the attacker can use a precomputed dictionary of keys to perform the attack. therefore, we need to generate completely random keys and UUIDs for each file piece. Since our file is always seperated into pieces of info, and each piece is encrypted with its own random keys and signatures and IVs, we thus gauarantee that even if one piece of the file is compromised, the attacker cannot use that info to decrypt other piece of the file. The attacker cannot even change any piece of the file, since even if one piece of file is changed, its own signature will not match, which will shutdown the entire decryption process. Therefore, we not only achieve integrity but also prevent the attacker from doing a piece-by-piece attack on the user files. 

Attack on file sharing: We first encrypt a file transfer struct, which is a copy of the owner’s file structure list corresponds to certain file name, and store is just like a regular file (using the same authenticated encryption method) in the DS, therefore, any attack model breaking this scheme will also break the security of our previous discussed user file security, and a simple reduction shows that this file transfer struct is secure. The keys and UUIDs to find and decrypt this transfer struct is send via public key encryption and verified using a digital signature, so the attacker cannot decrypt the keys and UUIDs as long as the underlying public key encryption method is secure, the attacker also cannot forge signature so that the receiver can always verify the authenticity of the message string. Therefore, the file sharing system is secure also. 
