Course outline

Cybersecurity / Advanced: architecture, recovery, and governance / Lesson 14

Cryptography and the key lifecycle

Distinguish integrity, keyed authenticity, confidentiality, and trusted origin. Treat cryptographic keys and recovery as managed service dependencies rather than inventing an algorithm.

About 5 min readContent reviewed
On this page

Lesson goals

  • Explain hashes, MACs, encryption, and signatures without conflating their claims.
  • Plan key purpose, access, rotation, compromise response, and recovery.

Choose a security property before a mechanism

A cryptographic hash summarizes bytes and can support change detection when the expected digest is trusted. A message authentication code uses a secret shared key to authenticate a message to other holders of that key. Encryption addresses confidentiality, while authenticated encryption can also protect integrity under its documented usage requirements. Digital signatures have a different public-key verification model and still depend on trusted binding between a key and its claimed identity. None of these mechanisms automatically proves that the content is accurate, authorized, timely, or produced by an uncompromised application. Name the precise claim before choosing an approved implementation.

Use a hash for a narrow comparison

The standard-library example compares synthetic content and an altered version without reading files or contacting any system. It demonstrates equality and inequality of SHA-256 digests for these inputs. If an untrusted source supplies both a file and its expected hash, the comparison does not establish approved provenance. A general fast hash is also not a suitable stand-alone password-storage design; use a supported password-hashing system with its required parameters and lifecycle. Keep instructional byte comparisons separate from production cryptographic protocols, credentials, and key generation. The code does not implement encryption or certify the source.

python Offline hash comparison of invented bytes
import hashlib

original = b"synthetic recovery manifest: version 1"
same = b"synthetic recovery manifest: version 1"
altered = b"synthetic recovery manifest: version 2"
assert hashlib.sha256(original).digest() == hashlib.sha256(same).digest()
assert hashlib.sha256(original).digest() != hashlib.sha256(altered).digest()

Both assertions succeed for the stated input. This proves the example comparison, not authenticity, password safety, or complete backup correctness. No real manifest or secret is read.

Manage key material and metadata together

A key inventory should state purpose, algorithm or service, authorized uses, owner, access path, identifier, active status, and recovery or destruction requirements without exposing the secret value. Generate and store production keys through approved libraries or managed key facilities appropriate to the environment. Separate privileges for using a key from administering its policy where the design requires it. Rotation must consider old ciphertext, verification needs, replicas, caches, backups, and rollback. A new active key does not make historical data readable unless the required previous material and metadata remain available under the approved retention policy.

Understand what shared-key authentication establishes

This example calls the standard HMAC construction through Python’s library; it does not invent a cryptographic algorithm. The fixed classroom key is public synthetic data and is unsuitable for any real protection. A matching tag verifies for the original message and fails for changed bytes under this same key. Every holder of a shared MAC key can create a valid tag, so a tag does not identify which holder produced it. Verification requires protected key distribution and an appropriate protocol, including freshness or replay rules when the application needs them. These assertions model none of those operational controls.

python A standard-library MAC demonstration
import hashlib
import hmac

lab_key = b"public-synthetic-classroom-key-not-for-production"
message = b"synthetic record count: 3"
tag = hmac.new(lab_key, message, hashlib.sha256).digest()
assert hmac.compare_digest(tag, hmac.new(lab_key, message, hashlib.sha256).digest())
assert not hmac.compare_digest(tag, hmac.new(lab_key, b"synthetic record count: 4", hashlib.sha256).digest())

The original-message check is true and the altered-message check is false. The key is intentionally nonsecret, making this a property demonstration only. It supplies no real authentication service or replay defense.

Plan loss and compromise as different incidents

Loss of a decryption key can make retained ciphertext unusable; disclosure of a key can invalidate the confidentiality or authenticity assumptions of affected material. Recovery policy must distinguish those cases and the key’s purpose. Restoring a compromised signing key does not restore trust in its prior signatures automatically. Use approved revocation, replacement, re-encryption, and investigation processes as applicable, with owners and evidence. Test required recovery access in an isolated authorized exercise without exporting real keys into a course or ticket. NIST key-management guidance and OWASP recommendations inform the lifecycle, while actual implementation choices require current supported mechanisms and reviewed environment-specific policy.

Common errors and fixes

A checksum is treated as trusted authorship

Why it happens
The expected digest and identity binding are untrusted.
How to fix it
Establish an approved authenticity or provenance mechanism.
Prevent it next time
State the trust source for every expected value.

Key rotation makes old backups unreadable

Why it happens
Historical decryption requirements were omitted.
How to fix it
Review retained key versions and authorized recovery dependencies.
Prevent it next time
Rehearse restoration across the retained data lifecycle.

A library primitive is assembled into a homemade protocol

Why it happens
Correct individual operations are assumed to guarantee a secure system.
How to fix it
Use a supported reviewed protocol and approved library interface.
Prevent it next time
Review key, nonce, identity, and freshness requirements together.

Check your understanding

1. A supplier provides an archive and SHA-256 value through the same untrusted channel. What has equality established?

Show worked solution

Only agreement with that supplied reference under the hash comparison. It does not establish the supplier’s approved identity or an authorized artifact. Obtain trustworthy provenance or authenticity evidence and validate the expected content and compatibility separately.

2. A new encryption key is active and the previous key is deleted immediately. Which recovery question was missed?

Show worked solution

Whether retained ciphertext and backups still require the previous key version and associated metadata. Establish the permitted retention, use, recovery, and destruction policy before deletion, then test the necessary path safely. Rotation and historical recovery are coordinated lifecycle decisions.

Key takeaways

  • Hash, MAC, encryption, and signature claims are different.
  • Keys need purpose, ownership, controlled access, and tested recovery.
  • Use supported mechanisms rather than homemade cryptography.

Official references