Introduction
第二部分的作业，主要是共享和取消共享，需要实现共享链，比如Alice共享文件A给Bob，Bob也可以共享文件A给Carol。当Alice取消共享给Bob的文件A时，也会自动取消Bob共享给Carol的文件A。此外需要考虑各种各样的攻击，跑过包括上一次在内的全部测试集。
Part 2: Adding complex features
Question 2 Sharing
A file store becomes much more interesting when you can use it to share files with your collaborators. Implement the sharing functionality by implementing the methods share() and receive_share().
When Alice wants to share a file with Bob, she will call msg = alice.share(“bob”, filename). Alice will then pass Bob msg through an out-of-band channel (e.g., via email). You may not assume that this channel is secure. A man-in-the-middle might receive or modify the message after Alice sends it but before Bob receives it. After this, if Bob wishes to accept the file, he will call bob.receive share(“alice”, newfilename, msg). Bob should now be able to access Alice’s file under the name newfilename. In other words, Alice accesses the file under the name filename; Bob accesses it using the name newfilename.
You can only send one message, msg, and it will be sent only once. msg must be a string in python. During grading, we will pass this message from one client to another on your behalf.
Property 3 (Sharing)
After m = a.share(“b”, n1); b.receive share(“a”, n2, m), user b should now have access to file n1 under the name n2. Every user who this file has been shared with (including the owner) should see any updates made to this file immediately. To user b, it should be as if this file was created by him: he should be able to read, modify, or re-share this file.
This also changes Property 1 and Property 2 from above. A download() operation should return the last value written by anyone with access to the file (the owner, or anyone with whom the file was shared). Only those with access to the file should be able to read or modify it.
Sharing is tricky. Note that both filenames refer to the same underlying file, and any writes performed by anyone who has access to the file should be immediately visible to all other users with access to the file. Sharing should be transitive. If Alice shares a file with Bob who shares it with Carol, any changes to this file by any of the three should be visible to all three immediately. Sharing a file with someone who has already received it results in unspecified behavior (you may do whatever you choose). It is okay if the storage server learns which other users you have shared a file with.
We require a minimal amount of efficiency: assuming a file (of size m) is shared with n users, and Alice shares the file with a new user, you may perform a linear (in n + m) number of either public or private key encryption operations. This is simple to achieve: any reasonable scheme should be at least this efficient. It is possible to do significantly better—and you are free to do so if you choose—but we will not evaluate you on this.
Your client may only keep state for performance reasons. Your implementation must work if your client is restarted in between every operation. Any state maintained on your client must be able to be reconstructed from data that exists on the server. Your clients may not directly communicate with each other.
Again, you do not need to worry about rollback attacks with sharing. The server may rollback state and remove a client from receiving updates. However, this should only be possible if it is a complete reset to an old state.
Question 3 Efficient Updates
For this question, you must efficiently handle very large files—potentially multiple gigabytes long. Design and implement a solution for efficiently updating files that are already stored on the server.
This makes maintaining confidentiality and integrity much more difficult. Be aware that when the server is malicious, it can perform arbitrary actions at arbitrary points in time during your execution. For example, you cannot assume that two consecutive calls to server.get(f) will return the same value.
You do not need to handle the case where two valid users are interacting with the server simultaneously: you can assume only one user will interact with the server at any point in time. (That is, you do not need to worry about implementing locking.)
The requirements are exactly the same as Question 1, except that now we want your solution to be efficient when making a small update to a large file.
By efficiency, we are referring the amount of data that must be transferred over the network connection to the storage server. By “update”, we are referring to the case where the user invokes upload(f, v2) on a file f that was previously uploaded and whose previous contents were v1. Your solution only needs to be efficient for updates that replace some bytes of the file in place.
Question 4 Revocation
Remote collaboration is a difficult thing, and, unfortunately, one of your collaborators has betrayed you, and you can no longer trust them. You realize that you need to revoke their access to your files. Implement the revoke() method, which allows a user to revoke someone else’s access to a given file. You can’t stop them from remembering whatever they’ve already learned or keeping a copy of anything they’ve previously downloaded, but you can stop them from learning any new information about updates to this file.
Only the user who initially created the file may call revoke().
Property 4 (Revocation)
After calling revoke(otheruser, name), otheruser should not be able to observe new updates to name, and anyone with whom otheruser shared this file should also be revoked. Except for knowing the previous contents of name, to otheruser, it should be as if he never had received the file.
This single property has several hidden implications which may not be clear right away.
Suppose that in the past, Alice granted Bob access to file F, and now Alice revokes Bob’s access. Then we want all the following to be true subsequently:
- Bob should not be able to update F,
- Bob should not be able to read the updated contents of F (for any updates that happen after Bob’s access was revoked), and
- If Bob shared the file with Carol, Carol should also not be able to read or update F.
You may not send any messages during revocation
You only need to implement functionality to revoke access from direct children. If Alice shares a file with Bob, and Bob shares the file with Carol, you are not required to allow Alice to revoke Carol’s access. It must work for Alice to revoke Bob’s access.
If Alice shares a file with Bob, and Bob shares the file with Carol, you don’t need to provide a way for Bob to revoke Carol’s access. We will not test this situation: you only need to ensure that the original creator of the file can revoke others.
If Alice shares a file with Bob, and then revokes Bob’s access, it may still be possible for Bob to mount a denial of service (DoS) attack on Alice’s file (by overwriting it with all 0s, or deleting ids), but Alice should never accept any changes Bob makes as valid. She should always either raise an IntegrityError, or return None (if Bob deleted her files).
Summary
Part2部分简直是噩梦，由于Share和Revoke的存在，Part1部分的代码几乎重写了。