Encryption implies oversized files

ℹ️ Support
1

Hello there,

I read the followingn about server file encryption:

Encrypting files increases their size by roughly 35%, so you must take this into account when you are provisioning storage and setting storage quotas. User’s quotas are based on the unencrypted file size, and not the encrypted file size.

https://docs.nextcloud.com/server/21/admin_manual/configuration_files/encryption_configuration.html

I don’t get why encryption would imply such an overhead.
Symmetric encryption actually requires no overhead, or at least not 35%.

Is it a failing app design?

2

Sorry i do not know much about the increase of storage while encryption. Yes there are functions e.g. aespipe with 0 bytes overhead at all. But i do not know the Nextcloud encryption.

Mostly the server-side nextcloud encryption is useless. It usually does not bring any safety advantage. It is only useful if you use storage at another secondary hoster e.g. S3. The Nextcloud server admin can always decrypt the encrypted data. However, if the data is then at Microsoft, Google or Amazon, for example, these three providers cannot decrypt it if the Nextcloud itself is not there.

Do you use an external storage for your data? If not do not use the server-side-encryption. It only causes trouble and apparently takes up space. :wink:

3

Thanks for confirming the overhead is weird.

I believe this encryption is not useless, it actually depends on the threat model.
I guess it’s a pretty good efficient against seizure. It’s similar to file disk encryption but in this case the admin would have to reveal the main secret, while with server encryption with per user key only the user could allow to decrypt the encrypted key using the user password.

4

I think not. Watch this video.

The advantage is that if someone takes a quick look at the file system, they can’t access the data. But it is quite easy to perform a restore with a backup and then decrypt this copy on a second system. Sorry i am not a hacker and i have not tested it.

Use a HDD encryption and if it comes to that, pull the plug and play dumb. Also you should deal with plausible deniability (at the end of the entry). But i think Nextcloud does not support it.

5

You mention server encryption mode without per user key. This is an option.

When using per-user keys, the key in the data directory is per user and encrypted with the user password.
https://nextcloud.com/blog/encryption-in-nextcloud/

Nextcloud can be configured to encrypt data at rest. This has two options: server-wide key (default since Nextcloud 13) or per-user key. With the former, the keys are on the server and thus the only protection offered is against external storage. With per-user keys, the keys are encrypted by the user password and handled as securely as possible, thus securing data when the user is not logged in.
https://nextcloud.com/security/threat-model/

This is not possible to recover without the user password. And the downside is that the data is lost if the user looses the password.

6

Can be possible. But a hacker can read passwords in plain text on login. Use E2E encryption for real security.

1 Like
7

You perfectly right, this is better security.

The purpose here is to find an agreement between best security level and easy access. E2EE is probably not as transparent as server-side encryption. For example it cannot be accessed without the secret stored on the device or directly through a web access.

I think server side encryption with per user keys may have to be considered as a good choice for my threat model, knowing that:

  • users may want easier access than E2EE
  • server may be seized
  • I shall reveal any secret upon request.

So cold storage attack would be vain.

1 Like
8

I can’t find the document any more where you can find more details. There was a security issue with the encryption and a whitepaper: Nextcloud Server Side Encryption | Flyer and Whitepaper but around this bug there were a few more details (not just he whitepaper), where you can perhaps find more details.

But the overhead comes from how they implemented the encryption, it doesn’t mean you can’t do more efficient symmetric encryptions.

9

This has actually been fixed with Nextcloud 25 which introduced a binary encoding for the encrypted files instead of using Base64 encoding as before.