3 ms·
Question, I build webapps, meaning I only have access to the native WebCrypto API that doesn't have some of these other things mentioned. Advice/pointers? Here
by marknadal 9y ago
Question, I build webapps, meaning I only have access to the native WebCrypto API that doesn't have some of these other things mentioned.
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!
- lvh 9y agoAre 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".
- marknadal 9y agoAssume 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.
- lvh 9y agoI 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?
- ryan-c 9y ago5000 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.
- marknadal 9y agoThank you, I missed a 0: 50,000 I shall up it to 100K!