One key for each task – A Secret to Share

3.2.1 One key for each task

In addition to the three basic requirements, it is a good practice in cryptography to have a unique key for each unique task. As an example, if Alice and Bob first authenticate each other (entity authentication) and then use message authentication to ensure their communication is not being manipulated by Mallory, they should use two different keys. One key should be used only for entity authentication and the other key only for message authentication. Typically, the former key is a long-term, possibly pre-shared key (PSK), while the other is a more short-lived, so-called session key (see the next subsection).

While this might seem odd at first, having two distinct keys instead of one has a major advantage. If Mallory manages to compromise the key used for entity authentication, say, by mounting a side-channel attack on Alice’s machine, the second key remains secure (at least for a certain period of time, namely until the next session key is negotiated). Mallory can now authenticate herself to Alice as Bob, but she still cannot send messages with the correct message authentication codes. Hence, the compromise of one key does not lead immediately to the total break of the entire security system.

In contrast, if a single key is used for all tasks, then regardless of the circumstances of how it is compromised, the entire security of that system is immediately broken. So, this best practice can be viewed as the cryptographic equivalent of not putting all your eggs in one basket.

3.2.2 Key change and session keys

Another good practice when dealing with cryptographic keys is to change them frequently. Regardless of what security measures they take, Alice and Bob can never rule out the possibility that their secret key becomes compromised.

There is always the chance that Mallory will find a new way to extract the key without breaking the underlying cryptography, for instance, by using a zero-day vulnerability to infest Alice’s computer with malware. Alternatively, Eve might find a new, more effective cryptanalytic attack that breaks the protocol or mechanism used by Alice and Bob within a reasonable time frame.

By changing their secret key(s) frequently, Alice and Bob mitigate these risks. A frequently changing key limits the amount of information (for example, plaintext-ciphertext pairs or message authentication codes for given plaintexts) available to Eve for cryptanalysis.

More generally, frequently changing keys protects Alice and Bob against future algorithmic vulnerabilities or advances in cryptanalysis that would shorten a key’s lifetime. As an example, if sufficiently large quantum computers with appropriate error correction (so that logical bits can be extracted from a large set of physical qubits in a stable way) ever become available, Eve could run Shor’s algorithm for factorizing large numbers or finding discrete logarithms [163], [164] to break public-key algorithms such as RSA or ECC that are widely used today. However, Alice and Bob can at least mitigate this threat by changing the key faster than a quantum computer needs to execute Shor’s algorithm.

Leave a Reply

Your email address will not be published. Required fields are marked *