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.
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 :
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.
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.
Physical analogies like these are dangerous I know - I thought in this case it'd get the idea across effectively ;-)
– Legorooj
Dec 04 '19 at 02: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.
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 08:36For 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).
