# Encrypting a key with the same key

I am new to crypto and trying to understand why it would be insecure to use AES to encrypt a key with the same key.

Basically, something like this: encrypt(key, key)

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

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

I tried searching for an answer for the above, but couldnt not find one. Sorry if its been answered before. A link to the older posts would also be a great help in that case.

-
 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 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 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 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 at 11:24

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.

-
 Thanks for providing the benefits and drawbacks. – madhukar2k2 Feb 15 at 19:51

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 at 7:54 There are no known different attacks against AES when the key and message are the same. – ponsfonze Feb 15 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 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 at 10:06 All: Thank you for your comments. – madhukar2k2 Feb 15 at 16:35

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 at 16:36

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).

-
 Thank you @PulpSpy – madhukar2k2 Feb 15 at 16:37