ZeroKit for Realm: Easy End-To-End Encryption

ZeroKit's website says they offer "hack proof encryption" and a $50k prize with a quote from The Next Web about "1,000 hackers" failing to break it.

If I'm handling highly sensitive data, I'd prefer any service I'm using to do that have multiple third party security audits on a source code level. Look at TrueCrypt's audit -- which gets into actual lines of code and details potential attack vectors -- as an example. Without any kind of auditing, it's a very tough claim to be hack proof.

Not to mention the fact that $50k might just not be enough to entice reporting. It's a good bounty for sure, but if you can compromise highly sensitive data sources, it stands to reason that the value on breaking that crypto is much, much higher than $50k.

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.

Edit: It says ZeroKit doesn't have access to the password, so asking for clarification here - is ZeroKit running entirely on the client then? Or do passwords ever get sent to the server (even if they are not stored or are session encrypted)? If that is true, why does one need to make a ZeroKit API call? Edit again: Quote from the article "which enables you to log in a ZeroKit user on the server", perhaps cool that they have this option, but that is a huge red flag to me that there is a server side attack vector.

Full disclosure: I work on a competing system that has uses real end-to-end encryption. It works like this:

- First, PBKDF2 extend a user's password into a proof of work.

- Use that proof of work to AES encrypt/decrypt an ECDSA private key.

- Now use that private key AES encrypt/decrypt private data, or a public key of a trusted user to encrypt/decrypt private messages.

Note: The user authenticates strictly against their device, the password is never sent to any servers. Same with the private key, it can only be derived from a local process PBKDF2 extending the password (to prevent brute force attacks) and decrypting the private key with the proof of work. The private key is never shared or known by any middleman servers.

To read more about how this works, see a working prototype demo, and watch our 1 minute animated explainers on cryptography, check out this link: https://github.com/amark/gun/wiki/auth (Note: All our code is MIT/ZLIB/Apache2 and open for auditing).