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