> Zero knowledge cloud
> Data in our cloud is end to end encrypted so your credentials are never exposed to anyone but you.
1. You might want to avoid calling this zero-knowledge. While your docs suggest some use of E2EE, there seems to be a significant amount of metadata that remains both unencrypted and unauthenticated.
2. Having read your white paper, it appears your E2EE setup is vulnerable to various forms of forgery. In a simple case, an attacker that has compromised your infrastructure can easily substitute the credentials of arbitrary users in a way that is NOT tamper-evident.
3. There seems to be no post-compromise security. If your user private key is compromised (e.g. extracted from the extension's local storage), there seems to be no way to reset it.
4. The recovery flow is questionable. Do you really want to store critical cryptographic material in plaintext and in a third-party cloud?
When rolling out E2EE from scratch, it's very easy to give rise to issues like #2. At Backbone[1], we've created a framework for building end-to-end encrypted applications with building blocks designed to preserve confidentiality, integrity and nonrepudiatiability under a strict threat model.
Feel free to reach out, we're happy to share how we solved issues like the above.