5000 iterations of PBKDF2 is very low. I'd use at least 100,000. Benchmark it, but that should be reasonable even on mobile provided you're caching the keys.
Thank you, I missed a 0: 50,000
I shall up it to 100K!
Are you shipping a real webapp where the server fully controls the JS anyway, or are you shipping, like, a WebExtension?
I think the TL;DR is "I'm not sure you can do this safely without having a security person on your team".
Assume it is a NodeJS Electron app that people run locally (and in the future, a browser extension).
(there is also a web version, which of course could always be compromised, but we're encouraging users to download the app so they have full control and don't have to worry about that. But they need to be compatible.)
Telling our users not to use crypto isn't an option. Recommending our users not use a browser is possible, but forcing them not to use a browser isn't an option either.
I don't think you can do this safely without having a security person on board. And there's a chance they'll try to ship a real crypto library in the Electron app.
I'll give it a shot though, some things that come to mind:
* RFC6979 ECDSA or bust
* Have you considered off-curve attacks for that ECDH?
* How do you authenticate your symmetric ctexts?
Advice/pointers? Here is our setup:
ECDSA sign/verify P-256;
ECDH enc/dec P-256;
PBKDF2 password + salt = extension, using SHA-256, 5000 iterations, 64 ks;
private key encrypted with PBKDF2 extension via AES-CBC
But it isn't like WebCrypto gives you access to much else. So given browser constraints, what are your thoughts?
Thanks!