1.4Cryptography (Symmetric-Key, Public-Key, Hybrid Cryptography, Hashing, Key Management)

Cryptography is often imagined simply as 'a technology that protects information from being read,' but what matters to a manager is not implementing the algorithm but the operational question of which scheme to use when, and how to manage the keys. Choosing a strong cryptographic scheme means nothing if key management is sloppy. This section covers the basic tradeoffs among cryptographic schemes and the key management and obsolescence concerns SG particularly emphasizes.

1.4.1Symmetric-key, public-key, and hybrid cryptography

• In symmetric-key cryptography, encryption and decryption use the same key (e.g. AES). It is fast, but sharing a key securely with each communication partner is the key distribution problem. In public-key cryptography, a paired public key and private key are used (e.g. RSA). Content encrypted with the public key can only be decrypted with the matching private key, solving the key distribution problem, but it is slower than symmetric-key cryptography.
• Hybrid cryptography is the mainstream approach in practice: the bulk data is encrypted with fast symmetric-key cryptography, while only that symmetric (session) key is encrypted with public-key cryptography for transport, achieving both a solution to the key-distribution problem and processing speed. SSL/TLS key exchange is based on this scheme (covered in the next section).

1.4.2Hash functions, cryptographic obsolescence, and key management

• A hash function produces a fixed-length value (a hash) from data of any length, as a one-way function (it cannot be decrypted; the original data cannot be recovered). Since the same input always yields the same hash, it is used for tamper detection and secure password storage (storing a hash instead of the plaintext password).
• When computing power improves or a new attack technique is found, cryptographic obsolescence (compromise) occurs — a cryptographic scheme or key length that was safe in the past becomes breakable over time (e.g., the older hash functions MD5 and SHA-1 had collisions found and are no longer recommended for new use). A manager must not assume "it was safe when we adopted it, so it is still safe" — they are responsible for continuously tracking obsolescence information and planning updates to the scheme and key length (crypto-agility).
• The key management lifecycle: generation (creating a sufficiently strong key via a secure method) -> storage (secure storage, e.g. in an HSM (hardware security module), preventing private-key leakage) -> rotation (periodically renewing keys to limit the blast radius if one leaks) -> disposal (reliably deleting a key that is no longer needed in an unrecoverable way). If a private key leaks, the trustworthiness of everything ever encrypted or signed with it is lost, which is why storage controls matter most.

Consider a SaaS company's security officer conducting an inventory of the cryptographic schemes the service has used for years. Checking how user passwords are stored, they confirm the design stores a hash rather than the plaintext password, so even if the database leaked, the password itself could not be read directly — despite using an older hash function. But investigating that hash function further reveals it is one where recent research has found collisions (different inputs producing the same hash), and new use of it is no longer recommended. This is a textbook case of cryptographic obsolescence, and it cannot simply be left alone on the grounds that "it was safe when we adopted it." The officer draws up a migration plan to the current recommended scheme, including the scope of impact (such as when to re-hash existing users' passwords), and reports it to management. Next, checking how API keys and signing private keys are managed, they find a private key sitting unencrypted for a long time on a developer's personal PC — a serious gap in the storage stage of the key management lifecycle. Since a leaked private key undermines the trustworthiness of everything ever signed or encrypted with it, the officer migrates it to an HSM or a dedicated secrets-management service, and additionally institutes periodic key rotation as a standard operating rule. The point is that the practical essence of cryptography for a manager is not just the strength of a given scheme, but the operational discipline of keeping up with obsolescence and having a process to securely store and dispose of keys.

1.4.3Section summary

• Symmetric-key = fast but has key-distribution problem; public-key = solves it but slow. Practice uses hybrid cryptography
• Cryptographic obsolescence = an older scheme becoming breakable over time. Continuous tracking and updates are a manager's responsibility
• Key management lifecycle = generation -> storage -> rotation -> disposal. A leaked private key destroys the trustworthiness of everything tied to it