# Homomorphic encrypted streams (Paillier)

Situation: Alice (violin) and Bob (drums) play music together and want to (real-time) stream the concert to Carol. In order for Carol to save bandwidth, the stream is sent through a server which combines (integer addition) the two streams which it receives from Alice and Bob and sends the resulting single stream to Carol. In order to secure the stream from hacking attacks on the server, the data is encrypted.

For the encryption scheme, I am thinking of using homomorphic encryption (e.g. Paillier) in order to allow the addition operation without decryption.

1. Does the communication need to be synchronized? Do both streams need to start at the same time?
Symbols are encrypted independently and combined with random. $$\Rightarrow$$ No need for synchronization.
2. What is the effect on dropped frames (e.g. when using UDP)? What can I do in order to circumvent potential problems or do I need to switch to TCP?
Symbols are encrypted independently and combined with random. $$\Rightarrow$$ Dropped frames have no effect on other frames.
3. Is it possible that Alice and Bob use symbols of different length? The goal is to implement variable bit rates (the symbol size of each participant could be transmitted in plain text if necessary).
Example: Alice uses symbols of 8-bit while Bob uses symbols of 16-bit. Is it possible to decrypt the addition of the encrypted symbols?
Edit: Is my assumption right, that the ciphertext will have the same size as $$n$$ anyway?
4. Can this scheme be easily adapted to $$n$$ participants? What do I have to watch out for?

Edit: Since each symbol is encrypted independently, 1. and 2. don't seem to cause problems.

Edit 2: Number sizes

• How should number sizes be chosen in practice? Is n_length of 2048-bit good?
• Encoded data should be $$< n/3$$. And $$n$$ should be chosen randomly, right? So when I want to use 2016-bit for data, $$n$$ needs to be at least $$2^{2016} \cdot 3$$ thus reducing key complexity by this factor, right?
• I want to encode symbols of 16-bit data. Because of the summation, I need to add headroom by the number of senders of $$log_2(num_{senders})$$ bits. How should I deal with (8/16/32-bit) alignment for fast pack/unpack/calculations?
• This is what Netflix does Real time video stream AES encryption with authentication. Note that it is quite common that Coral can be a hacker to save the stream and share it. – kelalaka Apr 12 '20 at 12:11
• Thanks for the insights on Netflix practices. Although I don't see how this can be relevant to me. I want to have $x$ video sources and 1 viewer. The crucial part is the merging/mixing/combining of all encrypted video sources on the server without the server being able to decrypt the content and sending only one stream to the receiver (and not $x$ streams as this is necessary with other non-homomorphic encryption schemes). – darkdragon Apr 12 '20 at 14:21
• Use Netflix idea and also give a movie ID and part ID TLS record, So the server can combine them without knowing the actual video information. – kelalaka Apr 12 '20 at 14:49
• "mathematical addition" - what precisely is this operation? Bitwise xor? Additional modulo a large number? Different partially homomorphic methods perform different operations. – poncho Apr 12 '20 at 16:18
• @kelalaka: I still don't understand what you mean. How can one combine streams in AES which is not homomorphic? – darkdragon Apr 12 '20 at 22:50