One of my major complaints about existing software systems that claim to be "E2EE" is that they often don't provide a clear description to how their key management actually works.
This is a mistake. This information must be readily available to the users of these systems, as understanding what and where their keys are is critical for preserving both the security and availability of their private data.
One possibility is that your password could be your key to end-to-end encryption, if your service provider does it right.
Most authentication systems don't do it right, making this proposition untenable for many/most existing password database deployments.
I made a password hash function that automatically preserves the possibility of using passwords as keys so long as it is deployed as a client-side prehash function:
https://hackage.haskell.org/package/g3p-hash-2.0.0.0
Most authentication systems see plaintext versions of the password as part of the authentication process. If a plaintext password has ever been disclosed to your authentication server, using that password as a cryptographic key is not ideal.
The better thing to do is to encourage users to change to a random passphrase as part of the migration, and ensure that your authentication servers never see those newly generated passphrases.
