> 1. The web crypto api was indeed made to secure communications, such as stated by the W3C on http://www.w3.org/TR/WebCryptoAPI/ (...) "Uses for this API range from user or service authentication, document or code signing, and the confidentiality and integrity of communications. "
So they say. You'd be hard-pressed to find a cryptographer that likes Web Crypto.
> 2. Yes, you are definetly right, an detailed audit of the protocol is necessary by more than one expert.
> So at sign up, the client software now generates a (RSA) public key pair and some symmetric keys used for (AES) encryption and integrity protection locally and encrypts it with a passphrase. The passphrase is only known by the user, but not by the server. The encrypted string is also integrity protected. It is sent to the server, stored there, and decrypted with the passphrase at login again. This way we ensure only the client software can see secrets, such as the private key, but not the server software.
Are you going to build it in, say, Electron? That's pretty neat.
What padding mode are you going to use for RSA? What hash function for MGF1?
Are you going to also employ digital signatures? Will you use the same RSA keypair for signatures?
What about your other parameters? (There are attacks for e=3 RSA signatures, for example.)
What cipher mode are you going to use for AES? What key size? Are you going to MAC then Encrypt, Encrypt and MAC, or Encrypt then MAC? I'm assuming the third option.
How are keys going to be authenticated to the clients? How will they detect/prevent the server from substituting a user's RSA (eww) key for one of their own choosing?
How are you going to derive your encryption keys from the password?
Why not save a lot of time and frustration and just use node-sodium (assuming Electron of course)?
So they say. You'd be hard-pressed to find a cryptographer that likes Web Crypto.
> 2. Yes, you are definetly right, an detailed audit of the protocol is necessary by more than one expert.
Shameless plug: https://paragonie.com/service/code-review
> So at sign up, the client software now generates a (RSA) public key pair and some symmetric keys used for (AES) encryption and integrity protection locally and encrypts it with a passphrase. The passphrase is only known by the user, but not by the server. The encrypted string is also integrity protected. It is sent to the server, stored there, and decrypted with the passphrase at login again. This way we ensure only the client software can see secrets, such as the private key, but not the server software.
Are you going to build it in, say, Electron? That's pretty neat.
What padding mode are you going to use for RSA? What hash function for MGF1?
Are you going to also employ digital signatures? Will you use the same RSA keypair for signatures?
What about your other parameters? (There are attacks for e=3 RSA signatures, for example.)
What cipher mode are you going to use for AES? What key size? Are you going to MAC then Encrypt, Encrypt and MAC, or Encrypt then MAC? I'm assuming the third option.
How are keys going to be authenticated to the clients? How will they detect/prevent the server from substituting a user's RSA (eww) key for one of their own choosing?
How are you going to derive your encryption keys from the password?
Why not save a lot of time and frustration and just use node-sodium (assuming Electron of course)?
Life is easier with sodium. https://paragonie.com/blog/2015/09/how-to-safely-implement-c...