I am wondering how could a zero-knowledge host such as mega.co.nz prevent users to just upload files in clear, and, for example, to discredit the site by uploading a large quantity of illegal material and then telling the authorities.

Ideally, the server should refuse unencrypted uploads. However, what's a definition of "unencrypted" that a computer may understand? I guess there's none. It could be that by pure chance, a JPG picture of a giraffe is actually the cyphertext of some other encrypted document. This is just very unlikely. And a computer can not really tell a picture of a giraffe from a file that has jpg headers and random noise. One could reject files based on headers (e.g., using the unix "file" utility) but that seems a bit unreliable, and would sometimes reject legitimate uploads.


3 Answers 3


A host such as mega.co.nz is simply performing the encryption (locally) in the upload step, and then in the view/download one. You could create a custom client that sent unencrypted data as if it was already encrypted, and then you would need another custom client to download it, too. Hardly resulting in a discrediting evidence.

In fact, a normal mega.co.nz url is designed to directly allow you to view the content, which would do that more easily. Similarly, you could always encrypt the illegal content encrypted and then report it yourself to Law Enforcement along the password (NB: that such planting of illegal data would likely give you trouble).

That would be very unlikely to "discredit the site". Actually, the point is that the hoster is not aware of the contents. Encryption is just a (pretty good) way to prove that they had no knowledge of the file contents. Most hosters are not aware of the file their users upload, either, and it is generally explicitly stated so in law (your local jurisdiction may differ), such as the DMCA.

However, it is once they are aware (hey, you have $ILLEGALCONTENT on http://....), they can no longer claim ignorance. This is independent on them being encrypted or not.

The indictment on Megaupload (mega predecessor) claimed that they were aware of infringing material, and even «searched the internal database for their associates and themselves so that they may directly access copyright-infringing content». Locally encrypting the contents of its successor before upload served to protect them against another similar claim.

  • So it's a legal matter, not a technical one.
    – vincenzoml
    Nov 9, 2019 at 3:30
  • As an end user of their service, I will likely care that they can't read my file (technically). However, discrediting the hoster would be a social problem. And getting the company in trouble with the authorities a legal one, and the one that was probably the main driving reason when designing the service in this way.
    – Ángel
    Nov 9, 2019 at 19:45

It can't.

There are heuristics to tell whether a file is encrypted, but they're unreliable, and they're useless anyway.

An encrypted file is uncompressible because the encryption hides all the patterns. Except when it's not: if you encode an encrypted file in hexadecimal (with two bytes to encode each original byte), it takes twice as much room, so you can compress the hexadecimal version by 50%, but the hexadecimal version isn't less encrypted. Conversely, if a file is uncompressible, if may be encrypted, or it may simply be already compressed with an algorithm that's at least as good as what you have. So in fact an encrypted file may or may not be uncompressible, and a plaintext file may or may not be uncompressible,

An encrypted file contains no recognizable patterns. Except that of course it can contain, for example, a header indicating the type of encryption. Or it can recognizably contain only hexadecimal digits. So in fact an encrypted file may or may not contain recognizable patterns, and a plaintext file may or may not contain recognizable patterns.

An encrypted file may very well be a JPG picture of a giraffe, with information encoded in (say) the low-order bits of each pixel. See steganography.

Even if a file is encrypted, you can't tell, say, an AES-CBC-encrypted file from an AES-CBC-encrypted file with the key prepended. Except by trying to use the first 16 bytes as the key — and then you'd need to try out all the other ways the key may have been put in there.

Let's say that the file really is encrypted and cannot be deciphered with only the uploaded material. The creator of the encrypted file could still publish the key elsewhere.


Idea: Force structure: integrity checkable files or hybrid encryption.

It is hard to distinguish between unencrypted and encrypted files encrypted with symmetric mechanisms, if there is no forced structure within the files uploaded to the service.

An idea I have, they could use is: force some structure on uploaded files.

For instance, have integrity checking for ciphertext. This way, the file hosting service is able to ensure they host files which are not broken, in addition to added integrity checking based on cryptographic mechanism allows the hosting service to ensure that at least some cryptographic processing has been applied to the uploaded file.

If the service insists on being able to recognize if encryption has been applied, maybe they wish to require hybrid encryption. On many hybrid cryptographic schemes, the asymmetric encryption part is distinguishable from random.

What remains problem: the actual symmetric encrypted part remains unverifiable, if the key is not known. This is kind of obvious: if the file host could decrypt the file, they have access to the keys which was intended to be avoided.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .