Is there a key management approach for the following scenario:

  • Customer Alice uses an application S1 to generate a file. The contents are expected to be encrypted such that it can only be decrypted by someone who owns another application S2.

  • Alice distributes the file publicly.

  • Customer Bob owns application S2 and is able to decrypt the file.

In this case, Alice does not know Bob, and is not exchanging any keys with him directly. The key exchange is offline and between the applications S1 and S2!

How will application S2 store its decryption key? Obfuscating it in the binary is a bad idea. Let's say that using a key server is a non-starter in my scenario. Are there any other solutions?

Does any well-known product run into this scenario? How did they solve it?

  • what about a password protected zip file?
    – schroeder
    Jul 6, 2017 at 14:48
  • @schroeder Thanks for the reply. I would imagine that the contents are encrypted using a key derived from the password provided by the customer. I am looking for a product which does not depend on user input to encrypt i.e. the encryption key is the product's own and does not belong to the customer.
    – SkypeMeSM
    Jul 6, 2017 at 15:00
  • I have edited the question now to hopefully make it on-topic.
    – SkypeMeSM
    Jul 9, 2017 at 2:51
  • What type of applications are applications S1 or S2? Are they desktop applications? Or some sort of server-side application? Jul 10, 2017 at 18:24
  • @user52472 S1 and S2 are desktop applications, and they are fixed. I could have named it better as Encryptor and Decryptor.
    – SkypeMeSM
    Jul 11, 2017 at 13:40

1 Answer 1


True encryption means that a secret will be required to get original data back. Common secrets storage are:

  • the recipient's brain (something you know)
  • a smartcard of other HSM (something you have)

As soon as you go away from this secure encryption use case, you fall into obfuscation with 2 common ways:

  • a custom algorythm - hard to securely setup and test, and hard to protect against reverse engeneering, please keep away from that
  • a key hidden inside an application executable - hard to change if it were compromised, and hard to protect against reverse engeneering, not really better

If all you need is that Alice and Bob are not required to exchange any keys, you could use a central hub:

  • application S2 is distributed in such a way that every customers receives a personnal asymetric pair of keys and the central app only stores the public part, ideally the pair should be generated client side, for example during an app initialization
  • when Alice sends a message through S1, the message in encrypted with a random symetric key, and that key is securely transmitted to the central hub. A UUID of the message is transmitted to the recipient and to the central hub
  • when Bob receives the message and the UUID, S2 application opens a secure channel (TLS) to the central Hub. Bob is authenticated with his private key as a legitimate S2 owner, so the hub accepts the request for the symetric key for the message identified by its UUID
  • S2 can decrypt the message and Bob can read it


  • what is controlled is only the ownership of a valid key, if Bob turns evil and decides to sell copies of his keys, you cannot prevent it. Same if he does not turn evil but gets hacked
  • if Bob finds that you S2 app is not what he wants and uses a third party app that mimics the interface you have no technical way to prevent it - but legal ways may exist...
  • even if the central hub does not receive the messages, you have full control over S1 and S2, so you could easily get all exchanged messages - you must know it when you present your solution to customers
  • This is similar to what a Rights Management System like Azure does - the central hub being the RMS server. I think my use-case does align more with Rights Management than anything else. Thanks for your answer.
    – SkypeMeSM
    Jul 11, 2017 at 13:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .