# Encrypting a key with the same key, for instance using AES

I am new to crypto and trying to understand if it would be insecure to use a cipher such as AES to encrypt a key with the same key. If it is insecure, then why would it be insecure?

Basically, something like this:

encrypt(key, key)


What happens when both key and message are the same (128 bits)?

The obvious question would be why would I want to do that. If I have a secure channel to send the key, why encrypt it? My question is more for understanding.

• This question makes no sense. You're asking us why something would be insecure without telling us why you want to do it. Something can't be insecure unless there's something you're trying to prevent that would constitute a security failure. Without requirements whose violation would constitute a security problem, it's logically impossible for something to be "insecure". – David Schwartz Feb 15 '13 at 10:04
• @madhukar2k2 "I tried searching for an answer for the above, but couldnt not find one." - try looking at circular security, it might give you some answers. Additionally, I've added some things in my answer below. – hakoja Feb 15 '13 at 10:48
• Is fgrieu's premise along the lines of the security situation that you had in mind? As it is, the question does not specify the context of the security you are interested in (as @David pointed out). Could you add some detail or incorporate fgrieu's premise into the question? – B-Con Feb 15 '13 at 20:31
• Note that all the problems mentioned are only relevant if it is known from other sources that there is the key encrypted, not if the key is included in the plaintext by chance. – Paŭlo Ebermann Feb 17 '13 at 11:24
• This question was merged. Now there are some close votes against it, but closing it would directly harm the merge. Please indicate below if you have specific problems with the question that need to be cleared up. Note that I didn't notice that the comment section was copied as well; I've removed the comments that did not make much sense here. – Maarten Bodewes Dec 8 '19 at 17:22

I'm taking the question as: given some cryptosystem using AES-128 with some random secret key $K$, what are benefits and drawbacks of computing and making public $\hat K=\operatorname{AES}_K(K)$?

Benefit - $\hat K$ can be used as a KCV: A legitimate holder of $K$ could do the same calculation with the $K'$ he holds, and compare $\operatorname{AES}_{K'}(K')$ to the public $\hat K$. If there's no match, then one of $K'$, $K$, or the copy $\hat K$ used in the test is altered. If there's a match, it is almost as certain that $K'=K$ that it is certain that $\hat K$ is genuine. In this usage, $\hat K$ would be a Key Check Value (and far from the worst KCV ever used). And if the purpose of such a KCV and test is to guard against alteration of $K$, or of the AES encryption engine, and $\hat K$ is not made public but rather stored secretly along $K$, that seems a byzantine but effective idea (caveat emptor: side channel leakage considerations may apply).

Drawback 1 - $\hat K$ enables an attack on a reduced-round version of AES: A passive attacker knowing $\hat K$ has the same test as above to determine (with high confidence) if a guess of $K$ is right. That test is slightly more useful than just a random plaintext/ciphertext pair would be, because, in AES-128, the first computational step is to XOR the input and key; that gives zero in case of computation of $\hat K$; and thus the result of the first AES round is a constant (0x6363636363636363). Revealing $\hat K$ is like revealing a plaintext/ciphertext pair for a variant of AES-128 with 9 rounds instead of 10. This saves close to 10% of the work in an attack by brute force; and might conceivably open to a cryptanalytic attack that has a benefit at 9 rounds, but not the full 10; I do not see either as truly worrying in practice, though.

Drawback 2 - in some protocol, $K$ can leak: An active attacker might trick a legitimate party holding $K$ into revealing $K$, if that legitimate party uses $K$ to compute the function $\operatorname{AES}^{-1}_K()$. For example, assume a (dumbed down) authentication protocol where Alice draws a random $R$; computes $C=\operatorname{AES}_K(R)$; sends that to Bob, who computes $R'=\operatorname{AES}^{-1}_K(C)$ and sends that back to Alice (which compares $R$ to $R'$). An active adversary knowing $\hat K$ can obtain $K$ from Bob by submitting $\hat K$ instead of $C$, and will get $K$ as $R'$ (because $\operatorname{AES}^{-1}_K(\hat K)=K$). More generally, availability of $\hat K$ could entirely ruin the security of any protocol or encryption mode where $\operatorname{AES}^{-1}_K()$ is used anywhere, and invalidate the security argument of others.

Disclaimer:

The original question was more general than "is AES circular secure", since AES was cited as an example only.

You are asking for a circular secure scheme.

This is not as simple as it seems, because the security games that we use to prove security generally go (roughly) like this :

1. An oracle generate the keys;
2. The adversary chooses two messages $$m_0$$ and $$m_1$$, and send them to the oracle;
3. The oracle returns a ciphertext $$c$$;
4. The adversary tries to guess if $$c$$ encrypts $$m_0$$ or $$m_1$$.

And the scheme is considered secure if the adversary's advantage in step 4. is negligible.

Therefore, those security games do not cover the case "the adversary chooses one of the messages to be the secret key", because if the adversary could do that with non-negligible probability, they would already be able to win the game.

As a consequence, it may happen that a scheme is secure in normal usage, but insecure if one encrypts the own key. Indeed, researches managed to construct schemes that are CPA secure, but not circular secure.

However, I have read sometimes (even in scientific papers) that not being circular secure is believed to be an anomaly, in other words, in general, people believe that most of the schemes are circular secure. Moreover, this assumption (or a weak circular-security assumption) is used very often to construct advanced schemes like homomorphic encryption ones.

You may want to read this nice post by Matthew Green, which cites papers about this subject so that you can read them if you want more technical information.

• "And the scheme is considered secure if the probability that the adversary's guess is correct is negligible." Shouldn’t that be: "And the scheme is considered secure if the probability that the adversary's guess is correct is 50:50 (or indistinguishable from pure chance)." – Jonas Schäfer Dec 4 '19 at 14:46
• @JonasSchäfer yes, you are right. I should have written the adversary's advantage. I will edit it. Thank you. – Hilder Vitor Lima Pereira Dec 4 '19 at 15:39

I'd assume not; after all, how does having the key for a safe inside the safe make it easier to pick the lock?

Physical analogies like these are dangerous; cryptography is not locksmithing. Rather, we should appeal to security notions that come from cryptography itself. For example, a block cipher is a practical attempt at implementing a pseudo-random permutation, a bijective function that cannot be efficiently distinguished from a random permutation. The value that such a function assigns to any value is (for any number of queries up to the birthday bound) analogous to a random value, from which you wouldn't be able to learn anything about the input.

That's for a block cipher, though, and doesn't necessarily generalize to all kinds of ciphers. An interesting edge case here is the One-Time Pad (OTP) cipher:

$$C = M \oplus K$$

...because of course if you set $$M = K$$ (for keys and messages of length $$n$$) you get the all-zeroes length-$$n$$ string:

$$K \oplus K = 0^n$$

The only message that could possibly encrypt to all zeroes is the key itself, so in this case if you encrypt the key with itself the adversary can definitely tell that you did so. But knowing this doesn't help them learn anything else about the key, e.g., they cannot guess any one of its bits with better than even success probability.

• What I thought. Physical analogies like these are dangerous I know - I thought in this case it'd get the idea across effectively ;-) – Legorooj Dec 4 '19 at 2:53

There is no point to this. It would be like having two keys for a locked chest and then locking one of them in the chest. The only way to get the key out is by using the other key. You already have the key so why do you need the one in the chest? You can just make copies of the key without needing to go into the chest.

• Thank you for the comment. I understand your point. I was trying to see what happens in a case when key is the same as the message (unintentional). For example, if I have something like this: key = Random(); message = Random(); cipherText = aes_encrypt(key, message). assume that both key and message are from the same space (size 2 ^ 128). The probability of key = message is very low, but wanted to understand if such a case happens, will the system be considered insecure. – madhukar2k2 Feb 15 '13 at 7:54
• There are no known different attacks against AES when the key and message are the same. – ponsfonze Feb 15 '13 at 8:36
• Practically speaking it's so unlikely that it cannot be called "insecure". Theoritically speaking, if you take a look at the insides of aes you'll see that the first operation is xoring the plaintext with the key, effectively cancelling the state whatever the key. From then on the only difference between $AES_K(K)$ and $AES_{K'}(K')$ will come from the difference in the key scheduling of both keys. Hope it helps – Alexandre Yamajako Feb 15 '13 at 8:36
• @madhukar2k2: No, that would not make the system insecure. If you pick a random 128-bit number, you might pick zero, and an attacker might start searching at zero. But if you exclude zero as "insecure", then an attacker doesn't have to start at zero and the problem repeats for one. You only want to exclude unsafe choices if they have a high enough probability that the benefit from excluding them exceeds the cost. Reducing the search space by excluding a matching key has a cost (reducing an attacker's search space) greater than the benefit (eliminating one unsafe random key). – David Schwartz Feb 15 '13 at 10:06

For many things in cryptography, you must be careful to note the difference between "not known to be secure" and "insecure." If you use (an ideal representation of) AES to encrypt its own key, it is the case that its "not known to be secure" rather than it is "insecure." Thus, you can stare at the details of AES all day long and never see the problem.

What you need to stare at instead are the details of why we think that AES is secure; or more specifically, why we think AES with certain modes of operation (e.g., CBC or CTR) has one of the most basic definitions of security: something called semantic security.

The definition of semantic security involves a game where an adversary chooses messages to be encrypted by a blackbox with an embedded secret key, gets back ciphertexts, and has to guess some information about which ciphertexts correspond to which submitted messages. The reason the proof of semantic security does not "go through" when the the adversary chooses to encrypt the secret key is because the adversary doesn't know the secret key (or rather, if the adversary did know it, she could win always win the game). In other words, the hardness of the game is directly tied to the hardness of guessing the secret key (in addition to some assumptions about the block cipher).

This is more a peculiarity of provable security than a practical concern. It is possible to construct a pathological cryptosystem that is provably semantically secure but trivially insecure when you encrypt your own key. This fine but there are also pathological constructions of ideal block ciphers and hashes that become trivially insecure when implemented with a real function like AES or SHA2. These constructions, and the more general theoretic point, are routinely written off by cryptographers designing practical algorithms (my point isn't that these cryptographers are right to do that; only that they are prevalent --- don't kill the messenger).

If the encryption scheme is AES, then I would guess (as mentioned in the comments), that this would probably not be a big concern.

HOWEVER, in general, a secure encryption scheme (and here I define secure particularly to mean IND-CPA-secure), can still fail miserably when encrypting its own keys. To see this, assume $\mathcal{E}$ is an IND-CPA secure scheme. Then I can create another IND-CPA secure scheme, $\mathcal{E}'$, which is very insecure when given the secret key to encrypt. In particular, we define $\mathcal{E'}$ as: $$\mathcal{E}'_k(m) = \begin{cases} \mathcal{E}_k(m), & \text{ when } m \neq k \\ k, & \text{ when } m = k \end{cases}$$
Intuitively we understand that this must be IND-CPA secure, since the probability that the attacker will choose $m = k$ (in the IND-CPA game) is negligible. But, when given the secret key as the message, this encryption scheme is not exactly good. This is of course an artificial scheme, but it shows nevertheless that strange things can happen when you encrypt the secret key, in general.

This question is very much related to the notion of circular security, which you can read more about in this post, on the excellent blog of Matthew Green (where admittedly, I took the above idea from).

• Thank you @hakoja. Will definitely read more on circular sercurity. – madhukar2k2 Feb 15 '13 at 16:36