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

  • 1
    $\begingroup$ 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. $\endgroup$ – Richie Frame Jun 2 '14 at 10:48

There is no one answer. It depends why you think that keys might be compromised. That has to depend upon a threat analysis, based upon how the protocol will be deployed and what the most likely failure modes and forms of compromise might be.

For instance, it is pretty clear that a key that is stored in software on an Internet-connected computer is (all else being equal) probably at higher risk of compromise than a key that is stored on a computer that is never connected to any network. This then leads to protocols where a long-term signing key is stored in a hardware security module (HSM) that's airgapped and never connected to any computer, and is used to sign certificates for emphemeral public/private keypairs, where the private key is stored on an Internet-connected computer. Such a use of additional keys might have security benefits.

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.

  • $\begingroup$ "However, just adding extra keys 'just in case' often doesn't make any sense, if it's not done to defeat a specific threat." Nice one. $\endgroup$ – AHalvar Jun 3 '14 at 13:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.