1.2. Confidentiality

Your client must preserve the confidentiality of uploaded files. This specifically means that your client must enforce the following properties:

• File content must be hidden from the adversary, and must have \(\textsf{IND-CPA}\) security. That is, if the adversary picks two equal-length plaintexts, \(m_1\) and \(m_2\), sends them to a legitimate user, and the user picks one plaintext at random and uploads it as a file, the adversary should not be able to determine which plaintext the user chose. (This is not an exhaustive example.) Any breach of \(\textsf{IND-CPA}\) security constitutes loss of confidentiality.

  • However, leakage related to file content length or the number of files associated with a particular user is acceptable. That is, it is okay if the adversary can determine the length of a file, how many files a user has, or how many files are shared with them.

• Filenames must be hidden from the adversary. Based on the unencrypted info stored in the dataserver, an adversary should not be able to guess the length of any filename, or even narrow down the set of possible values for its length. However, \(\textsf{IND-CPA}\) security does not have to hold for filenames, meaning that it is okay if the adversary can determine if a user has access to a particular file, if the adversary happens to guess the correct name.

• The following implementation strategies must be avoided, as they are dangerous design patterns that often lead to subtle vulnerabilities. Our autograder tests for these and treats any instance of them as a breach of confidentiality and integrity:

  • Reusing the same key for multiple purposes (e.g. encryption, authentication, key-derivation, etc).

  • Authenticate-then-encrypt (i.e. MAC-then-encrypt).

  • Decrypt-then-verify (i.e. MAC-and-encrypt).