# Two different keys decrypting same content

is there some generally available algorithm which will encrypt a short string and generate two unique keys so that any of the two can be used to decrypt the message again? It doesn't has to be "super secure".

• Usually this is enabled by encrypting a random data key with two user specific keys, and then encrypting the message with the data key. You then add the encrypted (wrapped) keys to the ciphertext – Maarten Bodewes Dec 28 '15 at 12:56
• ... include the keys with the ciphertext, not add in the mathematical sense of course. – Maarten Bodewes Dec 28 '15 at 14:10

Most public key encryption schemes, such as PGP, support this.

When you are encrypting a message to Bob, in fact you are encrypting the message with a random key using a symmetric cipher, then including the key encrypted to the public key of Bob.

$$E_{\text{PK}}(\mathit{Bob}, \mathit{key}) \Vert E_{\text{Symmetric}}(\mathit{key}, \mathit{message})$$

where $\Vert$ denotes concatenation.

If you encrypt the message to Alice and Bob, you are encrypting the same random key to each of their public keys:

$$E_{\text{PK}}(\mathit{Alice}, \mathit{key}) \Vert E_{\text{PK}}(\mathit{Bob}, \mathit{key}) \Vert E_{\text{Symmetric}}(\mathit{key}, \mathit{message})$$

Each of them can decrypt the message.

• Small note: usually direct binary concatenation is not used. PGP for instance specifies a container format which can list the public keys that were used to (indirectly) encrypt the message. – Maarten Bodewes Dec 28 '15 at 15:15
• However this is not scalable to N participant since the message will have to grow as well rendering it untransferable anymore (I know the OP asked for only 2, but that's good to remember) – xryl669 Oct 16 at 6:09
• @xryl669 it does scale. Linearly to the number of participants, independent of the message size. Sending a 1GB file to a couple of people may take 1 GB plus 1KB, and encrypting for 100 users instead 1GB 50KB. The OP wanted to encrypt a "short string", so in such case the benefits may be dwarfed by the overhead of Public Key encryption, but as you see, it excels with large files. – Ángel Oct 16 at 23:50

You can do this for any encryption. Simply encrypt the secret message with a random key. Then encrypt two copies of the random key, one with Alice's key, and one with Bob's.

Keep it simple :)

A totally different approach is given in the following paper A Simple Public-Key Cryptosystem with a Double Trapdoor Decryption Mechanism and its Applications (pdf) where a double trapdoor is used to give two different and indipendent private key. The first secret key is given by the knowledge of the (secret) factorisation of an RSA-like integer $N$; the second secret key is given by the knowledge of the (secret) discrete logarithm of a public element.

The typical process is to encrypt the message using a separate data key, as suggested in Maarten Bodewes comments. It is then trivial to encrypt this key twice, once using each of the keys you plan on handing out, and concatenating those two encrypted keys to the message. There are potentially more optimal approaches, such as the one dddavidee suggests, but this approach has one big advantage: its simple. It is trivial to analyze the security of this process because it works for any arbitrary encryption methodology. Use whatever encryption you are comfortable with! The message is secure as long as neither encrypted copy of the key is cracked (and as long as you properly disposed of the key when you were done encrypting, of course!), and it is secure to the level of security afforded by the encryption you used on the data in the first place.

The more specialized algorithms prove to be more useful in shared secret situations, such as "Any 3 of 7 keys, brought together, needs to be sufficient to decode the message, but no 2 keys can do so." More exotic situations like that call for algorithms like those from Rivest's "How to Share a Secret."

I'd like to add Shamir's secret scheme here too.

Basically, you'd encode your message using this scheme. Then you can create as many different key as you want to decode it.

This is usually used with two or more part for decoding, but nothing prevents you from using only one part here.

Compared to Ángel solution, the message does not grow depending on the number of participants/recipients, which is a very nice property to have.