3 ms·
It's nice to see so many projects attempting to solve this problem. I have a question specific to the documentation on the main page: Private keys are stored
by mdip 13y ago
It's nice to see so many projects attempting to solve this problem. I have a question specific to the documentation on the main page:
Private keys are stored on the server in encrypted form. The key derivation function used is as follows:
K = scrypt(Passphrase, Username)
I'm going to skip the "JS crypto is bad".
What I'd like is clarification of the Zero Knowledge section that the keypair is decrypted client-side only and the passphrase is never transferred to the server for any reason. This is important because a state actor or other person with sufficient influence--such as a big wrench--could intercept this via code installation on whatever servers perform this work.
There's still the issue of JS being modified by the same evil actor (which you mention), and I'm not sure if signing with a browser extension is much insurance (that's just replacing code that can be modified in transit/on update with other code that can be modified in transit/on update), but with so much attention being paid to this problem as of late, an adequate solution will be discovered (if it doesn't exist already).
- jmccree 13y agoEven with the brute protection provided by scrypt, it's very worrying that you can assume the encrypted private key will A) Be available to authorities via (secret) court order B) Captured and stored by NSA types. The security of the key could only be assumed to be as high as the weakest passphrase ever used by the user. With what we know about most user's password security (especially the type not already capable of using GPG, which would seem the target market of this) this seems like a very bad idea. Why go through all the trouble of attempting strong client side crypto, only to store the private key secured only by a passphrase on the server?