# Use additional keys to thwart key compromise?

Is it good or bad practice to design crypto protocols for key compromise by using additional keys? Argument for bad practice would be: When you have a key you should trust it and not throw more keys at the protocol "just in case". Is there any research/substance to that argument? Eventually, does it all boil down to a risk analysis (cost of compromise vs cost of additional keys)?

A small example to illustrate my question:

Assume Alice and Bob regularly communicate with each other using encrypted (using symmetric $K_{enc}$) and authenticated (using symmetric $K_{auth}$) messages:

$Cryptotext = Enc(K_{enc}, msg)$
$Alice \rightarrow Bob: Cryptotext, Hmac(K_{auth}, Cryptotext))$

Very rarely they want to communicate messages $M$ whose integrity is extremely important.

Under which circumstances (if any) would it make sense to use a second $K_{auth-important}$ to protect these extremely important messages?

$Cryptotext_M = Enc(K_{enc}, M, Hmac(K_{auth-important}, M))$
$Alice \rightarrow Bob: Cryptotext_M, Hmac(K_{auth}, Cryptotext_M)$

A motivation might be that since $K_{auth}$ is used in all communication it is more exposed and at least theoretically more likely to become compromised by recording and analyzing traffic. However, the protocol becomes more complex and if burglar Bert breaks into Alice's or Bob's safe, he will still find $K_{enc}$, $K_{auth}$ and $K_{auth-important}$.

-
I would do protocol nesting with an ephemeral key in that scenario, or perhaps for all messages if key compromise is likely. Proper implementation of HMAC will NOT allow compromise by analyzing traffic if done correctly. – Richie Frame Jun 2 '14 at 10:48

However, just adding extra keys "just in case" often doesn't make any sense, if it's not done to defeat a specific threat. For instance, suppose we take a protocol that uses some key $k_1$ to encrypt data, and we now introduce a new key $k_2$ that is used to encrypt $k_1$. If the key-encrypting key $k_2$ and the data-encrypting key $k_1$ are stored on the same computers, and if the underlying encryption algorithms are secure, it is not clear what failure modes would cause compromise of one of those keys without the other being compromised at the same time too -- so in such a case, adding an additional key might not add any significant security benefit.