1

The design of the application is simple:

User Input > Serialize as JSON > Client-side Encrypt > Upload to server

The object being stored is structured like this:

type: <type1|type2|type3>
    type_specific_field1: "value1"
    type_specific_field2: "value2"
    type_specific_field3: "a_very_long_value_such_as_image_data"

All that the server sees is an encrypted blob. For privacy reasons, the server is not allowed to even see the type or the field names. The user is allowed to create as many objects as they want, and each object can be large (e.g. 10MB).

The problem then is that a user could store arbitrary data in the encrypted blob, and the server would have no way of verifying if the uploaded data is a valid object or not. They could (ab)use the server as a cloud storage alternative to Dropbox, S3, etc., instead of for its intended purpose.

Ideas for mitigation that I have so far:

  • Network rate limiting per user/IP address.
  • Rate limiting number of objects per user.
  • Requiring proof of work for each object.
  • Require CAPTCHA input every X object.

Ideas that might work in similar cases but not this one:

  • "Proof of space" will not work in this case because the client is not expected to keep a copy of the objects they upload.
  • Requiring payment for each object or unit of storage will also not work in this case because the application is free.

The mitigations I listed definitely help but do not eliminate the possibility of abuse, and each one has detrimental effects for legitimate users.

Is there a way for the client to prove, or the server to verify, that the encrypted blob contains a valid object? Or other cryptographic, network-level, or application-level mitigations you can think of?

Anders
  • 64,406
  • 24
  • 178
  • 215

1 Answers1

1

If you're allowing to store objects on your server and need to limit the amount of storage per user, you should introduce a per user quota and either deny new uploads or delete older ones. Other things won't work reliably if your encryption is good enough and the users want to misuse your resources.

Without knowing your concrete use case it is hard to give any other advise.

You may want to add to your question why you do not want to limit the number of objects. Obviously you do want to limit them, but are trying to avoid count the objects / storage space used by the objects but limit them by reducing the rate they can be created.

allo
  • 3,173
  • 11
  • 24