[IncRnd]

From reading this, one of the lynchpins seems to be a user password that encrypts a keychain containing stored key material used in the encryption.

This article doesn't say enough for me to attempt using this as a security product.

What are the key sizes? What is the kdf used to create them? How many iterations? What entropy requirements are enforced on the passwords? Where and how are the keys stored on the other side of the connection? How do the keys get there in the first place?

Also, what mode of AES is used? What bit strengths?

There is a lot that is unsaid in this, and what is said uses marketing not security terms. Together these lead me to believe there weren't security people involved in the actual design.

[porcellus]

We are working on fully detailed whitepaper, meanwhile you can read about some of this in our documentation. Here is some clarification: The user password is critical, because we need some kind of secret from the user, as we want them to be able to log in from multiple devices. The password requirements are entirely application dependent, we don't handle them: we provide feedback based on zxcvbn that the app can use to judge password strength. Regarding kdfs: the user password is first stretched using scrypt, then we use pbkdf2 to derive different keys for a few different uses. These keys are used to encrypt the user profile (which is just a collection of generated keys) before storing on the server. The keys derived from the user password won't travel to the server, they never leave the client, only data encrypted by it does. This data is mostly just other keys, we don't store any user data. We use AES GCM-256 Most keys are 32 bytes, for asymmetric key exchange we use the X25519 curve.

[porcellus]

Ah I forgot, I'm one of the developers working on zerokit