1.1. Threat Model
The adversary has the following capabilities:
Dataserver is untrusted. The adversary has full control over the Dataserver—the adversary can view, record, modify, and/or add any key-value pair stored in the Dataserver.
Read access on Keyserver. Since the Keyserver is public, the adversary can read any data stored on the Keyserver Keyserver. The adversary cannot overwrite or tamper with any records stored on the Keyserver. You may also assume that the adversary will never write any data to the Keyserver maliciously (ie, it will not use the Keyserver other than to perform normal actions as directed by your client to create users, log in, etc.).
The adversary can observe network traffic between the client and the Keyserver/Dataserver. By monitoring the network, the adversary can also observe which users store each key-value pair in each of the servers and the order in which key-value pairs are stored, viewed, or deleted. (The adversary cannot tamper with or inject network traffic.)
The adversary controls at least one (or more) malicious users. These users may use your client implementation, or they may use an adversary-defined client implementation instead. The adversary can convince legitimate users to share files with the malicious users, as well as convince legitimate users to accept files shared by the malicious user. If a file is shared with a malicious user, the adversary can record all relevant information about the file (such as the file itself, cryptographic material associated with that file, any sharing metadata, etc.) and remember it, even if access to the file is later revoked.
While the adversary does not have unlimited resources, the adversary can use some reasonable amount of automation and brute-forcing. For example, the adversary may possess and utilize a precomputed rainbow table of common passwords, perhaps one downloaded from the internet, or lists of common usernames. (Note that it’s okay if the adversary can guess filenames or the locations of other objects on the dataserver, so long as they cannot read/tamper their contents.)
The adversary is can adapt to operations it observes, which means that it can learn from the data you read/write to the Keyserver and Dataserver, its own execution of operations, etc.) and tailor its future choices of operations to take advantage of that information.
The adversary has your source code. Imagine that your code is open-source and anyone (including your adversary) can view it at any time. Therefore, the adversary knows your design and the implementation of your client, and can tailor its attacks accordingly to take advantage of flaws in the design. You should assume that if the adversary has the capability to do something malicious, it will do that thing. Similarly, this means you cannot rely on security through obscurity by expecting the attacker will not know how you have stored data.
Anything not mentioned here is outside the scope of the adversary’s capabilities. For example:
The adversary does not have direct access to the client machine, and thus cannot modify the code running on a legitimate client.
The adversary will not perform large-scale Denial of Service (DDoS) attacks against clients or the servers. In other words, you do not need to defend against attacks on availability.
The adversary will not conduct a rollback attack (i.e. it will not attempt to trick a client into accepting an older version of a file)—however, the adversary must not be able to trick the client into accepting a file that mixes old and new data.