You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our current encryption scheme is pretty rudimentary. We have a single encryption key based on the user's password and some randomness. Everything encrypted is therefore only decryptable using the user's password. This means that any time the user changes their password, every encrypted item in the database must be re-encrypted.
Instead, we should have an inner key, generated once during initialization and never changed, which itself is encrypted by an outer key identical to our current key. Then, when the user changes their password, we must only re-encrypt the inner key instead of everything encrypted in the database.
The text was updated successfully, but these errors were encountered:
Agreed on this. Was just commenting in matrix that it would even be possible to rework #978 to migrate the current password-derived key to become the inner key, and a new outer key defined from the new app pass specified on pass change. But I'm inclined to say 978 can go ahead as is, by re-encrypting every item in the database instead.
Our current encryption scheme is pretty rudimentary. We have a single encryption key based on the user's password and some randomness. Everything encrypted is therefore only decryptable using the user's password. This means that any time the user changes their password, every encrypted item in the database must be re-encrypted.
Instead, we should have an inner key, generated once during initialization and never changed, which itself is encrypted by an outer key identical to our current key. Then, when the user changes their password, we must only re-encrypt the inner key instead of everything encrypted in the database.
The text was updated successfully, but these errors were encountered: