I took a cursory look at the crypto on the backend, and it was mildly concerning. It appears to not be using modern asymmetric primitives. At first glance, it's not insecure or anything... just old[0].

Rather than using something like libsodium's public-key box API, which is wonderful, it's using a 2048-bit Diffie-Hellman Prime group. This isn't really great. You should definitely upgrade to more modern primitives. I can highly suggest libsodium as a drop-in replacement.

The other thing about this that's more concerning is that I have no idea if there is any validation going on to prevent small subgroup confinement attacks on this, but I don't really want to spend anymore free time checking this out and I'll leave it as an exercise for the reader/author.

Personally, I wouldn't use this product until a few cryptography design decisions were changed. If you're marketing this as a privacy-centric product, there's a lot of work to be done--not just on the Diffie-Hellman usage.

0. https://github.com/encrypted-dev/userbase/blob/master/src/us...

Old isn't a valid critique with crypto; 2048-bit DH is verifiably secure.

Old is entirely a valid critique of crypto; it demonstrates the authors aren't familiar with modern privacy tooling which tells me a lot.

We looked at libsodium and its choices impacted our discussions on our system. We decided not to use it because it's not compatible with many browsers [0]

We also discussed using a modern asymmetric key algorithm. We decided on Diffie-Hellman because we were extremely confident it's secure (so long as we choose the right parameters and implement it correctly), and would be very simple to fit it into our architecture.

[0] https://github.com/jedisct1/libsodium.js/#compatibility