End-To-End encryption

Hi,

we would like to add a end-to-end encryption to photon voice. From the doc:

"Photon does not offer end-to-end encryption between clients.Of course, you are in control."

https://doc.photonengine.com/en-us/pun/current/reference/encryption/

We do have a source in our system which can provide a key, which can be used for all clients, or at least for certain client pairs to crypt and de-crypt network packages.

Could you point us to the place in the pun voice source code where to best crypt/decrypt packages from our side, or provide a step-by-step guide how to change photon voice to add such a feature.

Maybe that would be interesting for other customers, too?


Thank you.

Regards

André

Comments

  • JohnTube
    JohnTube ✭✭✭✭✭

    Hi @AndreWe,

    Interesting.

    Could you tell us why do you need this?

    Do you specifically need End-To-End or just encryption?

  • Hi,

    we would like to have a real end-to-end encryption.

    We are developing a presentation software and we think that this feature is necessary to be a "good" presentation software which works over the internet. :)

    From our point we can generate a key from our cloud and can send it to the clients in a secure way. That could be a key for the AES encryption (or the like).

  • Kaiserludi
    Kaiserludi admin
    edited December 2021

    Hi @AndreWe.


    From our point we can generate a key from our cloud and can send it to the clients in a secure way. That could be a key for the AES encryption (or the like).

    When you generate a key on your cloud and send it to the clients, then your cloud knows which client uses which key.


    That means that your cloud theoretically could use those keys for a man in the middle attack and decrypt everything that is sent between the clients.


    For this reason your proposed implementation of end to end encryption is fundamentally flawed as it relies on you as the provider of the presentation software not using your key access in a malicious way and as it also relies on no one else who might use it in such a malicious way ever getting access to your servers.


    The whole point of end to end encryption is for the user to not have to trust the provider of the software, because a correctly implemented end to end encryption makes it impossible for the software provider to decrypt the data. This is not the case with your proposed approach. So with your proposed approach the whole point of end to end encryption is void and client to server encryption will just be as good.


    What you should do instead to implement proper end to end encrption is the following:

    • generate a private and a public key for asymmetric encryption on each client. It is absolutely fundamentally critical for proper end to end encryption that this happens on the client and not on your cloud
    • let the clients exchange their public keys with other clients with which they want to communicate with, but do not let the private keys ever leave the clients
    • when client A wants to communicate with client B for the first time, it encrypts its first message with the public key that it has received from client B and then sends the encrypted message to client B
    • client B is the only one who has the private key to decrypt that message. Not even client A can decrypt what it has just encrypted itself
    • this first message contains a key for symmetric encryption that is generated by client A (again it is absolutely fundamentally critical for proper end to end encryption that this happens on the client and not on your cloud) and only sent to client B (when client A starts a conversation with client C, it would then encrypt the first message in that conversation with the public key of client C and that message would contain a new symmetric encryption key that was created solely for communication with client C and that is different from the one that it has shared with client B)
    • from now on client A and B encrypt and decrypt all their communication with the exchanged symmetric key
    • the reason for exchanging symmetric keys over the asymmetrically encrypted first message is that asymmetric encryption is too expensive for using it for all data, while symmetric encryption is a lot cheaper (for the same encryption strength), but requires the shared key to be transferred encrypted, which is why you need to use asymmetric encryption first to transfer the symmetric encryption key.
  • AndreWe
    AndreWe ✭✭
    edited December 2021

    Hi @Kaiserludi

    thank you very much for your explanation.

    We will think of that workflow to add a real end-to-end encryption system.

    @JohnTube

    Would this be soemthing you could provide out of the box for photon (voice)? I guess that would be a very nice feature?

  • Tobias
    Tobias admin
    edited December 2021

    The downside of using a specific key for each connections between any two clients is that each message needs to be encrypted per receiver.

    A middle ground may be to use the same secret key for all users in a room.


    We won't add this feature to Voice in the near future.

  • AndreWe
    AndreWe ✭✭
    edited December 2021

    @Tobias

    "The downside of using a specific key for each connections between any two clients is that each message needs to be encrypted per receiver."

    That would be an performence issue I guess, or something else?

  • Performance and a client has to send the same update multiple times, instead of handing it over to the server to be sent to everyone in the room. Depending on the number of participants, this will increase traffic.

    Both may be non-problems but you should be aware of it.