Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
ZeroKit for Realm: Easy End-To-End Encryption (realm.io)
42 points by bjchrist on June 28, 2017 | hide | past | favorite | 10 comments


> If you’re building an app dealing with highly sensitive data, we definitely recommend you check out ZeroKit and give it a try!

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.


Good catches. ZeroKit seems too much marketing vs. too little security.


Hi, a ZeroKit developer here. We agree, third-party audits are crucial. We’re working on this, so stay tuned.


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.


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.


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


From my reading so far, it sounds like ZeroKit's stores the private keys? Am I mistaken? Because if so, this is definitely not end-to-end encryption because ZeroKit is a middleman that can be attacked to gain access to keys.

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).


Hi, one of the devs here working on ZeroKit. We encrypt everything on the client, so the it is end-to-end encrypted. We only store the private keys on our servers in an encrypted form. The server only provides ACL (so users don't get access to encrypted data they shouldn't, even if they wouldn't be able to decrypt it), checks the password using SRP-6a and provides OpenId Connect that realm uses to authenticate the users


Thanks for the more info.


If you don’t mind having seperate local and remote passwords (or never upload your private key to the server) it’s relatively easy to do so.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: