I think there needs to be some sort of reset process. Just because having a user who has to abandon their account over a forgotten encrypted pm seems, excessive.
I honestly favor a semi-destructive key reset method because it is simple to change keys used in future and not have to edit (much if any) previous data. In most encryption systems, a valid member key should still be able to access old data and the new key will only be valid for new communication.
I do support some sort of two party confirmation system for it. It’s a “destructive” action so should be at least moderately guarded. In my mind the flow could go something like:
User Requests Key Reset via Site
Staff(?) Confirmation of Key Reset Request via Site
Email Keyed Final Warning/Confirmation
@justin Yeah if you forget your password a lot, you’re gonna have a lot of unreadable encrypted messages. I think that’d be inherent in the system.
@Stephen Yeah the topic keys change it a bit, and I’m not that familiar with topic keys vs multi key systems. I think a system that doesn’t allow recovery of lost key data is inherently more secure even if less convenient.
My main example of this practice is a service like ProtonMail. With a recovery email and the confirmation from a staff member via your request, you can reset the main encryption key passphrase for your account. It will invalidate all the contents of every sent or received message, even if the mailboxes are encrypted seperately from the account, because the keys are nested like they are here, with private keys “inside” the public keys and sometimes multiple layers of this. The only data you keep is the to: from: and title of the email. There are many ways to approach this but I have a lot of thoughts on it and thought I would share.