Timeline for Asymmetric / end to end encryption for web messaging app
Current License: CC BY-SA 3.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 27, 2015 at 21:37 | comment | added | user3363866 | Formally, this should be possible if you use a sufficiently secure cipher (e.g CPA secure). Intuitively, uploading the secret key is not a good idea. If you prefer, you can find other possibilities, like for example deriving a key directly from a password (see key derivation functions). | |
| Mar 27, 2015 at 19:41 | comment | added | Alex | Last question. If I encrypt the private key with a key derived from a password, can I store it on a server for the user to be able to log in on other devices - securely that is? | |
| Mar 27, 2015 at 19:17 | vote | accept | Alex | ||
| Mar 27, 2015 at 19:17 | comment | added | Alex | Now I understand it. Thank you for the clear explanation. I obviously have some reading up to do before I continue on - which in turn is what I want - to educate myself on this topic! The answer is accepted for the main answer as well as the comments above. | |
| Mar 27, 2015 at 19:14 | comment | added | user3363866 | Scenario 2: msg server is malicious. Then A encrypts for B. The msg server sees the ciphertext but can not decrypt/read since it does not have the secret key. So using 2 independent servers means 2 instead of 1 need to be evil to break the secrecy =) | |
| Mar 27, 2015 at 19:12 | comment | added | user3363866 | Two different servers only help if they are independent. If they collude, you ' re lost again. But if only one is malicious, it does nit break secrecy. Scenario 1: key server is malicious. If A asks for the public key of B, the server responds with a wrong one, potentielly its own. A will encrypt the message with a wrong key which the key server could read, but uploads the msg to the message server which is assumed to be honestly and therefore the key server can not read the msg. On the other hand, B can not read the message, so this can be seen as a denial of service. | |
| Mar 27, 2015 at 19:06 | comment | added | Alex | How would using two different servers help? In the worst case mitm could still be used to switch keys, right? How would I use two servers practically to ensure secure usage? Thank you for taking your time to help me grasp the problems with this sort of security. | |
| Mar 27, 2015 at 17:58 | comment | added | user3363866 | Hm i think you already meantioned the solution yourself. Store the private key locally and encrypt it using password-based encryption. So euch user can only access the keys/accounts he has the password for. But the mitm is still a problem. Think of how A gets the key for B: it asks the server for the pub key of B. The server can still lie, provide its own key, decrypt it and encrypt and send it to B (remember that the server also has the original Pub key of B). I am pretty sure you can not solve this if the key server and the message server are the same. | |
| Mar 27, 2015 at 14:09 | comment | added | Alex | Now that you mention it that is obvious. So generate the key pair client-side and then sending the public key to the server is the obvious way to go. If the server only has the public key, it cannot decrypt messages meant for anyone else, only encrypt them - right? I want to do as much client-side as possible and trust the server as little as possible. Storing the private key using local storage is only feasible if it gets encrypted with a key derived from the password - correct? My final question is, how could multiple log-ins be handled? Since the private keys would be stored on one device. | |
| Mar 27, 2015 at 12:24 | review | First posts | |||
| Mar 27, 2015 at 12:25 | |||||
| Mar 27, 2015 at 12:20 | history | answered | user3363866 | CC BY-SA 3.0 |