I have an architecture where:

  • a user can have multiple devices (phones)
  • the server needs to broadcast the payload to all devices through the same channel (basically, all devices listen and receive the same payload)

Now, I need encryption for messages from server to devices.

  • the first phone will have to create a private/public key
  • server will use this public key to send encrypted messages. How do I solve the problem for the other devices? Is this mechanism (private/public) wrong and not appropriate in such case? User can't obviously ssh between devices to exchange data here...

The encryption protocol itself has not been chosen yet. If you believe one is more appropriate in this case, let me know!


closed as off-topic by Maarten Bodewes, yyyyyyy, DrLecter, K.G., e-sushi Jan 14 '15 at 21:50

  • This question does not appear to be about cryptography within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

  • $\begingroup$ Cross posted here $\endgroup$ – Maarten Bodewes Jan 11 '15 at 11:45
  • 4
    $\begingroup$ This question appears to be off-topic because it is about security without directly involving cryptographic algorithms. $\endgroup$ – Maarten Bodewes Jan 11 '15 at 11:46

Another alternative would be to share the same key pair between all the users devices e.g. using a QR code generator and scanner within the app.

The first device would generate a QR code representing the key pair and the other phone would read it through its camera. Additionally a password based encryption can be applied to the key pair to avoid easy leakage of the private key to others if they can access the phone temporary.


A simple solotion could be that all phones need to have the same pre-shared key. The pre-shared key could be downloaded once at first run, maybe from a password protected httpS site, or maybe from a url that delivers an encrypted and signed file with private/public key.

Then the pre-shared key is used on all phones, and it is used to encrypt by the sender, and decrypt by everyone else.

This simple solution provides only encryption, because this is what the only requirement of the original question.

This doesn't address all security issues, for example replay attack and impersonation. If you needed more than just encryption, then the solution will have to be a bit more complex.


If the number of phones will not be "large," the answer is simple: encrypt each message with a session key, then encrypt the session key to each phone's public key and stick the list of wrapped keys on the front of the message. Each phone finds its own wrapped key, unwraps it, and decrypts the message.

If you're looking for a good algorithm, might I suggest ECDH using Curve25519? Each message gets an ephemeral keypair, the shared secret using the message private key and each phone public key is calculated and used to wrap the session key. Keys are only 32 bytes, and each operation is really cheap compared to a traditional RSA-based implementation.

  • $\begingroup$ could you recommend me a fully implemented library of ECDH using 25519? I have only found the curve functions, but I am still missing the full implementation $\endgroup$ – user3684457 Jan 14 '15 at 22:47
  • $\begingroup$ cr.yp.to/ecdh.html is the reference implementation, and it's actually really easy to use by itself, which is what I'd normally recommend. What platform and language are you working with? $\endgroup$ – Reid Rankin Jan 15 '15 at 1:55
  • $\begingroup$ I need digital signature & encryption for python, iOS and android. I guess a shared C library would be perfect. $\endgroup$ – user3684457 Feb 1 '15 at 9:10
  • $\begingroup$ The reference implementation of Curve25519 is in C and is extremely portable. If you need more features, take a look at NaCl, which is also in C and provides easy ways to achieve most common cryptographic goals. $\endgroup$ – Reid Rankin Feb 1 '15 at 20:20

Not the answer you're looking for? Browse other questions tagged or ask your own question.