
ZeroKit for Realm: Easy End-To-End Encryption - bjchrist
https://news.realm.io/news/end-to-end-encryption-for-realm-by-tresorit-zerokit/
======
Shank
> 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.

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

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

------
marknadal
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](https://github.com/amark/gun/wiki/auth)
(Note: All our code is MIT/ZLIB/Apache2 and open for auditing).

~~~
porcellus
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

~~~
marknadal
Thanks for the more info.

