Better way to handle recovery keys

At the moment we create a recovery key-pair and use the public key to encrypt all files if the user enabled the recovery feature. Basically the recovery key works like a additional user to whom all files are shared. This can have some performance impacts if a user enable/disable the recovery key with a lot of files.

Therefore the idea is to make a copy of the users private key, encrypted with the recovery password. In this case we only have to copy one file (the private key) to a backup location and encrypt it with the recovery password instead of updating every individual file key. Also disabling the recovery key is much easier because we just need to delete the copy of the private key. The performance of the recovery process would also improve significantly because on recovery we no longer have to decrypt/re-encrypt all file keys but just copy over the backup of the private key and re-encrypt the private key with the users new password.

Only thing which needs to keep in mind:

• If there are situations where we replace the users private key we also need to update the backup created for recovery.

This was a idea from @jknockaert. I just decided to summarize it here to make sure that it doesn't get lost. If I missed something, feel free to add it. If you have some time and want to implement it feel free to assign the issue to yourself.

Start by locating the existing recovery-key implementation and the code paths that replace a user's private key. Trace how enabling, disabling, and recovering currently update file keys, then determine all cases that must also update or remove the encrypted private-key backup. Done means recovery preserves access, avoids per-file updates, and remains correct after private-key replacement.