0
$\begingroup$

I would like to create a software that will be installed on multiple clients. I would like to broadcast an encrypted message to all of those clients. Each client should be able to decrypt the message and react to it. However, noone should be able to create such a message that could be decrypted by those clients.

So, I would like to be the only entity that is able to create the encrypted message. At the same time I would like everyone to be able to decrypt the message I have created. I would also like the message to be sent in encrypted form, so digital signature alone won't suffice.

Is it possible with assymetric cryptography, i.e. RSA or ECC?

I know some people encrypt with private keys and decrypt with public keys, but lots of sources specify this approach as insecure/invalid. So, I would like to know what's the proper, secure and valid approach?

Update: edited to provide more context information, because maybe my generalization was confusing. It's not about the network, but rather I'm trying to think of some software registration key scheme. I would have multiple clients. When someone buys a key, I would send this person an encrypted registration info. His copy of the software would read this encrypted key info, decrypt it, and store on the disk in decrypted form. I would like to prevent converting this decrypted form into encrypted form again to prevent registration key from being stolen by some malicious software. The key would be useless in decrypted form because the software wouldn't accept decrypted key; it would accept only encrypted keys.

Improve this question
$\endgroup$
6
  • 3
    $\begingroup$ What's the point in encryption if anyone should be able to "decrypt"? That just makes it an encoding with no impact on security. $\endgroup$
    – yyyyyyy
    Apr 22, 2018 at 13:26
  • 1
    $\begingroup$ This sounds like DRM. Cryptography cannot help you here ("trusted" CPUs don't count). Maybe copyright law. BTW: You can symmetrically encrypt and asymmetrically sign the ciphertext. I.e. By deriving the symmetric key from the asymmetric public key. The keys must be bound in some way to prevent stripping the signature and resigning under another identity. Depending on the signature scheme, you may need to derive a sub-key for signing. Take a look at tahoe lafs' semiprivate keys $\endgroup$
    – cypherfox
    Apr 22, 2018 at 14:49
  • 1
    $\begingroup$ What about using a symmetric key K shared by all the parties. The sender creates then encrypts the message M and then signs the ciphertext with his private key. All the receivers can both verify that the message was created by an authorized sender with its public key and decrypt the ciphertext. $\endgroup$
    – Alexandre Yamajako
    Apr 22, 2018 at 16:57
  • 1
    $\begingroup$ Your updated description sounds exactly like you want a signed serial number / accountID. Especially if you want to store it decrypted, what is confidentiality buying you here? $\endgroup$
    – bartonjs
    Apr 23, 2018 at 14:58
  • 1
    $\begingroup$ Just add a signature. $\endgroup$
    – eckes
    Apr 23, 2018 at 20:24

3 Answers 3

Reset to default
2
$\begingroup$

This is a scenario where your description would be much improved if you explicitly considered the following questions, which you should always ask in cryptography:

  • Who are the "honest" parties? (See at the bottom for an explanation of the scare quotes.)
  • Who are the adversaries?

In particular, you've not taken enough care to describe who the adversaries are. The first obvious thing we can imagine is that there are third parties—neither your software nor its clients, both of whom would count as "honest parties"—that would eavesdrop on the broadcast and would like to know its plaintext. If that's the model, then a simple solution would be:

  • All the messages are encrypted with a symmetric algorithm whose key is shared by the broadcaster and all the clients;
  • The broadcaster signs every broadcast with its own asymmetric keypair, and all clients verify the signature on every broadcast.

But there's a problem with this way of looking at it: should the clients really be modeled as "honest" parties, or are they actually a type of adversary? Encryption only protects message confidentiality if the recipient is an honest party, who keeps the keys and plaintexts secret.

The problem with your scenario then is that you're disclosing information to another party and expecting them not to disclose it to anybody else. That works if and only if the other party is "honest," and it could easily fail if the other party is an adversary.

Note that in cryptography, "honest party" is not a moral term. It's a party to some protocol who can be counted on to execute it faithfully. While an adversary is a party that cannot be counted on to follow the rules.

Improve this answer
$\endgroup$
2
  • $\begingroup$ I agree that I should have used a better description. I don't want to edit current one anymore because that would look like a forum discussion instead of a StackExchange item. $\endgroup$
    – antonone
    Apr 24, 2018 at 4:33
  • $\begingroup$ No need to change the question. If you already knew this stuff you wouldn't have needed to ask, would you? $\endgroup$
    – Luis Casillas
    Apr 24, 2018 at 18:09
1
$\begingroup$

You say that you send your users a "key" in encrypted form. Then the program decrypts it and stores it on disk.

What would happen if I were to say intercept this key before it got to the program and make a copy of it while it was still in it's encrypted form?

From my understanding, with this, I could effectively "activate" two copies of the program.

However, if you say that you're going to keep track of these licenses by somehow crosschecking with your own database. You wouldn't need encryption in the first place!

Improve this answer
$\endgroup$
-1
$\begingroup$

Unless you are dealing with a bunch of clients on a single small network, you are probably not doing a true broadcast, but rather just sending the same message to each client. So I would just think in terms of sending a bunch of individual messages, each of which just happens to contain the same content.

As far as the encryption, I would recommend a normal SSL connection, perhaps with a "Wake up" message so each client knows to fetch the message.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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