search

nextcloud / end_to_end_encryption_rfc

🔒 Specification for end-to-end encryption used by Nextcloud sync & mobile apps
Other
31 stars 15 forks source link

Large Files #29

Open MaxFichtelmann opened 5 years ago

MaxFichtelmann commented 5 years ago

As far as I can see, the current proposal has some trouble with large files.

As a GCM decryption should not release plaintext before the tag has been verified, the client needs to buffer the complete content that is protected by the tag. Having a single authentication tag for a file then means having to buffer the complete plaintext.

There are some theoretical solutions and some practical limitations. While openssl emits plaintexts before verifying the tag, putting the responsibility to handle authentication failures to the user/developer, java does not and will buffer the whole plaintext until doFinal is called.

One way to mitigate this issue is to split the file into chunks that each have a separate IV. The order and total number of chunks should be protected by using the information in the AAD, to prevent reordering and trimming attacks.

This conflicts with the current rfc, that puts IV and tag into the metadata file with a 1-1 relation to the file.

purdieb commented 2 years ago

Additionally, it is recommended that AES-GCM not be used for messages that are 64GB or larger. (NIST source)

Unless file splitting is implemented the client should probably refuse to sync files equal to or above that limit (or at least warn of the security implications).