Sometime in the late 1980's I was introduced to the "One use, one key" rule ("une clé par usage"). A longer version could be: a cryptographic key should have a single purpose, with any exception justified by operational need and supported by a security analysis.
What's the history of the development of this key-management principle, whatever the wording? Update: I'm told it's known as key isolation or key separation.
How is it expressed in security recommendations or regulations, Common Criteria and the like?
Any notable corollary beside the following?
- Possession of a secret key (symmetric key or private key) materializes an authorization to access some information or location, operate some device, approve some type of information. Such authorizations should be compartmentalized inasmuch as practical by having a key for each kind of authorization and each subject for that authorization.
- In public-key cryptography, there should be a public/private key pair for each device or person, and for each role they have; e.g. acting as a private person, as company employee, as security officer, as a timestamping device. That allows selective revocation of authorization, fine-grained and per-message choice of recipients a message in hybrid encryption, identifying the meaning of a signature, and more.
- When possible don't reuse keys across a succession of communication sessions. Instead use session-unique keys. That's necessary for forward secrecy.
- Keys for transmission and reception, for message encryption and message authentication, should be separate (guards against some attack, e.g. reflexion attack, breaking authentication when using the same key for some combinations of CBC encryption and CBC MAC).
- Any key with multiple purposes for functional reasons should be used only as key of a Key Derivation Function, with the other input a public key derivation constant unique for each use. For keys that must go thru key stretching (e.g. passwords), the key derivation for multiple keys always used jointly (e.g. the keys implied by #3 and #4) might need to cascade two KDFs: a purposely slow KDF like Argon2 or scrypt for key stretching, then key derivation per se using HKDF or the same KDF as in the first step, but parameterized for speed.
- Point #5 should also apply to any single-purpose key (much more password/passphrase). That's to allow interoperability when and if introducing a new purpose for that key.
- Avoid using the same key for multiple cryptographic algorithms and protocols (among reasons: it's an assumption in the security evaluation of the algorithms and protocols, and of their implementation when facing some attacks like exploitation of side-channels). If an exception must be done because #6 was not followed, at least make sure the key is used for unrelated cryptographic algorithms (e.g. it's arguably OK for AES-CTR and HMAC-SHA-256).
