docs(admin): restructure and update server-side encryption documentation
This PR updates and improves the server-side encryption documentation.
- Adds context about "encryption" to help readers understand Server-Side Encryption (SSE) in relation to other encryption solutions (within Nextcloud and those provided by operating systems, etc.).
- Improves clarity throughout the documentation.
- Reorganizes and streamlines content for better readability.
- Adds additional reference links.
- Fixes outdated comments and notes.
- Expands and clarifies information on key management modes and encryption methods.
- Consolidates encryption troubleshooting entries from the General Troubleshooting chapter, bringing all related troubleshooting content together.
Note: In-depth implementation details remain in the dedicated "Details" chapter, which is not affected by this PR.. Same goes for occ encryption section in the occ command reference chapter.
☑️ Resolves
Follow-up items:
- [ ] Review/update #11545
- [ ] Review https://github.com/nextcloud/documentation/labels/feature%3A%20encryption%20%28server-side%29 tagged issues
🖼️ Screenshots
(works better if you open the screenshot image in a new tab then clicked on again to view it full-size)
It would be cool if you could mention that occ:fix-encrypted-version will (most likely) lead to data loss on the corrupted files since it will "just" roll-back to the most recent version that has a valid signature discarding more recent versions with signature errors.
fix-encrypted-versionwill (most likely) lead to data loss on the corrupted files since it will "just" roll-back to the most recent version that has a valid signature discarding more recent versions with signature errors.
@Toorero Can you clarify? The "version", in the context of SSE, is the encryption metadata version (not File Versions). The command just tries a bunch of different possible encryption versions. It doesn't touch file content or roll back to any prior file versions.
@joshtrichards thanks for working on it. One suggestion from my side. We should mention that user keys have some draw backs which can easily irritate users.
A example I use all the time: Think about a group share, the moment you share a file with a group Nextcloud will take the public keys of all group members and encrypt the file-key with it. With large groups this can have a (huge) performance impact. If a admin adds later additional users to the group they will see the file shared with the group but they will not be able to decrypt it because they where not part of the group when the file-key was encrypted. This can lead to a lot of confusion and 1st level support request like "i can't open a file shared with me", "nextcloud is broken", etc.