Add proof-of-concept for encryption #13
Conversation
|
From what I can gather your current proposal is a server-generated key that can be used for AES encryption. Is this correct? I was toying around with public key encryption that is registered through the GCM endpoint before. This will make sure only the receiving end can read the message when it goes through GCM. |
|
Not AES, Salsa20-Poly1305 (libsodium/pynacl), but yes, otherwise you are correct. I think public key encryption would be a bit overkill, plus you'd have to exchange one key for each device you have, which would be much harder for the user. |
|
This can be handled by the app. Simply when it registers to GCM (or FCM in the future) it will quickly generate a 1024 bit key and send that to the server with all the other registration parameters. The obvious downside of this is that you can't do password protected services. The upside is that only one key has to be kept track of and all messages will be encrypted for that device. |
|
Hmm, that makes sense, but my use case was mainly for authentication. The way you describe, everyone can subscribe to your service and start getting notifications (even an adversary), without needing to know any extra parameters. Maybe both could be done? Each device sends its own key (1024 is too low for RSA, btw) when it registers, and authentication could be implemented some other way. |
|
By the way, I would strongly recommend NaCl if you're doing anything with crypto, it takes care of everything for you and does everything right. |
This is a proof of concept for #6, it doesn't actually do any encryption, but it adds the necessary API calls and storage of symmetric keys so that all that would be required is to encrypt the message before sending. I'm primarily issuing this PR for feedback.