<p>This is possible, for instance using the following straight-forward approach (where $E(\cdot,\cdot)$ is some encryption function and $H(\cdot)$ is a cryptographic hash function):</p>

<ul>
<li>Input: A message $m$ and a set of keys $\{k_1,\dots,k_n\}$.</li>
<li>Generate a random <em>ephemeral key</em> $k_e$ that is used to encrypt $m$ <em>only</em>.</li>
<li>Output (for instance):
$$(H(k_e), n, (E(k_1,k_e),\dots,E(k_n,k_e)), E(k_e,m))\text.$$</li>
</ul>

<p>A message's recipient can subsequently decrypt all the encrypted keys $E(k_1,k_e)$ to $E(k_n,k_e)$
using <em>his</em> key $k$ and check whether the result's hash matches $H(k_e)$. If it does, he (highly likely) found the right $k_e$ and can proceed to decrypt $m$.</p>

<p>On the other hand, an adversary who does <em>not</em> have one of the keys $k_1,\dots,k_n$ learns nothing about $k_e$ from the hash $H(k_e)$ (as long as $H$ is not broken) nor any of the encryptions of $k_e$ (as long as $E$ is not broken), so he can't decrypt the message $m$ (as long as $E$ is not broken).</p>

<p>Drawbacks:</p>

<ul>
<li>This approach leaks the number of keys for which a message is encrypted, which may not be desirable.</li>
<li>The method doesn't scale well if you need to support a larger number of keys, but it should do for as few as two. A possibility to avoid having to decrypt <em>all</em> encryptions of $k_e$ until one matches is to add some key ID (for example, a hash of the corresponding recipient's key) to each encrypted key that a recipient can compare to a hash of his own key, at the expense of a slightly longer ciphertext and potential correlation of the recipients' identities.</li>
</ul>

CC BY-SA 3.0
2014-12-10T14:56:45.480Z
2014-12-10T14:56:45.480Z
yyyyyyy
<p>I'm a lowly web dev / programmer of 10 years who's never tried to wrap his brain around the high concept stuff, so apologies is this is a stupid question (or if it belongs in programmers.stackexchange.com)</p>

<p>I started wondering the other day, is it possible to encrypt something and have it decryptable by two different keys? </p>

<p>Suppose you wanted to have a user's data encrypted by a user-defined key, but you also wanted a safely stored "backup" key in case the user forgot their key. Is that even theoretically possible? </p>

CC BY-SA 3.0
2014-12-10T13:09:50.187Z
If the user's key and the backup key functionally equivalent, then why do you see an advantage in this application for there to be there two key? That is twice as many keys for an adversary to guess.
Tyson Williams
CC BY-SA 3.0
2014-12-10T15:39:48.063Z
I was just curious as to whether or not it was possible
roryok
CC BY-SA 3.0
2014-12-16T20:53:27.293Z
Ideas along these lines usually make people upset: see the Clipper chip controversy.  An easy implementation of this scheme is to separately encrypt the message first with the one key, then with the other, and send both ciphertexts together.  (This is not in itself a good scheme because it is subject to various kinds of attacks.)  Also, the folks over at crypto.SE might be more interested in this question.
András Salamon
<cr.crypto-security>
Is it possible to encrypt something in such a way that it can be decrypted by two different keys?
roryok
# Is it possible to encrypt something in such a way that it can be decrypted by two different keys?

(Asked by: username_0 on 2014-12-10)

I'm a lowly web dev / programmer of 10 years who's never tried to wrap his brain around the high concept stuff, so apologies is this is a stupid question (or if it belongs in programmers.stackexchange.com)

I started wondering the other day, is it possible to encrypt something and have it decryptable by two different keys?

Suppose you wanted to have a user's data encrypted by a user-defined key, but you also wanted a safely stored "backup" key in case the user forgot their key. Is that even theoretically possible?

**Tags:** cr.crypto-security

> **Comments:**
> **username_1**: If the user's key and the backup key functionally equivalent, then why do you see an advantage in this application for there to be there two key? That is twice as many keys for an adversary to guess.  
> **username_0**: I was just curious as to whether or not it was possible  
> **username_2**: Ideas along these lines usually make people upset: see the Clipper chip controversy.  An easy implementation of this scheme is to separately encrypt the message first with the one key, then with the other, and send both ciphertexts together.  (This is not in itself a good scheme because it is subject to various kinds of attacks.)  Also, the folks over at crypto.SE might be more interested in this question.  

---

## 1 answers

### Answer by username_3 on 2014-12-10. Score: 0 | Accepted answer

This is possible, for instance using the following straight-forward approach (where $E(\cdot,\cdot)$ is some encryption function and $H(\cdot)$ is a cryptographic hash function):

* Input: A message $m$ and a set of keys $\{k\_1,\dots,k\_n\}$.
* Generate a random *ephemeral key* $k\_e$ that is used to encrypt $m$ *only*.
* Output (for instance):
  $$(H(k\_e), n, (E(k\_1,k\_e),\dots,E(k\_n,k\_e)), E(k\_e,m))\text.$$

A message's recipient can subsequently decrypt all the encrypted keys $E(k\_1,k\_e)$ to $E(k\_n,k\_e)$
using *his* key $k$ and check whether the result's hash matches $H(k\_e)$. If it does, he (highly likely) found the right $k\_e$ and can proceed to decrypt $m$.

On the other hand, an adversary who does *not* have one of the keys $k\_1,\dots,k\_n$ learns nothing about $k\_e$ from the hash $H(k\_e)$ (as long as $H$ is not broken) nor any of the encryptions of $k\_e$ (as long as $E$ is not broken), so he can't decrypt the message $m$ (as long as $E$ is not broken).

Drawbacks:

* This approach leaks the number of keys for which a message is encrypted, which may not be desirable.
* The method doesn't scale well if you need to support a larger number of keys, but it should do for as few as two. A possibility to avoid having to decrypt *all* encryptions of $k\_e$ until one matches is to add some key ID (for example, a hash of the corresponding recipient's key) to each encrypted key that a recipient can compare to a hash of his own key, at the expense of a slightly longer ciphertext and potential correlation of the recipients' identities.


---

